How to implement a CRM without rebuilding it twice.

A CRM implementation is a sequence of decisions, most of which are not technical. Which states can a deal occupy? Who holds it in each one? What must be recorded for the next person to act? What happens when a record simply sits? A CRM can hold the answers to those questions. It cannot produce them, and it will faithfully encode a bad answer.

The fourteen steps below are ordered because the order is the method. Steps one to five are agreements. Steps six to eleven are configuration. Steps twelve to fourteen are what turns a configured system into an operated one. Teams that start at step six get a system that mirrors their confusion back at them, and a second implementation eighteen months later.

The common story is not that the software was wrong. It is that the business bought a system, imported its contacts, accepted the default pipeline, invited the team, and then discovered that nobody could answer a simple question from the record: whose move is it on this deal, and what is it waiting for?

Once that gap exists, the team routes around it. The real state of the pipeline moves into a spreadsheet, a group chat, or one person's memory. The CRM becomes a place where data is entered rather than a place where work is decided, and the entry stops the moment somebody is busy. From there the reporting is wrong, the follow-up is inconsistent, and the eventual conclusion — that this CRM was not the right tool — is the wrong conclusion drawn from the right symptoms.

The fix is unglamorous. Establish what the system must represent before deciding what to switch on. That work is uncomfortable because it surfaces disagreements the business has been carrying informally, which is precisely why it produces a system people use.

Each step below states what it settles and what exists afterwards. That second column is the useful one: it is how a team knows a step is finished rather than merely discussed. A step with no output has not been done.

1. 01

   Map how work actually arrives and moves

   Decides

   What really happens today, traced through real recent records rather than described in a meeting.

   Output

   A written flow of the current process, including the paths that went nowhere and the ones nobody documented.

2. 02

   Define the stages

   Decides

   The states a record can occupy, each verifiable by someone who was not there.

   Output

   A stage list where every stage has an observable definition, not a label that means whatever the last person assumed.

3. 03

   Define ownership

   Decides

   Who holds a record in each stage, how that is assigned, and what happens when the owner is away.

   Output

   An ownership rule that always produces exactly one named person. A queue is not an owner.

4. 04

   Define required data

   Decides

   What every record must carry, chosen for the decisions it supports rather than for completeness.

   Output

   A field list where each required field has a decision attached to it, and everything else is optional or absent.

5. 05

   Decide what happens when nothing happens

   Decides

   The designed behaviour of a record that simply sits: a timeout, an alert, a reassignment, a recorded exception.

   Output

   A written rule per stage. Silence is not permitted to be a valid outcome.

6. 06

   Clean and import the data

   Decides

   What is worth migrating, what is duplicated, and what should be left behind.

   Output

   An imported set the team believes, with a documented record of what was excluded and why.

7. 07

   Configure capture

   Decides

   Every route by which an enquiry can arrive, and how each one becomes a structured record with its source attached.

   Output

   Forms, inbound channels and intake paths landing in the system without retyping, source intact.

8. 08

   Configure routing

   Decides

   Which records go to whom, based on classification rather than on who happens to be free.

   Output

   A routing rule that resolves deterministically, including a defined fallback when it cannot.

9. 09

   Configure automation

   Decides

   Which steps are safe to automate, and which exist to protect a human response rather than to replace it.

   Output

   Acknowledgements, internal alerts and stalled-record checks, each traceable to a rule agreed in steps two to five.

10. 10

    Define stopping conditions

    Decides

    What changes or ends an automated sequence: a reply, an acceptance, a decline, a request for time, an opt-out.

    Output

    A stopping rule attached to every sequence, decided before any cadence is chosen.

11. 11

    Define exceptions

    Decides

    What the system does with the cases that do not fit — the duplicate, the reopened deal, the customer who returns a year later.

    Output

    An exception path that routes to a person with the context assembled, instead of failing silently.

12. 12

    Create reporting

    Decides

    The small number of questions the business will actually act on.

    Output

    Views answering what is stalled, what is unassigned, what entered, what closed and why. Nothing built for decoration.

