Skip to content
InteliSense IT — Navigating Change, Delivering Value

Change, Adoption & Training

Go-live changes
the technology.
Adoption changes
the business.

New systemNew way of working

A new ERP, CRM or business application can be technically ready while the organisation is still operationally unprepared. People need to understand what is changing, why it matters, what they are responsible for and how the new process should work in real situations. That preparation needs to begin before training.

Explore the approach

A system is adopted when the new way of working becomes the normal way to get the job done.

Adoption friction is evidence. The cause may be the process, system, data, incentives, leadership, timing, training or user understanding.

Before labelling users as resistant, ask: do they understand why the change is happening? Does the new process actually work? Have their concerns been considered? Do they know what is expected? Have they had enough opportunity to practise? Is leadership behaving consistently with the new model? The response should depend on the cause.

In short

The adoption story, in about a minute.

Everything below this section is the detail behind these eleven points.

  1. 01Adoption starts during design, not at training.
  2. 02Define the business outcome and the behaviour that creates it.
  3. 03Understand who is affected, where they work and how.
  4. 04Leadership and process owners own the change.
  5. 05Involve representative users, not only the available ones.
  6. 06Build capability around real roles and real scenarios.
  7. 07Assess business readiness before go-live, separately from technical readiness.
  8. 08Measure the process behaviour after go-live, not the login count.
  9. 09Diagnose workarounds rather than blaming users.
  10. 10Reinforce, Optimise or Recover based on the evidence.
  11. 11Transfer capability so adoption survives project closure.

Not a go-live activity

Change starts when the future process starts being designed.

The people journey runs alongside the delivery sequence used on our implementations: design playback, then integrated CRP after build, then UAT. Capability building starts well before UAT, and UAT is not a substitute for training.

  1. Understand impact

    Which processes change, and for whom.

  2. Involve

    Representative users, at the decision points that matter.

  3. Design playback

    Validate the future process before more is built.

  4. Early capability

    Build understanding of the process, not the menus.

  5. Integrated CRP

    Representative process validation, in business context.

  6. UAT participation

    Some users prove the organisation can operate it.

  7. Role preparation

    Role-based end-user training, built on real work.

  8. Practise

    Safe repetition, including the exceptions.

  9. Go live

    Real work, with help close by.

  10. Hypercare

    Correct, clarify and reinforce on the evidence.

  11. Reinforce

    Managers make the new model the normal one.

  12. Measure

    Process behaviour, and the outcome it should create.

Representative users take part in CRP and UAT. Most end users do not, which is why role-based preparation and practice are planned as their own stages rather than assumed to happen inside testing.

The change model

Ten steps, sized to the organisation.

We do not force a branded change framework onto a project that does not need one. These are the steps that keep recurring.

  1. Understand the change

    What is actually different, process by process.

  2. Understand the people

    Who is affected, where they work and how.

  3. Define the impact

    Role, system, data, approval and reporting.

  4. Prepare leaders

    Before asking users to change anything.

  5. Involve users

    At the decision points where their view matters.

  6. Build capability

    Role-based training, built on the process.

  7. Practise

    In a safe environment, before production.

  8. Go live

    Real work, with help close by.

  9. Measure

    Behaviour and data, not login counts.

  10. Reinforce

    Managers make the new model the normal one.

Outcome first

Adoption is valuable only when the behaviour being adopted supports the business outcome.

Behaviour change on its own is not the point. The chain below is what connects a change programme to something the business can actually see.

  1. Business outcome
  2. Required behaviour
  3. Observable process signal
  4. Baseline
  5. Post-go-live evidence
  6. Intervention
  7. Business result

Illustrative examples, not customer results

  • Finance

    Better period discipline.

    Behaviour: Transactions, dimensions and approvals follow the agreed process.

    Signal: Late adjustments, manual journals and approval bypasses.

  • Warehouse

    More reliable execution.

    Behaviour: Receipts, picks, moves and exceptions are completed through the new process.

    Signal: Exception volume, unrecorded moves and stock corrections.

  • CRM

    A more credible pipeline.

    Behaviour: Stage progression follows qualification and next-action discipline.

    Signal: Stage age, missing next actions and forecast revisions.

  • Projects

    Better commercial control.

    Behaviour: Time, cost, forecast and risk information is maintained consistently.

    Signal: Timesheet timeliness, forecast currency and unbilled drift.

