Practice / The Thinking · 06
Exercise 06 · The Thinking

The CRM Adoption Guide

Part One

The Scenario

Erik Sæther has run sales teams in maritime for most of his career. He joined Nordic Marine Systems as Chief Commercial Officer eighteen months ago, inheriting a team of twelve and a culture that distrusts process for its own sake. The company supplies navigation, automation, and connectivity systems to commercial vessels and offshore installations. The sales cycles are long, the relationships are dense, and most of the intelligence that actually drives decisions lives in the heads of individual sellers.

Three years before Erik arrived, the company attempted a CRM rollout. It was launched at a company meeting with a presentation from the vendor. By month three, sixty percent of the team had stopped updating it regularly. By month six, it was functionally abandoned. The information that had been entered was incomplete, inconsistent, and outdated. Management had dashboards with no useful data. Sellers had a system they did not trust and did not use. The project was not officially cancelled. It simply stopped.

Now the Board has signed a licence for a new platform. The Head of IT has been appointed implementation lead for the technical deployment. The rollout is scheduled ninety days from today. Erik has been told to ensure adoption. He has a mandate but not yet a method. He knows the technical deployment is not the risk. The risk is exactly what happened three years ago: a system that gets used for a month and then quietly stops being used.

He also knows something his predecessor did not articulate clearly enough. The previous failure was not a training problem, a change management problem, or a technology problem. The sellers stopped using the system because the system stopped being useful to them. What it asked of them, in terms of activity tracking, pipeline entry, and forecast updating, gave them nothing they could use to close a deal. The system was built for the reporting needs of management. The sellers experienced it as reporting work on top of their actual work. The trade was unfair. They opted out.

Erik has ninety days. This exercise is his planning process.

Part Two

Reflection

Question 01
Think about a CRM system you have worked with, either your own or one you have observed. What did it ask of the sellers who used it? What did it give them back? At what point did the exchange stop being fair?
Auto-saved as you type
Question 02
In your own organisation right now, what is your sellers' real attitude toward the system or process you use to track commercial activity? Not their stated attitude in meetings. What does their actual behaviour tell you?
Auto-saved as you type
Question 03
If the purpose of CRM is to help a seller prepare for tomorrow's call, not to report on last month's activity, what would your system need to contain? What would it need to surface without being asked? How far is that from what it currently does?
Auto-saved as you type
Part Three

Adoption Design Canvas

Design your CRM as a tool for sellers first. Use the four elements from the article to define what the system must contain to be worth their time.

Stage Clarity
What does each deal stage in your CRM actually mean? Not the label, but the criteria. What must be true for a deal to move from stage two to stage three? Can any seller on your team answer that question right now, independently and consistently?
Known and Unknown
What do your sellers currently record because they are asked to, versus what they would record because it helps them? Where does the system ask for information that does not yet exist and therefore cannot be entered honestly?
Stakeholder Map
Does your CRM capture who is actually involved in the customer's decision? Not just the primary contact. The full stakeholder landscape: who shapes the budget, who has veto power, who is the internal champion, who is the quiet opponent. Or is your CRM a record of who sellers have talked to?
Next Meaningful Action
For a deal currently in your pipeline, what does your CRM tell the seller to do next? Not "follow up." What specifically, with whom, by when, and why does it matter for this deal at this stage? Is that information in the system? Does anyone check it?
The Value Exchange
What will a seller in your team concretely get from using this system that they do not have today? Not reporting capability for management. Not pipeline visibility for the board. What does a seller, sitting alone at their desk preparing for a call tomorrow morning, gain from having this system and using it well?
Part Four

The Pitfall Checklist

  • Trap 01
    "We will make it mandatory."
    Mandatory without value does not create adoption. It creates the appearance of adoption: data entered to satisfy the requirement, not to capture useful intelligence. Ask yourself this honestly: if you removed the mandate tomorrow, would usage continue? If the answer is no, you do not have adoption. You have compliance. Compliance degrades the moment oversight relaxes.
  • Trap 02
    "We will train everyone on launch day."
    A training event is not an adoption strategy. Training covers how the system works. It does not address why a seller should invest time in it or what they will get back. Rollout events create temporary awareness and some initial activity. Durable adoption is built through the daily experience of the tool being useful. Those are different things. Do not confuse one for the other.
  • Trap 03
    "Adoption will improve once we have more data."
    This is the adoption paradox: sellers do not enter data because the system is not useful; the system is not useful because sellers do not enter data. Waiting for the loop to resolve itself is not a strategy. The loop only breaks when someone decides to make the system valuable to sellers first, before the data quality is good. That requires deliberate seeding of useful intelligence from the start.
  • Trap 04
    "The standard stages work fine."
    Standard stage names do not describe how your customers actually buy. If your stages do not map to real decision points in the customer's journey, your sellers cannot use them honestly. They estimate. The estimates compound. The pipeline becomes a number the board wants to believe and a number sellers know is wrong. Find out what your best sellers actually do between each stage, and build your stage definitions from that reality.
  • Trap 05
    "Sellers will see the value once they use it."
    This assumes value becomes apparent through use. It usually does not, unless value has been intentionally designed in before launch. Do not open the system and wait for adoption to emerge from the experience of using it. Define explicitly, before rollout, what a seller gains from using this system well. Then make that the opening message. If you cannot name the value, sellers will not find it on their own.
  • Trap 06
    "CRM is primarily a management tool."
    If sellers experience the system as existing primarily for management reporting, they will eventually behave accordingly. They will enter the minimum required to keep the pipeline review bearable. They will not bring the system into their actual commercial work. Durable adoption requires the opposite assumption as its foundation: the system exists to make the seller more effective, and management gets useful data as a consequence of that. Not the other way around.
Your Honest Assessment
Which of these traps is your organisation most at risk of falling into right now? What evidence are you already seeing, and what will you do differently because of it?
Auto-saved as you type
Part Five

The First Thirty Days

This is not a project plan. It is a philosophy for sequencing. Before your first training session, before your first dashboard, before you communicate anything to the team about adoption expectations, there are three things that must happen first.

01
Map your best seller
Sit with the seller who closes most consistently and ask them to walk you through a deal from first contact to close. Not a summary. The actual sequence: what they learned, when they learned it, how they used it, and what they wish they had known earlier. That conversation is your design brief. Everything the system should contain is in that story. The system should make every seller as informed as your best one is naturally.
Auto-saved as you type
02
Seed three accounts fully
Choose three live accounts from your pipeline and enter them completely. Not as placeholders. Enter everything that is known: the full stakeholder map, the commercial triggers, the known and unknown factors, the next meaningful action and why it matters at this stage. Then sit with a seller and show them what a fully populated account looks like. Ask them: if you had this for every account in your pipeline, would it change how you prepared? Their answer tells you whether your design is right.
Auto-saved as you type
03
Write your success statement
Define in one sentence what success looks like for a seller who has used this system well for ninety days. Not for management. Not for the board. For the seller. What will they be able to do that they cannot do today? What decisions will they make faster, what conversations will they walk into better prepared, what deals will they see coming that they would previously have missed? If you cannot complete that sentence before launch, you are not ready to launch.
Auto-saved as you type
Export your work
Generate a PDF of your completed exercise. Includes your reflection, your adoption design canvas, your pitfall assessment, and your first-thirty-days commitments. Use it as the foundation for your rollout planning session.