13. 13

    Test against real cases

    Decides

    Whether the configuration survives the work the team really does, including the awkward cases.

    Output

    Real historical records run through the system end to end, with the failures fixed before anyone depends on it.

14. 14

    Train, then establish ongoing ownership

    Decides

    Who inside the business can change the configuration, and who explains it to the next person hired.

    Output

    A trained team, written operating rules, and a named internal owner who knows what changing a rule affects.

Of the fourteen, two decide whether the rest holds. The first is the stage definition. A stage is worth having only if someone who was not on the call can look at the record and agree it belongs there. Stages like Interested, Warm or In progress fail that test: they describe a feeling, so two people will place the same record differently and the pipeline stops meaning anything. Quote sent, Site visit booked and Awaiting finance decision pass it, because each names something that either happened or did not.

The second is ownership. An owner is one named person, produced by a rule that always resolves. Assignment to a team, a queue, a role or a rota is the shape most commonly mistaken for ownership, and it is the shape in which work goes missing: everybody can see it and nobody has to move it. The test is simple — if a record has been sitting for four days, is there a single name that has to answer for it? If the answer is a department, ownership has not been defined.

A useful check on both: pick five records that went quiet last quarter and ask, from the record alone, what state each was in and whose move it was. If the record cannot answer, the stage and ownership definitions are the implementation, and the software is not the problem.

Every required field is a small tax paid on every record by the person least able to refuse it, usually while doing something else. The discipline is to require a field only when a decision depends on it. If nobody can name the decision, the field is optional or it does not exist. A form nobody completes honestly produces data nobody can use, and the resulting report is worse than no report, because it is believed.

Automation deserves the same scepticism, in the other direction. An automated step is a commitment that runs whether or not anyone is watching, which makes its stopping condition more important than its content. The sequence that keeps sending after a customer has replied does not merely waste a message; it tells that customer the business is not listening. Design what ends a sequence before deciding what it says.

There is a narrower question underneath both: what is the system of record for a given fact? When two systems can each hold a customer's phone number, address or deal stage, one of them has to be authoritative and the other has to be a copy. Leaving that undecided is what produces the familiar situation in which nobody trusts either system and both are updated by hand.

A configuration tested only with clean invented records passes easily and fails in week one. The cases worth testing are the ones the team already finds difficult: the enquiry that arrives twice through different channels, the customer who says not yet and means call me in March, the deal that dies and revives, the record that has to change owner mid-flight. Run real historical examples through the system before anyone relies on it, and fix what breaks while breaking it is free.

Training then has to cover the part that is not visible in the interface. Most teams can learn where the buttons are. What they need explained is why a stage exists, what a stage change asserts, when to record a reason rather than a status, and what the automation will do on their behalf after they close the tab. A team that understands the rules will use a mediocre interface correctly. A team that has only been shown the interface will use an excellent one inconsistently.

The last step is the one most often skipped, because it does not feel like part of the project. A CRM encodes a business's operating rules, and those rules change: a new service line, a new channel, a person leaving, a pricing model that alters what a stage means. Without a named internal owner who can make those changes and knows what they affect, every adjustment becomes a request to whoever configured it, and the gap between the configuration and the business widens quietly until somebody proposes replacing the system.

Ownership does not require the owner to be technical. It requires them to hold the rules — to be the person who can say what Quote sent means here, why routing works the way it does, and what has to be true before a stage change is allowed. The documentation exists to make that role transferable rather than to sit unread.

1. The first five steps are agreements, not configuration. A project that begins by switching things on is encoding an argument nobody has had yet.
2. A stage is only real if someone who was not present can verify it from the record. Stages that describe a feeling make the pipeline unreadable.
3. An owner is one named person produced by a rule that always resolves. A queue, a team or a role is where records go missing in plain sight.
4. Require a field only when a decision depends on it. Every other required field is a tax on the person least able to refuse it.
5. Design what stops an automated sequence before deciding what it says. A sequence that continues after a reply tells the customer nobody is listening.
6. Test with the cases the team already finds difficult, and train on the rules rather than the buttons.
7. Name an internal owner before go-live. Without one the configuration and the business drift apart until someone proposes buying a different CRM.