Baseline

Without a baseline, changed behaviour is harder to evidence.

Before intervening, establish what is actually true today where it can reasonably be measured. Where a number cannot honestly be obtained, a described position is still better than nothing.

  • The route the process actually takes today
  • Manual workarounds and spreadsheet use
  • Current support demand and repeated questions
  • Data completeness and process exceptions
  • How managers report and what they ask for
  • Current user confidence and internal training capability

What is changing?

People cannot adopt a change that nobody can explain clearly.

Change impact work exists to turn a programme statement into something a specific person can act on.

What tends to change, process by process

  • Process
  • Role
  • Responsibility
  • System
  • Data
  • Approval
  • Timing
  • Reporting
  • Control
  • Team boundary
  • Customer interaction
  • Supplier interaction

  • What happens today?
  • What happens tomorrow?
  • Why is it changing?
  • Who is affected?
  • What must they do differently?
  • People cannot adopt a change that nobody can explain clearly

What changes for me?

Different roles experience the same transformation differently.

Training that ignores this ends up teaching everybody the parts of the system they will never touch.

  • CFO

    New controls, reporting, approvals and period discipline.

  • Warehouse user

    New mobile process, location logic and picking sequence.

  • Sales user

    New qualification, CRM ownership and pipeline discipline.

  • Project manager

    New project controls, forecast, risk and commercial visibility.

  • Case worker

    New referral, action and case process.

  • Manager

    New exceptions, dashboards and decision responsibilities.

Reinforcement

Users notice what leaders tolerate.

Adoption follows the behaviour people see above them, not the messages they receive from the programme.

  • Explain why the change matters
  • Make decisions
  • Resolve conflicting priorities
  • Support agreed standardisation
  • Challenge workarounds
  • Attend key validation points
  • Reinforce expected behaviour after go-live
  • Leadership cannot delegate adoption entirely to the project team

Leadership cannot delegate adoption entirely to the project team.

Managers reinforce adoption through the operating questions they continue to ask: using the new reports, requiring the agreed workflow, stopping reliance on obsolete reports, supporting process owners, using the agreed controls and acting on exceptions through the new model. That is reinforcement, not policing.

Involvement

Involve the right people at the right decision point.

Representative users are not simply the easiest people to release from the business. They should represent the relevant roles, sites, shifts, experience levels and operating exceptions. Involvement is not consensus voting: decision accountability stays with named owners.

  • Executive sponsor

    Owns purpose, resolves conflict and reinforces publicly.

  • Process owners

    Own the future process, its policy and its exceptions.

  • Managers

    Own daily reinforcement and the questions they keep asking.

  • Subject-matter experts

    Own the detail others assume is already known.

  • Representative users

    Roles, sites, shifts, experience levels and operating exceptions.

  • Super users

    Local capability and feedback route, where that model fits.

  • Support

    Designs the week-one route and reads demand as evidence.

  • Internal trainers

    Carry capability beyond the project, where they exist.

  • External partners

    Included where the process genuinely crosses the organisation.

Clarity

Communication should reduce uncertainty, not create campaign noise.

People support changes more easily when they recognise how the decisions were made.

  • Why are we changing?
  • What will be different?
  • When?
  • What do I need to do?
  • What training will I receive?
  • What happens to the old process?
  • Where do I get help?
  • Who decides if something does not work?

Feedback

User feedback needs diagnosis before it needs a solution.

Communication that only broadcasts is not a change process. Feedback has to be classified, owned, acted on and turned back into knowledge.

  1. User feedback
  2. Classify
  3. Owner
  4. Action
  5. Outcome
  6. Knowledge

How feedback is classified

  • Training or knowledge
  • Process
  • Configuration
  • Defect
  • Data
  • Performance
  • Usability
  • Access or security
  • Change request
  • Policy or management

