CRM Implementation: The Scope Nobody Writes Down

The project has been signed off. The data is in, the fields are right, the team has had its training. In the first week after go-live somebody notices that enquiries from the contact form are no longer assigned to anyone. They just sit there. Nobody removed that rule — it is simply that nobody ever wrote down that it existed.

This is the most common break in a CRM implementation, and it almost never involves data. Data moves. What does not move on its own are the processes that ran quietly in the old system: automations, assignment rules, the handover between Marketing and Sales. They appear in no scope document, because nobody ever thought of them as a separate item.

Why sign-off does not catch it

A sign-off checks what the scope says. That is exactly its purpose, and exactly where the gap sits: processes nobody wrote about are not test points. They appear on no checklist, because a checklist is built from the scope.

The path there is always the same, and every single step of it looks sensible. In the workshop the customer mentions a rule that matters to them. The vendor agrees to cover it. Two weeks later the rule is discussed again in more detail, because a dependency has surfaced. Both sides know what is meant, and neither records it — the scope dates from week one and is never updated. By go-live there are three versions: the one in the document, the one in the customer's head, and the one in the system.

So the moment of the break is not the moment of the mistake. The mistake happened weeks earlier, in a conversation where someone said "we will obviously include that" and nobody noted what "that" was. The internal review on the vendor side almost always reaches the same, unspectacular conclusion: not bad faith, but weak project governance. Scope changes were discussed verbally and never put in writing, and risks were never formally escalated to decision-makers on both sides.

Data moves, processes do not

This distinction carries the whole article. A data import is a bounded technical task: objects, fields, mappings, deduplication logic. It can be described in days and verified in days. Process integration is something else — it asks which workflows the new system has to carry after go-live, and it is the part that takes weeks.

At MAIA by Prodlane both are on the record and kept apart. The company had previously invested four weeks in Pipedrive, but had run into the limits of its configurability. SalesPlaybook then helped configure HubSpot completely and integrate it into existing processes within six to eight weeks, with the result that clearly structured sales processes made the work more efficient and predictable.

The number of weeks is the interesting quantity. It does not describe how long an import takes; it describes how long it takes until a system genuinely represents how a team works. So when you read a migration duration in a proposal, ask precisely that: does the figure refer to the data or to the processes?

The four areas that regularly go missing

Across implementation and migration projects the same pattern repeats. Four areas run so unobtrusively in the old system that nobody perceives them as a deliverable — and so they never make it into the scope.

The fourth row is the awkward one, because it is usually seen as sitting outside CRM responsibility. A webhook that pushes orders into the billing system counts internally as an IT topic — until it stops firing after the switch. Then it is a CRM topic.

Building the list of these four areas takes less time than the argument about who ought to build it. In the old system, automations and assignment rules are enumerable: they sit in an overview, they have names, and they can be exported. The handover to Sales is harder, because part of it lives in a habit rather than in the system — then the right question is not "which rule applies" but "how does a rep recognise that a lead is theirs". For the interfaces, the only method that works is to walk through every system that reads from or writes to the CRM and name one person per system.

Whoever has that list before signing is then negotiating about something concrete. The vendor can size every line, take it out, or price it as effort. What they can no longer do is carry it along unspoken — and that is the entire point of the exercise.

The counter-case: when the scope exists first

It can go the other way, and the difference is not luck. Workist set up the move from Salesforce to HubSpot as a change to the whole revenue journey rather than a data relocation: Marketing, Sales and Service in one system, backend integration through webhooks, usable by every team from day one.

Two further items come from the same case study: more than €100,000 in annual tool costs saved, including by replacing Zendesk and other tools, and a full-time RevOps role that was no longer required, thanks to a cleanly designed, maintainable setup. Both figures are stated in the Workist case study.

The point of these numbers is not their size. It is that "a complete end-to-end representation of the revenue journey" was a scope item at Workist, not a by-product. Make the processes the subject of the project and you get them — and you end up saving in a place nobody had budgeted for.

What a scope line that holds looks like

The difference between a scope that holds and one that has to be interpreted later comes down to a single property: the line names a result you can check at go-live. Three examples from the same part of a project.

Does not hold: "Migration of existing automations." The line sounds complete and is not — it does not say which ones, how many, or whether "migration" means rebuild or replace. There is nothing to verify at go-live.

Holds: "The 14 Pipedrive automations listed in the 12 March export will be rebuilt in HubSpot. Seven of them one to one; seven will first be reviewed for fit and consolidated where appropriate, with the decision documented per rule." That line has a number, a source, a boundary and a test point.

Also holds: "Automations are not part of this project. The customer will build them after go-live; SalesPlaybook provides an inventory of the legacy rules." An explicit no is good scope. What endangers a go-live is not a narrow boundary — it is a missing one.

The same test applies to every line: does it state something whose absence would be noticed the day after go-live? If yes, the line is usable. If the answer is "that depends how you read it", it is the next dispute.

When it does break: problem before responsibility

No scope is complete. At some point something breaks that nobody foresaw — and then the order of the first response decides the working relationship, not the contract text.

Here is what happens almost automatically in that moment: as soon as the problem is visible, the conversation shifts to what was agreed and what was not. To the vendor that feels like necessary clarification. To the customer it feels like a change of subject — away from the outage, towards a detail they did not raise. Their process is still not running.

This is not a question of politeness but of effect. Talk about responsibility first and the damage to trust is usually already done, however justified the contractual point turns out to be.

The list for the proposal in front of you

Writing things down here is not a formality. It is the only tool that works reliably in a project with two parties and several months of runtime. A note after each workshop stating what changed in the scope and who agreed costs ten minutes. It replaces a later conversation in which both sides sincerely remember something different.

If you are reviewing a proposal for a CRM implementation right now, these are the questions that make the difference. They are deliberately phrased so that an evasive answer is noticeable.

1. Does the scope name processes or only objects? If it says "contacts, companies, deals", that is a data scope. Processes have names.
2. Who produces the inventory of existing automations? If the answer stays open, nobody produces it.
3. Does the stated duration refer to import or to integration? Both are legitimate answers — but only one of them describes the go-live.
4. How are scope changes recorded? "We agree things as we go" is the answer that becomes the dispute later.
5. What happens in week one after go-live? A project that ends at sign-off ends too early.

For the route out of a specific legacy system we go into detail elsewhere — Salesforce, Marketo, Zoho and Excel each have their own traps. What the effort costs internally is worked through in our piece on the internal cost of a CRM migration. And when several entities are involved, the governance question comes on top, which we describe for group-wide CRM projects.

A scope is not a legal document. It is a list of the processes that have to run after go-live — and whoever writes them down beforehand ends up without a contract problem and with a project plan.