A CRM loses money when it does not reflect the real process

A CRM can be rolled out and still not work, if its statuses do not match what the team actually does.

A typical conversation about CRM goes like this: the system is bought, configured, the sales team works in it — and nobody can say how many deals are genuinely in progress or where they are stuck. Formally everything is rolled out. In practice the process lives elsewhere.

The cause is almost always the same: the funnel was drawn from how things should be rather than how they are. The statuses came out handsome and unusable, the sales team learned to set whichever one avoids an argument with the system, and the data lost its connection to reality.

Why a CRM becomes an archive

A system turns into a contact archive gradually. First someone does not get round to logging a call. Then the status “in progress” starts meaning anything from “we picked it up” to “the client has been silent for three weeks”. Then the manager stops trusting the report and asks for numbers out loud at the stand-up.

From that point the CRM runs empty: the data gets entered because someone said so, while decisions are taken from other sources. The worst part is that you cannot see it from the interface — every field is filled in.

You can check this in half an hour. Take a dozen deals in progress and ask the salesperson what is really happening with each. If the account regularly differs from the record — not in details but in substance — this is not about discipline. It means the system asks for actions the team does not perform.

How to describe the funnel

A funnel is described from actions, not from imagination. For each stage you answer three questions: which action moves a deal into it, who performs that action and what should happen next. If there is no answer to the first question, the stage is redundant.

  • a stage is named after an action, not after a state of waiting
  • each stage has an owner and a next step
  • there is a separate path for a loss — with a reason, not just “closed”
  • there are as many stages as decisions the team actually makes

A good sign: looking at a record, a salesperson always knows what to do right now. If they have to recall a verbal agreement, the funnel is not fully described.

Loss reasons deserve a separate field and a short list: too expensive, not now, went elsewhere, not our profile, went quiet. Five or six options beat twenty — those get chosen honestly. A quarter later that list turns out to be the most useful report of all, because it shows where the company loses deals systematically.

Which automations are needed

What is worth automating in a CRM is what a person is obliged to do anyway but forgets. Create a task after a call. Follow up when the client goes quiet. Notify when a request has been unanswered longer than agreed. Pull the data from a site form so nobody retypes it.

Changing statuses automatically, on the other hand, is usually harmful: the system starts asserting things nobody did. Let the status remain a human decision, and let the automation make sure that decision is not missed.

Notifications are a trap of their own. Too many, and everyone stops reading them at once — and then misses exactly the one the whole thing was built for. The rule is simple: a notification is sent only when the recipient has to do something. Anything that is merely “for information” belongs in a report, not in an inbox.

What the manager should see

A manager needs not a report but an answer to “where is the problem right now”. In practice that is three things: how many requests sit at each stage, which have been waiting longer than they should, and which sources produce the deals that actually close.

All of that is calculated automatically, provided the stages reflect actions. If they do not, any analytics will display the inaccuracy beautifully, and no dashboard will fix it.

How not to overload the process

The opposite extreme is just as common: twenty required fields, fifteen stages, an approval for every action. The sales team starts filling records in from memory at the end of the day, and the data drifts away from reality again.

The rule that works is simple: make required only what the next decision cannot be taken without. Everything else is optional. What is worth checking is not how completely the fields are filled but whether the statuses match what is really going on.

The rebuild is easier in steps than all at once: first put the funnel in order and watch it for a month, then add the automation, then assemble the reporting. The team has time to absorb each step, and it stays visible which one produced what. Replacing everything simultaneously almost always ends with the sales team back in their old habits and the system half-configured.

Does the CRM disagree with what is actually happening?

Describe the path of a request from first touch to outcome, and where it stalls. We will work through the funnel, the redundant stages and the automations that are genuinely needed.

Show us your process