Not every issue belongs with training, and not every issue belongs with development. Defects, process changes and data problems route into the appropriate implementation, support, Recovery or Optimise workflow with a named owner.

Build capability

Train people for the work they need to perform.

Not a tour of the menus, and not one generic system overview delivered to everybody.

Teach the process. Use the software to practise it.

  • Role-based training
  • Process-based training
  • Scenario training
  • Manager training
  • Super-user training
  • Technical and administrator training
  • Support training
  • One generic system overview for everybody helps almost nobody

Prove the process

UAT is also an opportunity to build confidence.

Representative users execute real scenarios, see exceptions, understand roles, validate data, experience integrated processes and raise meaningful issues. Not every end user takes part, and UAT never replaces role-based preparation.

A user who participated meaningfully in UAT starts training from a different place.

The detail

Detailed adoption practice.

Open only what is relevant to your situation. Everything stays available to keyboard and screen-reader users.

Go-live readiness

Technical readiness and business readiness are different things.

Go-live needs both. One of them is usually assessed carefully. The other is often assumed. Training completion on its own is not a readiness measure, and we do not publish universal readiness percentages.

  • Environment, code and deployment

    People who know what they are doing

  • Integration proven in test

    Process owners who have signed off

  • Data loaded and reconciled

    Managers who understand their controls

  • Security roles configured

    Work instructions people can find

  • Defects triaged

    Support ready to answer week one

  • Cutover rehearsed

    Old routes being retired on a known date

  • Have critical user groups been trained?
  • Have process owners signed off?
  • Do managers understand their responsibilities?
  • Are super users ready?
  • Is support ready?
  • Are work instructions available?
  • Do users know where to get help?
  • Are old processes being retired?
  • Training completion percentage is not a readiness measure on its own

Old routes

Do not ask people to adopt a new process while the old one stays fully open.

Spreadsheets, an old database, a shared folder, email approval, a shadow CRM or a legacy ERP each need an explicit decision before go-live rather than a quiet assumption afterwards.

  • Operational use: does it remain usable, and for whom?
  • Historical access: does the information need to remain accessible?
  • Fallback: is it temporarily required for business continuity?
  • Access: who can still reach it, and with what permission?
  • Retirement: when is operational access removed?
  • Retention: what must be kept under organisational policy or applicable requirements?

Historic records and archive: Data Migration & Data Quality

Confidence gates

Adoption confidence should increase through evidence, not attendance.

Four decision points, using the same gate model as our implementation and delivery assurance work. Each one is a conversation with an honest outcome, including the outcome that says wait.

  1. Gate 1

    Before capability work begins

    Impact and ownership

    Adoption cannot be planned until it is clear what business outcome is wanted, which processes change and who owns the decisions.

    Confirmed at this gate

    • Business outcome and the behaviour it depends on
    • Processes changing, and how materially
    • Affected roles and user populations
    • Named sponsor and named process owners
    • Sites, locations, shifts and working patterns
    • What happens to the old processes
    • Major adoption risks, stated honestly

    Decision

    Proceed · Clarify process · Resolve ownership · Re-scope

  2. Gate 2

    Before end-user preparation

    Capability readiness

    Training built on an unstable process teaches people something they will have to unlearn. This gate confirms the conditions for building capability.

    Confirmed at this gate

    • Future process stable enough to teach
    • Representative users genuinely involved
    • Agreed training approach and delivery model
    • Trainers or super users prepared, where that model applies
    • Materials, work instructions and knowledge ownership
    • A practice environment with realistic data
    • Communication plan and support design

    Decision

    Proceed · Remediate · Delay preparation · Redesign

  3. Gate 3

    Go / no-go

    Go-live adoption readiness

    Business readiness is assessed separately from technical readiness, because a system can be deployable while the organisation is not yet able to operate it.

    Confirmed at this gate

    • Critical user groups prepared, by role
    • Managers understand their controls and exceptions
    • Process owners have signed off the future process
    • Super users ready, where that model applies
    • Support ready for week one, across shifts and sites
    • Work instructions available and findable
    • Users know where help comes from
    • Old-route decision made and communicated

    Decision

    Ready · Action required · Controlled deferral

  4. Gate 4

    Hypercare exit

    Stabilisation and adoption

    The last gate decides whether the organisation moves to normal operation, needs reinforcement, needs Optimise, or has a deeper problem that Recovery should address.

    Confirmed at this gate

    • Core processes being used as intended
    • Serious workarounds understood and classified
    • Material knowledge gaps controlled
    • Support demand stable enough for normal support
    • Managers reinforcing the intended operating model
    • Data and process trusted well enough to rely on
    • Improvement backlog classified and owned

    Decision

    Normal operation · Targeted reinforcement · Optimise · Recovery

