Change & Adoption
Go-live is where adoption starts, not where it ends.
I design the routines, ownership, enablement and feedback mechanisms that turn a new commercial system into the way the organization actually works.
Five phases with go-live inside them, not at the end. Read them as a project plan—where work stops at go-live—or as an adoption design, where the system goes on to be used, trusted, managed through and improved.
Adopt
Management reviews run from the system; the temporary bridges are frozen; bypasses are visible.
- Owner
- Business owner and line managers
- Signal it is working
- Reviews run from system evidence; bypasses fall
- If this phase is skipped
- The system is live; the business still runs somewhere else
Training explains the system. Adoption changes how the business operates.
Adoption is the transition from a designed operating model to an actual working habit—so it is designed with the process, the roles and the management routines, not added after them.
Number of loginsTraining attendanceA launch emailMandatory fieldsAsking users to stop complainingForcing people into a system that gives them nothing
- Role-level valueEach role gets something from the process it is asked to feed.
- Management behaviourManagers review, decide and follow up from the system.
- Process complianceWork moves through the intended states and decisions.
- Tool rationalizationParallel trackers are classified, replaced and retired on a date.
- Clear ownershipSomeone owns adoption, the process and the platform after go-live.
- Useful dataData entered is data used—by the person entering it or a named decision.
- Measurable frictionWorkarounds are recorded, classified and owned.
- ReinforcementReviews, recognition and targets reward the designed behaviour.
- ImprovementWhat users struggle with changes the design, release by release.
- 01People adopt what their managers inspect.
The system people use is the system management runs the business from.
Management cadence - 02A parallel spreadsheet is often a signal, not just a discipline problem.
Find out what it does before deciding when it stops.
Parallel tools - 03Login is not adoption.
Measure whether work and decisions move through the process.
Adoption measurement - 04Repeated workarounds are architecture signals.
Friction is design feedback before it is a discipline issue.
Friction loop
From designed model to working habit.
Nine moves that treat adoption as design work. The first four happen before go-live and decide whether the new process is worth following; the last three decide whether it keeps getting better once the project team has left.
01Understand the role
What does this role actually need to achieve?
Start from the person’s week, not from the system’s screens.
- Goals
- Decisions
- Current tools
- Workarounds
- Pain
- Incentives
A workaround people rely on is a requirement nobody wrote down
Understand the role
What does this role actually need to achieve?
Start from the person’s week, not from the system’s screens.
- Goals
- Decisions
- Current tools
- Workarounds
- Pain
- Incentives
Role profileA workaround people rely on is a requirement nobody wrote down
Define role-level value
What does the new process give this person?
Value stated from the user’s side, not the reporting side.
- Less manual coordination
- Clearer customer context
- Faster decisions
- Fewer duplicate tasks
- Better prioritization
Role-value mapIf the new process only creates value for reporting, users will experience it as administration
Remove unnecessary work
Which fields, steps and duplicate activities can disappear?
Adoption improves when the design asks for less.
- Data already available
- Derivable values
- Automation
- Obsolete tasks
- Parallel reporting
Friction-reduction backlogMandatory data does not guarantee good data
Align management routines
Which meetings and decisions must run from the new system?
People adopt what their managers inspect.
- Pipeline review
- Forecast
- Customer performance review
- Recovery review
Management cadenceIf the management meeting happens outside the system, the operating system is outside the system
Enable real work
What must each role be able to do on day one?
Real task + real decision + real process—not screens.
- The scenario
- The decision
- The action
- Where it happens in the system
- What happens next
Role-based enablement planTraining cannot repair incentives that make the system irrational to use
Retire parallel tools
What old behaviour must stop?
Each parallel tool is classified before it is retired.
- Spreadsheets
- Duplicate trackers
- Shadow CRM
- Local reporting files
- Manual approval sheets
Tool-retirement planA parallel spreadsheet is often a signal, not just a discipline problem
Measure real adoption
Is the process actually being followed?
Login is not adoption.
- Process completion
- Stage compliance
- Required decisions
- Management usage
- Data used in decisions
- Bypass behaviour
Adoption scorecardA signal without an owner and an action is only a chart
Capture friction
Where is the design making work unnecessarily difficult?
Repeated workarounds are architecture signals.
- Repeated manual steps
- Workarounds
- Unused fields
- Slow approvals
- Confusing states
- Missing automation
Friction registerA deviation is design feedback before it is a discipline issue
Improve
Who owns changes after go-live?
Go-live is a handoff, not an ending.
- Process and product owner
- Backlog
- Release cadence
- Governance
- Review
Continuous-improvement loopWhen the project closes, ownership must not close with it
The system is live. The business runs somewhere else.
These are rarely training problems. Underneath, a role gets nothing back, a manager reviews from a file, or nobody owns the process after go-live.
The CRM is technically live, but managers still review the business from spreadsheets.
Usually missingA management cadence that runs from the systemSalespeople enter data nobody uses—including themselves.
Usually missingRole-level value and a named decision per fieldTraining explains screens instead of the decisions people make.
Usually missingEnablement built on real scenariosMandatory fields fill up with placeholder data.
Usually missingFewer, derived and conditional fields—used where they are enteredLocal trackers quietly recreate the old operating model.
Usually missingA classified inventory of parallel tools with retirement datesAdoption is reported as login counts.
Usually missingSignals for process compliance and management useUsers build workarounds because the process is too slow.
Usually missingA friction register feeding a governed backlogOwnership ends when the project closes.
Usually missingNamed process, platform and adoption owners after go-live
Artefacts that make a new model the normal way of working.
Each one replaces an assumption—“they will use it once trained”—with something that can be owned and checked.
- Role-value mapWhat each role gives, gets, decides—and should not have to do
- Role & ownership modelWho uses, manages, owns and supports the new process
- Adoption hypothesisWhich behaviour should change, for whom, and how we will see it
- Role-based enablementScenario → decision → action → system → outcome, per role
- Champion modelLocal context and feedback—without taking over ownership
- Management cadenceWhich reviews run from the system, with which evidence
- Tool-retirement planEach parallel tool classified, frozen and retired on a date
- Rollout planWaves sequenced by readiness, not only by calendar
- Compliance modelWhich states, decisions and evidence the process requires
- Adoption scorecardFrom access to operating-model adoption, each signal owned
- Friction registerFriction, cause, type and action—as design feedback
- Post-go-live backlogPrioritized changes with an owner and a release
- Governance modelWho may change the process, the platform and the rules
- Continuous-improvement loopUse → measure → friction → prioritize → change → release
- Adoption review cadenceWho reviews the signals, when, and what they decide
If a role only gives, the data goes stale.
Six roles, four questions each. Switch to the reporting-first design to see what most rollouts actually ask of people.
Sales rep
- Gives
- Opportunity state, next step, customer context
- Gets
- A complete account view, prioritized work, less manual coordination
- Decides
- The commercial next action
- Should not have to
- Re-enter ERP data by hand
What this role gives comes back as something it uses. That is why the data stays current.
People adopt the operating model their managers actually use.
If the management meeting happens outside the system, the operating system is outside the system. The same review, run two ways:
- CRM dataCurrent, owned, visible to everyone in the review
- Management reviewHeld on the shared pipeline view
- DecisionRecorded where the work is
- ActionA task with an owner and a date
- CRM updateNext week’s review starts from this week’s decisions
Every decision leaves evidence in the system, so updating it is worth the effort.
Routines that must run from the system
| Routine | The question | Evidence in the system | What changes when it moves in |
|---|---|---|---|
| Weekly pipeline review | Which deals need help this week? | Stage, next step, age in stage, last activity | Stale deals and missing next steps become visible to the rep before the meeting |
| Forecast call | What will we close, and what would change it? | Forecast categories, overrides with reasons, coverage | Overrides are recorded, so judgement becomes reviewable |
| Customer performance review | Which customers are growing, slipping or silent? | Segments, targets and actual, recent activity | Account plans and recovery actions live next to the account |
| Recovery review | Is each recovery plan working? | Recovery actions, owners, due dates, outcome | A plan without a next action is visible as such |
Enablement follows real work, not screens.
Day-one readiness per role, rehearsed on the scenarios people will meet on Monday.
- “Click Accounts.”
- “Click New.”
- “Complete these fields.”
- “Click Save.”
Explains the system. Nobody leaves knowing what to decide.
“A customer requests a quote. What do you do? What decision are you making? What information is required? What happens next?”
Real task + real decision + real process. The screens appear where the work needs them.
A customer asks for a quote on a new product line.
Is this a new opportunity or part of an existing one—and is the price within my authority?
Create or update the opportunity and request the quote.
Opportunity → quote request; the price check runs on submit.
The quote reaches the customer, or the approval goes to the right person with the reason.
A parallel spreadsheet is often a signal, not just a discipline problem.
Retiring a tool starts with finding out what it does. Some reveal a missing capability; some are legitimate analysis; some are habit. Each gets a verdict and a date.
- CRM
- Spreadsheet pipeline
- Local tracker
- Manual forecast
The CRM is one of four places the truth might be.
- CRM
- A temporary, controlled bridge
One bridge, owned, with a freeze date.
- CRM
- Governed analytical tools
Analysis continues—on governed data, not on copies.
- 01Discover
Find every tracker, file and side system people rely on—and who uses it for what.
- 02Classify
Decide per tool: required temporarily, replaced, integrated or retired.
- 03Migrate
Move the legitimate value—views, fields, routines—into the operating model.
- 04Freeze
The old tool becomes read-only on an agreed date; exceptions need an approver.
- 05Retire
Archive it, remove access and watch the bypass signals.
Classify before you retire
Weekly pipeline spreadsheet
- Purpose
- The manager’s Monday review
- What it reveals
- No CRM view supports the review cadence
- Verdict
- Replaced
- Action
- Build the review view; run two reviews in parallel; freeze the file
- Owner
- Sales manager
- Required temporarily
- Replaced
- Integrated
- Retired
Login is not adoption. Measure whether the process is followed.
Six levels, from access to improvement. Most adoption reports stop at the second. Select a level to see what it shows—and what it misses.
Management adoption
Are decisions made from system evidence?
- Signal
- Reviews run from the system, decisions recorded against records
- If you stop measuring here
- Managers may still keep a private copy
Adoption signals
Each signal has an owner, a meaning and an action. No universal thresholds: what is good depends on the process and the unit.
| Signal | Level | Owner | Meaning | Action |
|---|---|---|---|---|
| Opportunities with a valid next action | L2 · Process compliance | Sales manager | Deals are being worked, not only recorded | Review the ones without a next action in the weekly pipeline review |
| Stage ageing | L2 · Process compliance | Sales manager | Where work waits—or where stages are not updated | Help, escalate or requalify stale deals |
| Records bypassing the expected lifecycle | L2 · Process compliance | Process owner | The process is skipped, or does not fit | Classify the bypass: design friction or discipline |
| Management reviews run from the CRM | L3 · Management adoption | Business owner | The operating system is inside the system | Move the next routine; retire its spreadsheet |
| Parallel spreadsheet usage | L4 · Operating-model adoption | Adoption owner | A capability is missing, or a habit remains | Classify the tool; freeze it or fix the gap |
| Records with no owner | L2 · Process compliance | Data owner | Work nobody will act on | Assign by rule; fix the rule, not only the record |
| Task completion | L3 · Management adoption | Line manager | Decided actions are followed through | Review overdue actions in the next review |
| Exception volume | L2 · Process compliance | Process owner | Where the design and reality disagree | Feed recurring exceptions to the friction register |
| Reopened process states | L2 · Process compliance | Process owner | Handoffs that fail on the first attempt | Fix the entry criteria of the receiving stage |
| Data used by downstream decisions | L3 · Management adoption | Data owner | Fields that earn their place | Remove or derive fields no decision uses |
Repeated workarounds are architecture signals.
Friction is recorded with its cause and type, and handed to the owner of whatever causes it—so the next release removes it instead of the next reminder.
- “Users re-enter the customer address.”
ERP data is not available in the working context.
System / integration
Expose the authoritative data where the work happens.
- “Managers export the pipeline every Monday.”
No CRM view supports the review cadence.
UX / operating model
Design a review workspace for the routine.
- “Small discounts wait days for approval.”
One threshold for every deal size.
Process
Tier the approval by amount; approve small ones by rule.
- “Most records carry a placeholder in a mandatory field.”
The value is unknown at that stage.
Data
Make the field conditional on the stage where it is known.
- “Reps log activities on Friday afternoons in bulk.”
Recognition counts activities, not outcomes.
Policy / incentive
Review what is recognized; stop counting activities.
The continuous-improvement loop
- Support tickets
- Usage signals
- Process exceptions
- Manager feedback
- Adoption measures
- Business changes
- 01Use
- 02Measure
- 03Friction
- 04Prioritize
- 05Change
- 06Release
Use
One list, prioritized by the process owner, released on a cadence.
Roll out by readiness, not only by calendar.
Seven factors decide whether a unit pilots, prepares or waits. Select a unit: the outcome follows from its scores.
Engaged team; data needs cleansing and one local variation is undecided.
- Process readinessReady
- Data readinessPartially ready
- Management sponsorshipReady
- User readinessPartially ready
- Local variationPartially ready
- Integration readinessReady
- Support capacityReady
Targeted preparation on the partial factors, then deploy
The global rollout pattern
Global rollout is standardization plus local readiness plus controlled learning—the core is designed once, learned from, and changed between waves.
Standardization+Local readiness+Controlled learning
- 01Core design
Lifecycle, roles and routines designed once
Standardization - 02Pilot
One ready unit, with the project team present
Controlled learning - 03Learn
Friction and signals from the pilot change the core
Controlled learning - 04Adapt controlled variation
Registered local differences only
Standardization - 05Deploy by unit
Waves sequenced by readiness
Local readiness - 06Stabilize
First weeks supported locally, bridges frozen
Local readiness - 07Measure
Adoption compared by level, read in local context
Controlled learning - 08Improve
A governed backlog shared across units
Standardization
Who owns the system after the project?
Every responsibility the project held needs an operating owner before go-live—otherwise the adoption curve flattens the month the team leaves.
Project team→Named operating owners
- Process owner
Owns The end-to-end process, its states, rules and exceptions
Not How the platform implements them
- Platform owner
Owns Configuration, releases, support and technical health
Not Business rules and priorities
- Data owner
Owns Definitions and quality at the source, per concept
Not The reports built on top
- Adoption owner
Owns Adoption signals, enablement and the friction register
Not The fixes—those go to the owner of what causes the friction
- Business owner
Owns The outcome, the management cadence and reinforcement
Not Configuration choices
- Local champion
Owns Local feedback, first-line support, context and interpretation
Not Process or system decisions—those escalate
Champion ≠ process owner ≠ system owner
A champion is not the person who attended more training. Champions bring local context and feedback; formal ownership stays with the process and platform owners.
- Local champion
- Local feedback
- First-line support
- Process interpretation in context
- Escalation
- Reviewing local adoption signals
Does not Decide the process or change the system
- Process owner
- Owns the process design
- Decides changes and exceptions
- Owns process KPIs
Does not Configure the platform
- System owner
- Owns configuration and releases
- Implements approved changes
- Keeps the platform healthy
Does not Decide business rules
Six rollouts, one question: does the new way stick?
Synthetic global B2B scenarios. Two existing cases are read here through the adoption lens; four new cases cover parallel trackers, a multi-subsidiary rollout, mandatory fields and ownership after go-live.
- Case 01Selected workShadow-tool inventory & retirement
Moving a commercial team from parallel trackers to CRM
The team has a CRM, but daily management still depends on spreadsheet trackers, local customer files, offline forecasts and manual reporting.
What does each tracker do that the CRM does not—and what must move, change or stop before the team works from one system?
CRMSpreadsheets (retiring)Analytics toolCollaboration toolsRevenue OperationsDigital Operating Model - Case 02Readiness, waves & champions
Designing adoption for a multi-subsidiary CRM rollout
A global CRM is deployed across subsidiaries with different maturity, roles, historical processes, data quality, local tools and management habits.
How do we balance the global standard with local readiness—so each subsidiary adopts the same model without the rollout ignoring where it starts?
Global CRMLocal ERPsLocal trackers (retiring)Data platformDigital Operating ModelSystems & CRM Architecture - Case 03Operating-model case · adoption lensRoutines moved in, tools retired
Moving from CRM tool to commercial operating platform
The CRM is implemented, but managers run the business from spreadsheets and each team reads the stages its own way.
Which routines, ownerships and parallel tools decide whether the business operates through the CRM—or around it?
CRMSpreadsheets (retiring)Data platformCollaboration toolsDigital Operating ModelRevenue Operations - Case 04RevOps case · adoption lensManagement adoption
Running commercial management cadence from the CRM
Sellers are asked to keep the CRM current, but every management meeting runs from spreadsheets—so the system is maintained for nobody.
Which management forums must run from the CRM—and how do we know they do?
CRMData platformCollaboration toolsRevenue OperationsDigital Operating Model - Case 05Field audit & role value
Replacing mandatory fields with data people use
To force adoption, most opportunity fields were made mandatory. Records are complete—and full of placeholder values nobody trusts.
Which data does each decision actually need—and how do we get it without asking people to type what they do not know?
CRMERPData platformProcess ArchitectureData & Integrations - Case 06Ownership handoff & friction loop
Keeping adoption owned after the project team leaves
The project team disbanded at go-live. Support tickets pile up, workarounds spread, and nobody is accountable for whether the new process is followed or improved.
Who owns adoption, the process and the platform after the project—and how does what users struggle with change the design?
CRMSupport deskChange backlogData platformDigital Operating ModelAutomation
Every adoption request has a second layer.
The visible request is where the design starts, not where it ends.
“Users need training before go-live.”
Run screen-by-screen sessions for every user.
4 of 5 questions surfaced
Day-one tasks per role, not a tour of every screen.
Adoption is not a phase after the design. Every capability shapes it.
Change & Adoption
- Digital Operating Model
The operating model defines roles, decisions and ownership; adoption turns them into working habits.
- Process Architecture
A redesigned process exists only once people work that way—so role value is designed with the process.
- Revenue Operations
Management routines are where adoption is won or lost; the commercial cadence runs from the system.
- Systems & CRM Architecture
A platform that fits the way people sell is adopted; one that encodes the org chart is worked around.
- Data & Integrations
Re-entered data is friction; authoritative data in the working context removes it.
- Automation
Removing manual steps is part of adoption design—automation takes work away before training explains it.
Architecture decisions
Cases & writing
Adoption is not training, communication or login counts. It is the designed transition from operating model to working habit:
- Role value
- Management routines
- Enablement
- Tool retirement
- Measurement
- Friction
- Ownership
- Improvement
Design adoption into the solution, so the new model becomes the normal way of working.
Go-live is where adoption starts, not where it ends.
Live on schedule—and still running on spreadsheets?
- Which management review still runs outside the system?
- What does each role get back from what it enters?
- Who owns the process now the project has closed?