Services firm: CRM to cash

Lab build. This is a reference implementation in the bworkx Frappe lab using a synthetic professional-services firm. It is not a client engagement. Figures are lab benchmarks.

The problem

A services firm of about 45 people had grown into four disconnected tools:

• A CRM used only by sales, with no link to delivery.
• Project plans and timesheets in spreadsheets.
• Invoices raised manually in accounting software.
• Support requests in a shared inbox.

Every handoff lost context. Sales promised scope that delivery never saw. Invoices missed change requests. Support tickets reopened issues that were already known to the account manager.

The objective was narrow: one customer record, one revenue trail, from enquiry to payment.

Scope

1. Lead capture and qualification in Frappe CRM.
2. Conversion to a customer, opportunity, and project.
3. Project tasks, timesheets, and milestone billing.
4. Sales invoices and payment reconciliation in ERPNext.
5. Support tickets linked to the same customer and project.
6. A customer profitability view.

Out of scope: marketing automation, complex resource scheduling, and payroll.

Architecture

Frappe CRM ──► ERPNext Customer ──► Project ──► Sales Invoice ──► Payment
      │                                  │
      └──────────► Helpdesk ticket ◄─────┘

All four apps share one Frappe site, so the customer is a single record rather than a sync job. That is the main architectural decision, and it removes an entire class of integration failures.

Key workflows

Qualify and convert

A lead is scored on a short, explicit set of criteria. Conversion creates the customer, an opportunity, and a draft project in one action. The original enquiry text stays attached to the record, so delivery can read what was actually promised.

Deliver against milestones

Projects use milestone billing: discovery, build, and handover. Timesheets roll up to the project. When a milestone is marked complete, a draft invoice is generated for review rather than created from memory at month end.

Bill change requests

Change requests are tracked as separate, billable items on the project. This was the single biggest commercial win in the lab build: the work was already happening, it simply was not being invoiced.

Support with context

Helpdesk tickets link to both customer and project. An agent can see the contract, the open invoices, and the delivery history before replying.

What was actually hard

Deciding what a “project” is. The firm used the word for a retainer, a fixed-scope engagement, and an internal initiative. We defined three project types with different billing behaviour, then mapped the existing work onto them.

Time capture. Timesheets fail when they are a separate ritual. The lab version puts a weekly grid in front of the consultant and defaults to the projects they are actually assigned to.

Revenue recognition. Milestone billing is simple until a milestone spans a month boundary. We documented the rule rather than building elaborate automation.

Permissions. Sales should see pipeline, not salaries; delivery should see projects, not margin. Role design took longer than the doctype configuration.

Lab benchmarks

• Lead to project conversion: one action, under 30 seconds.
• Customer profitability report: under a second on 12 months of synthetic transactions.
• Invoice draft generation: one click per completed milestone.
• Support ticket lookup by customer: single search, all linked records visible.

What I would do differently

Model the commercial rules before the screens. The first iteration looked good and billed the wrong things. Once milestone and change-request rules were written down, the configuration became obvious and much smaller.