Short answer: Build a single record that travels from enquiry to invoice, changing state rather than being re-created at each stage. Define the states, the transition triggers, and the required data at each step; hold it all in one relational system; and use an integration platform to push actions outward at each transition. The key design rule is one record, many states — not five systems, five records.
Why most pipelines break at the joins
In a typical small business, a lead exists in a form response, becomes a row in a spreadsheet, is re-typed into a proposal tool, re-typed again into a project tracker, and re-typed a fourth time into the accounting system. Five representations of one commercial relationship, each drifting from the others.
Every join is a manual bridge, a delay, and a place where the client's context is lost. Fixing the joins is the whole point of pipeline design.
The data model that makes it work
You need a small number of related objects, held in one relational system:
- Company — the organisation. One record, ever.
- Contact — people, linked to a company. Many per company.
- Opportunity — a potential piece of work, linked to a company. This is the record that travels.
- Project — created when an opportunity is won, linked back to it.
- Invoice — linked to the project, mirrored from your accounting system.
The critical relationship is opportunity to project to invoice. When those three are linked, you can answer questions that are otherwise impossible: what did we quote versus what did we bill, how long from enquiry to payment, which source produces the work that actually gets paid.
The states and what triggers them
Define the opportunity's lifecycle explicitly. A workable default:
- New — created by form submission or manual entry.
- Qualified — a human confirms it fits. This is a judgement step and stays human.
- Proposal sent — triggers document generation from record data and dispatch.
- Won or Lost — won triggers project creation, folder setup, onboarding sequence and team notification. Lost triggers a reason capture, which is the cheapest market research available.
- Delivered — triggers the invoice condition.
- Invoiced and Paid — status flows back from accounting automatically.
What the automation layer actually does
At each transition, the integration platform performs the outward actions: generate the document, create the folder, send the email, notify the channel, raise the invoice, update the linked records. The database holds state; the automation platform moves things in response to state changes. Keeping that separation clear is what makes the system debuggable a year later.
Where to keep humans in the loop
Three points, minimum: qualification, proposal approval before dispatch, and the decision that delivery is complete. These are judgement calls with commercial consequences. Everything between them can run without intervention.
What to build first
Don't build the whole pipeline in one go. Sequence it:
- Get the data model right and migrate existing records into it.
- Automate enquiry-to-record creation. Run it for two weeks.
- Automate won-to-project-and-onboarding.
- Connect the accounting system for invoice status.
- Add reporting on top, once the data has been flowing long enough to be meaningful.
Frequently asked questions
What tools does this need?
A relational database or CRM (Airtable, HubSpot, Pipedrive), an integration platform (Make.com or similar), a document generator, and your accounting system. Four tools, properly connected, beat eight loosely coupled ones.
How long does it take to build?
Three to six weeks for a small business, with data migration typically taking longer than the automation itself.
What if we already have a CRM?
Use it, provided it can represent the object model and has a usable API. Migration is a last resort, not a starting point.
This is the backbone we build as standard — CRM, intake, finance and reporting as one system. See it in practice.
