A quiet decline without a big bang
The rollout is complete. The CRM is running, the interfaces are in place, the licence invoice arrives on time. Since the project closed, the topic has dropped off the agenda.
Two years later, everyday work looks different. Sales keeps its own list because it is more up to date. Service would rather call a colleague than look in the system. New fields were added, old ones were never cleaned up. Nobody decided to use the system less. It just happened.
That is why this decline is so hard to pin down. There is no outage and no error message. The costs stay the same while the benefit falls.
Not every unused feature is a loss. It becomes critical when the core processes you bought the system for gradually move outside it. What matters is whether it still does what you introduced it for.
Three patterns that slowly bleed systems dry
A CRM loses its value in many small places, each of which looks harmless on its own. Three patterns come up again and again.
Workarounds next to the system
A field is missing, a screen is cumbersome, so the team builds itself a workaround. An example from mechanical engineering: the internal sales team keeps open quotes in a spreadsheet on the shared drive because they are quicker to sort there. The CRM holds the same quotes with an outdated status. Service sees the wrong picture and would rather call sales.
Each workaround is reasonable on its own. Together, they mean the system no longer shows the actual state of things.
Nobody is responsible
During the rollout there is a project team. After go-live it disbands. IT takes care of access, the vendor takes care of the software. Who decides on mandatory fields, duplicates and processes is left open.
At a wholesaler, the same customer appears three times in the system, each time with a different contact person. Sales, accounting and marketing all know about it, and each department thinks another one is responsible. With every new entry, the clean-up gets harder.
Old processes in the new tool
The third pattern is the least noticeable. During the rollout, existing processes are rebuilt as faithfully as possible. That feels safe. But it also means that steps survive which only existed because the old system or paper required them.
At a service company, a complaint used to go through a form that was printed, signed and filed. In the new system, there is a digital approval for it with exactly the same stages. The customer waits just as long as before; only the software costs more.
In all three cases, the tool works. One example is email flows that fell silent after a system change.
Why this is a design problem, whatever the tool
When a system loses value, people usually look for the cause in the tool: too complicated, too old, set up wrongly. So a new one is introduced and people are trained on it. Two years later, the spreadsheet is back next to the CRM.
What was introduced was the software. Nobody designed the operations around it.
This observation is not new. As early as 1990, the Harvard Business Review described why IT so rarely delivers big leaps in performance: companies use it to speed up outdated processes instead of getting rid of them. In 2002 the same journal applied this to CRM. The fundamental mistake, it said, is the assumption that CRM is software that manages customer relationships. What CRM really means is customer strategy and processes; the technology only supports both.
More recent figures fit the picture, but they measure something other than CRM value loss. In Gartner's marketing technology survey, marketing leaders said in 2023 that they use only 33% of the capabilities of their marketing software on average. In 2022 the figure was 42%, and in 2020 it was still 58% (analysis of the Gartner figures, August 2023). The values are based on self-assessment. The martech analyst who analyses them there regards them as closer to gut feeling. He sees the main cause in teams lacking enablement (training, support, reference material) rather than in the tools. He considers unused secondary features unproblematic as long as the core features pay off.
What does "designing the operations" mean? We call it operational design. For every important process, it answers four questions:
- Who does what? One named role per process and per data area. "IT" and "the vendor" do not count.
- With which data? What information does each step need, where does it come from, who keeps it up to date?
- When? What triggers a step, when does a case move from sales to service, and what must be in the system at that point?
- How do you know it is working? A few signals, defined in advance, that someone checks regularly.
Switching tools answers none of these questions. The new system inherits the open points, often along with the old processes. If you have answered the four questions, on the other hand, you can decide objectively whether the existing system is good enough. A switch is then a considered decision and no longer a way of running from the problem.
Pressure tests: checking before the launch and afterwards
A system loses its value during day-to-day operation, so that is also where it has to be checked. We propose two checks for this, which we call pressure tests. Your IT clarifies whether the software runs. The pressure test clarifies whether your people work with it as planned.
Both tests use the same five test questions. The pre-launch test records before the rollout what the answers should be. At its core it checks three things: processes (test questions 1 and 3), roles (test question 2) and data flows (test question 4). Test question 5 defines how you will later recognise whether the system creates value. If an answer is "we'll sort that out after go-live", you have found a real gap.
A good format for this is the premortem, which the Harvard Business Review described in 2007. The team assumes the project has already failed and collects plausible reasons why. That way, doubts come to the table before the launch. For a CRM it sounds something like this: "A year after the rollout, sales is back to keeping its contacts in Excel. Why?"
The post-launch test then checks at fixed intervals what the answers actually are. This is exactly the test that many companies lack, because attention moves on to the next project after go-live. Where target and actual diverge, you need to act. You don't need a BI team for that. A fixed date and honest answers are enough.
If your system has been running for years, start directly with the post-launch test and define the target state retrospectively in the first round.
Test question 1: Where do your teams work around the system?
Workarounds rarely come from defiance. They come about because someone has to get a task done and the system gets in the way. Practitioners call this "shadow CRM": parallel lists that are more up to date and more trusted than the actual system.
How to recognise it
- Meetings report from a spreadsheet instead of the CRM.
- "Where does that stand?" is followed by "My colleague has that, I'll ask".
- Customer emails land in personal inboxes and get forwarded.
- After a holiday or a change of job, knowledge about ongoing customers is missing.
- The CRM gets updated just before monthly reporting.
What it costs
Duplicate work, because information is entered twice or transferred later. Lost customer information, because service cannot see what sales promised. And a false picture in the figures, because reports from the CRM only describe the part of the business that happened to be maintained there.
Workarounds show where the operations were never designed.
What you can check in practice
- Without any blame, have two people each from sales and service show you where they actually manage their customers. Every spreadsheet and every forwarding rule goes on the list.
- Follow a customer enquiry from last week: are receipt, reply, commitments and next step all fully in the system? Every gap points to a workaround.
- For each workaround, ask: what can the spreadsheet do that the system can't? The answer is often smaller than expected, such as a missing field or an unclear rule.
Test question 2: Who is responsible for which process, by name?
If you ask who is responsible for the CRM, you usually hear "IT" or "the vendor". Both answers fall short. Neither decides when an enquiry counts as promising, who hands a customer over to service or which details are mandatory. Yet exactly these decisions determine whether the system creates value. They belong in the business.
What "responsible" means in practice
Responsibility has two levels. For each process, such as new enquiries, handover to service or complaints, you need a role that defines how it works and changes it when it falters. For each data area, such as contact data or quote status, you need a role that answers for completeness and accuracy. That person does not make every entry themselves but is accountable for the rules.
"Named" means there is a person behind the role whom everyone knows. A committee is not enough. In mid-sized companies, this is rarely a full-time position, usually a clearly defined part of an existing role, such as the head of sales. It needs time blocked in the calendar.
The test
At your next management meeting, ask a question about a failure in the lead process: an enquiry from a potential customer sits in the system and nobody gets in touch. Who decides what happens now? And who changes the process so it doesn't happen again?
If every manager names the same person without hesitation, responsibility is settled. If the room goes quiet or different names come up, you have found a gap. In daily work it rarely shows. It only becomes visible when something goes wrong, and then people look for someone to blame instead of a solution.
Before and after the launch
Before the rollout, set up a simple table: core processes and data areas in the rows, the responsible role next to them. Every empty cell is an open decision. After the rollout, check the same table regularly, because people leave and roles change.
Test question 3: Did you rethink your processes or just move them?
In many rollouts, the brief is: the new system should be able to do everything the old one could. Then every step, every mandatory field and every approval is carried over, including those that only existed because the old system couldn't do any better. This is exactly what the articles from 1990 and 2002 mentioned above warned against.
How to recognise a process that was just moved
- A quote is created in the CRM but goes out for approval as a PDF by email, because that is how it used to work.
- The same customer data is entered in two places, because there used to be two systems.
- There are mandatory fields whose content nobody analyses.
- Handovers run via export and list, even though the system could map them directly.
- There are approval levels whose reason nobody remembers.
Each of these steps costs time and is a reason to work around the system.
How to check it
- Pick a process your customers feel directly, for example from enquiry to quote.
- Sketch it from scratch, from the customer's point of view, on a blank sheet: what does the customer need and when, which information must be available where, who has to act?
- Put the current state next to it, every click, every handover, every waiting time. Do this with someone who runs the process every day, and leave the project documentation aside.
- For every step that only appears in the current state, ask: who benefits from this? If the only answer is "we've always done it this way", it goes on the list of things to cut.
Some steps have legal or internal reasons. What matters is that someone can name the reason. Test question 2 settles who decides what gets cut. Before the rollout, that means sketch first, then configure. Afterwards, it means doing the comparison on one process before you think about another tool.
Test question 4: Do your people trust the data in the system?
Data quality sounds like an IT topic. In daily work, it shows in behaviour. Does your sales team look in the CRM before a customer call, or would they rather ask a colleague in service? If your people prefer asking to looking it up, the system counts as an archive and nobody treats it as the basis for their work.
The problem reinforces itself. People who don't trust the data don't maintain it carefully, and that makes it even less reliable. New employees then quickly learn whom they have to ask, instead of where they can look things up. Who is responsible for which customer data can be recorded on one page in a data ownership mapping.
How to recognise it
- Before customer meetings, people ask around internally, even though the information should be in the system.
- Contact persons and phone numbers are out of date, and nobody corrects them.
- The last customer contact is missing from the system, even though it took place.
- Meetings turn into arguments about figures, because everyone brings their own instead of the CRM's.
A spot check without a data department
You need one hour and two people.
- Randomly pull 20 customer records with contact in the last four weeks.
- Have the person who looks after each customer check every record: are the contact person and contact details correct? Is the last contact recorded? Is the current status clear?
- Show three records to someone who doesn't know the customer. Could that person have a meaningful conversation tomorrow?
- Ask the team: when did you last call someone before a customer contact instead of looking in the system? And why?
The result is no exact metric, but it is an honest picture. The last question usually also reveals the reason: missing fields, unclear responsibility (test question 2) or processes that bypass the system (test question 1). Repeat the spot check after the launch, and you will see whether trust is growing or quietly fading.
Test question 5: How do you know the system creates value?
CRM systems produce reports in large numbers: logins, contacts created, dozens of dashboards. Hardly any of them answers whether the system brings the company anything. The share of features used is no yardstick either, as the self-assessments above show. So ask which processes the system is supposed to improve, and whether that is happening.
Three to five signals everyone understands
Good signals describe everyday work. Examples:
- Handovers without follow-up questions: after a handover, service finds everything it needs in the system and doesn't have to call to find out what was promised.
- Enquiries land in the system in full; none sits only in a personal inbox.
- Before a customer meeting, your people open the system instead of asking colleagues (test question 4).
- There is no second list that is more up to date than the CRM for any customer.
Hardly any company needs more than five signals.
Define beforehand, check afterwards
Define the signals before the launch, together with the people who work with the system, and record where things stand today. Otherwise you will have no comparison later, and every assessment remains opinion. After the launch, check with spot samples: a few recent handovers, a few enquiries from the last few weeks. How to plan the proof of return before launch is covered in a separate article.
If a signal deteriorates, it shows which process, which responsibility or which data source needs sharpening.
How to set up the check in your company
The five questions only help if they are asked regularly and something follows from the answers. You need one responsible person, a fixed date and a rule for what happens with the results.
Who asks the questions
Choose someone from operations who knows sales and service, for example the head of operations. This person collects the answers and brings them to the management meeting. The answers themselves should come from the people who work with the system every day. If you only ask managers, you learn how the system was meant to work. How it is actually used, you won't find out.
How often
Our suggestion:
- First check a few weeks after the launch, while workarounds are still easy to spot.
- After that, once a quarter, attached to an existing meeting.
- Additionally when things change, such as new teams or a larger adjustment to the system.
Shorten the interval if too much has shifted between two checks.
How answers turn into corrections
Every finding gets an action, a responsible person and a date. Take on no more than two or three corrections per round; anything more gets lost in day-to-day business. Often an additional field, a named role or a step that gets cut is enough. Every new round starts with the question of whether last time's corrections have worked.
Not every gap has to be closed. Focus on the processes that customer contact and revenue depend on. There, small, regular corrections achieve more than a big overhaul every few years.
Conclusion: value comes from operations after the rollout
A system is only as good as the operations designed around it. Take the five test questions to your next management meeting:
- Where do your teams work around the system?
- Who is responsible for which process, by name?
- Did you rethink your processes or just move them?
- Do your people trust the data in the system?
- How do you know the system creates value?
Wherever the answers hesitate or contradict each other, you have found your first starting point. If you would like an outside view for this, our Reactivation Audit is one possible way in.
Frequently asked questions
How can I tell that our CRM is losing value even though it runs flawlessly from a technical point of view? By how it is used: spreadsheets next to the system, forwarded emails instead of entries, colleagues who would rather call than look it up, and handovers that only work with follow-up questions.
What is a pre-launch or post-launch pressure test, and how long does it take? The pre-launch test defines the target answers to the five test questions before the rollout; the post-launch test then regularly checks the actual state. How long it takes depends on how many processes you check.
Do we need a new tool if everyday use is declining? Usually not. A new tool takes over missing responsibilities and unresolved processes one to one; first answer the four questions of operational design.
Who should be responsible for running a CRM in a mid-sized company that has no dedicated CRM team? One named role per process and per data area, for example the head of sales for the lead process. Management sets these responsibilities and makes them known.
How often should we check after the rollout whether the system still creates value? Roughly once a quarter, attached to an existing management meeting. A fixed date matters more than the frequency.
Can we apply the five test questions to a system that has been running for years? Yes, especially there, because workarounds and unclear responsibilities have become entrenched. Start with the post-launch test and one core process.