After go-live

The first days of real use create information no test environment can reproduce.

Support requests are one of the earliest sources of adoption intelligence, if somebody is reading them as evidence rather than as a queue.

  • Daily issue review and critical user support
  • Process monitoring and defect triage
  • Data validation and integration monitoring
  • Knowledge updates and training reinforcement
  • Hypercare needs a clear entry, clear ownership and clear exit criteria

Explore Support

Adoption measurement

Measure whether the new process is being used, not only whether people logged in.

A user can log in every day and still export everything to Excel, run the real process through email, avoid updating CRM and maintain a shadow tracker.

Logging in is not adoption.

  • Process completion

    Is the work finishing in the new system, end to end?

  • Agreed workflow

    Is the approval path being used, or bypassed?

  • Workaround volume

    How much of the real process still lives outside.

  • Data completeness

    Are the fields the process depends on being populated?

  • Transaction quality

    Corrections, reversals and exception rates.

  • Support demand

    What people ask for, and how often.

  • Manager adoption

    Are managers using the new reporting and controls?

  • User confidence

    Asked directly, not inferred from a login report.

Adoption visibility should be management-level: role, expected process, actual usage, data completeness, workarounds, support demand, exceptions, old-route use, approval bypass and trend over time. We do not build a universal adoption score, because unrelated processes do not share one.

The evidence chain

Each important behaviour needs a signal, an owner and an intervention.

This is what turns adoption from an opinion into something a management team can act on, process by process.

  • Expected behaviour

    What should the user or manager actually do?

  • Signal

    What evidence shows the process is being followed?

  • Owner

    Who reviews it, and how often?

  • Baseline

    What happened before the change?

  • Trend

    What is happening now, over time?

  • Intervention

    What action follows if behaviour is not changing?

  • Outcome

    Did the intervention improve the process?

Measurement governance

Measure the process closely enough to improve it, not the individual more closely than the purpose requires.

Adoption measurement should not become surveillance-style employee scoring. Process, role and team-level evidence answers most business questions.

  • Process, role or team level answers most business questions
  • Trend matters more than a single reading
  • No universal adoption score across unrelated processes
  • Measure the process closely enough to improve it, not the individual more closely than the purpose requires

Understand before blaming

Workarounds are signals, not misconduct.

Shadow processes usually exist because somebody found the new route harder, slower or less trustworthy than the old one. Sometimes the workaround is serving a legitimate requirement nobody captured.

  • Spreadsheet stock records
  • Manual project forecast
  • Local customer lists
  • Email approval
  • Offline case tracker
  • Personal Power BI extract

Then classify the response

  • Train
  • Fix
  • Redesign
  • Optimise
  • Recover
  • Retain with justification
  • Retire

We do not automatically ban spreadsheets. Some are the symptom of a gap worth closing, and a few are a reasonable answer to a requirement the platform was never asked to meet.

Explore Data Migration & Data Quality

Shared responsibility

A partner can support adoption. It cannot own organisational behaviour.

The split should be explicit for each project, including who owns training content and knowledge after go-live.

  • InteliSense

    Design, guidance, training support, delivery, knowledge and hypercare.

  • Customer leadership

    Purpose, decisions, reinforcement and accountability.

  • Process owners

    The future process, its policy and its exceptions.

  • Managers

    Daily behaviour, and what they continue to ask for.

  • Users

    Execution and honest feedback.

