Ask most teams what their CRM is for and you get some version of “keeping track of leads.” Which is true, and is also why the thing turns into an expensive contact list that nobody trusts by month nine.
The problem is not the platform. It is that the record structure only describes one third of the business.
Sales lives in there. Delivery lives in a project tool or somebody’s head. Billing lives in Stripe or an accounting package. Nothing reconciles, so every real question gets answered in a spreadsheet, and the CRM slowly becomes a place you update after the fact rather than the place the work happens.
The gap is everything after “closed won”
Watch what a normal CRM does when a deal closes. The deal moves to a won column. Then nothing.
That is the exact moment the relationship actually starts. Onboarding begins, work gets scoped, deliverables get built, someone starts getting invoiced monthly. None of it has anywhere to live, so it scatters.
The fix is a record for the ongoing relationship itself, separate from the deal that created it. Call it an engagement, an account, a retainer, whatever fits how you talk. What matters is that it holds the things a deal cannot: what services are in scope, what the client pays and how often, what state the relationship is in right now, and who owns it.
Once that record exists, questions that used to need a spreadsheet become a view. Which clients are active. What is recurring revenue this month. Who has not been touched in three weeks. Which engagements are stalled in onboarding.
One-time work is a deal, not a field
A related mistake that causes real reporting pain later.
An existing client buys a one-off build. The instinct is to record it on their engagement record, as a note or a value bump, because they are already a client and it feels like part of the relationship.
Do not. It is a deal. It has a value, it closed on a date, and it was won. Putting it anywhere else means your sales reporting quietly stops counting revenue you actually sold, and you end up with a pipeline number that undercounts and a relationship record that has become a diary.
The clean rule: anything sold is a deal. Anything ongoing is an engagement. A long client relationship is one engagement and several deals over time, and that is a feature, because it lets you see expansion clearly.
Contracted and collected are different numbers
This is the one that causes arguments.
Your CRM knows what you sold: the terms, the monthly figure, the setup fee. Your billing system knows what actually arrived: whether the invoice went out, whether it was paid, whether someone downgraded in month four.
Those are different numbers and they should stay in different systems. The CRM holds contracted terms. Billing holds realized cash and is the source for revenue reporting. Join them on a shared customer identifier so you can move between them.
Never sum a new business deal AND the recurring engagement it created. It is the same money counted twice, and it produces a revenue number that feels great and is wrong. Decide which system answers "how much did we make" and let the other one answer "what did we agree to."
If you only automate one thing between them, make it billing status flowing back into the CRM. Whether someone is current, late, or churned changes how you treat the relationship, and that is the one billing fact the team needs to see without opening a finance tool.
Model delivery where you can see it
Once engagements exist, the argument for keeping delivery in a separate project tool gets weak.
The case for a separate tool is that it has better task features. The case against is that delivery is invisible to the system that owns the client relationship. Nobody can answer “what are we actually building for this client right now” without opening a second app and mentally joining it to the first.
Modeling deliverables inside the CRM, linked to both the client and the engagement, closes that. The work becomes visible next to the money and the relationship. And it removes an entire category of stale integration between two tools that disagree about what a client is.
The test
You do not need a diagram to know whether your model holds. Try to answer these without opening a spreadsheet:
What is our recurring revenue this month, by client. Which clients are actively being delivered to right now. What did we sell this quarter that was not recurring. Which relationships have gone quiet. What are we currently building, and for whom.
If those take a spreadsheet, the answer is not a better report. The records do not describe the business yet.
A CRM that only models companies, people, and deals describes how you win work and nothing else. Add the ongoing relationship and the work inside it, keep contracted separate from collected, and the spreadsheets stop being necessary.