Training responsibility, defined per project

  • Who creates training content?
  • Who delivers training?
  • Who updates it?
  • Who trains new starters?
  • Who owns knowledge after go-live?

Capability transfer

If only project participants understand the system, sustainable capability has not been built.

Before handover, adoption needs owners: for training material, process guidance, updates after system change, new-starter training, knowledge and FAQs, super users where they exist, the support route and the process itself.

  1. Learn

    People build capability around their real role.

  2. Own

    Named owners for process, content and knowledge.

  3. Maintain

    Material is updated when the system changes.

  4. Onboard

    New starters have a route to the same capability.

If managers keep asking for the old spreadsheet, users will keep producing it.

Managers need preparation in the new reporting, controls, exceptions, approval paths and decisions. New starters need onboarding content, role-based training, knowledge, a process owner, access and support long after the project has closed.

Context

The process needs to fit the environment in which the work actually happens.

Three work patterns tend to decide how adoption should be designed. Sector-specific detail, including public sector and care nuance, sits with the industry pages.

  • Front-line and operational

    Shift handover, shared devices, connectivity, scanners and speed of exception handling.

  • Office and professional

    Approvals, reporting, data quality and commercial control behaviour.

  • Service and case-based

    Continuity, case ownership, partner coordination and statutory service responsibilities.

What mobile and front-line users need

  • Few clicks
  • Clear information
  • Simple exception handling
  • Useful defaults
  • Appropriate device
  • Fast enough performance
  • Relevant training
Explore Industries

After the project

Adoption evidence is the most useful input an existing customer has.

Unused capability, repeated manual work, missing reporting, data-quality issues, automation opportunities and new teams all show up in how the process is actually operated. Evidence is used to prioritise improvement, not to manufacture an opportunity.

  1. Operate

    The process runs, day to day.

  2. Observe

    Process signals, support demand and workarounds.

  3. Reinforce

    Clarify, retrain or correct where the cause is capability.

  4. Optimise

    Fix the process, reporting or configuration where it is not.

  5. Measure

    Did the intervention move the process signal?

  6. Expand

    Only where the evidence justifies it.

Commercial model

How adoption work is normally scoped.

Adoption may sit inside an implementation, be customer-led with our enablement, or run as a focused improvement engagement on a live platform. We do not publish user thresholds, durations or prices.

  • Implementation adoption workstream

    Change, training and readiness scoped inside the implementation.

  • Customer-led with our enablement

    We equip your trainers, process owners and super users.

  • Live-system adoption improvement

    A focused Optimise engagement for a platform already in use.

What scope depends on

  • Number of roles
  • User population
  • Sites
  • Languages
  • Delivery format
  • Content required
  • Trainer model
  • Process complexity
  • Support model
  • Internal capability

Where adoption leads next

Sometimes the answer is training. Sometimes it is not.

Poor adoption can be the symptom of a deeper implementation problem: a process that does not fit, data nobody trusts, failing customisations or a rushed go-live.

  • Optimise

    Adoption evidence usually points at the next automation, report, workflow or process fix.

  • Recovery

    Where confidence has materially deteriorated, another training campaign is not the answer.

  • Transform

    Transformation changes roles, controls, ownership, decision rights and reporting, not only technology.

  • RAPID

    Acceleration is difficult when every process decision is deferred until training.

Explore OptimiseExplore RecoveryExplore TransformExplore RAPID

Adoption in practice

The strongest evidence is what happened after people started using the platform.

We publish verified customer evidence rather than adoption percentages. Where a customer has described user confidence, long-term support or an operational improvement in their own words, that is what we show.

See Customer Stories

Common questions

Questions leaders ask about adoption.

Make the change stick

Will the new system change how the organisation works, or just where people enter the data?

If your programme needs stronger business readiness, role-based training or adoption planning, we can help connect the people journey to the solution delivery plan.

Explore Implementation Methodology

Related