Our Six-Step Approach to Digital Adoption
We run digital adoption in six stages: Discover, Diagnose, Design, Implement, Enable, Stabilize and Optimize.
TL;DR
- Six stages, and you receive a named deliverable from each. Not a status report. Artifacts you keep.
- This supersedes the sequence we published in 2023, which ended at training and treated adoption as the last item on the list.
- The first three stages are available on their own. Most clients start there and decide on the build from what it finds.
- The design decisions are yours. We cannot decide who approves a discount over fifteen percent, and where the decision is not available we record it as open rather than assuming.
- Zoho comes up often and is not the definition of the service. Clients have finished on Microsoft, on mixed platforms, and on tools they already owned.
- The engagement continues past go-live, typically for ninety days, agreed before the build starts.
The version of this article published in 2023 described a different sequence, ending at training. That sequence treated adoption as the last item on the list, which put the two stages that actually decide the outcome outside the scope of the engagement. This is the current approach and it supersedes the earlier one.
What changed and why
The old sequence ran Pre-Engagement Assessment, Digital Audit, Review Existing Tools, Solution Design, Implementation, Training.
Two problems with it.
Training does nothing about a process that is slower for the person running it, data the team does not trust, or a question nobody is available to answer.
The engagement ended at go-live, which is the day the real problems start appearing. Some of the design will be wrong. A field marked required blocks a case nobody described. An approval stage exists for a scenario that happens twice a year and now blocks the other three hundred. Finding those in month two is normal. Finding them with no scope to fix them is how a team returns to the old method.
Enable and Stabilize replaced Training, and both are scoped and paid for like the rest.
Stage 1: Discover
We write down how the work runs today.
Processes, existing software, the spreadsheets doing a system’s job, where the data lives, who owns what, how reporting gets produced, what is integrated, and every place the same thing is done twice.
Done by interview and observation rather than questionnaire. The documented process and the real one are different documents, and the real one is what we build against.
You receive
Current-state process maps, a systems inventory, a pain-point analysis, a requirements register.
Stage 2: Diagnose
The gaps, duplication, risks and adoption problems in that account, named and ranked.
Ranked, not listed. Any organization can produce forty problems. Three of them are producing the others, and this stage identifies which three.
It is also where we establish why a previous rollout failed, when there was one. Those conditions are usually still present, and designing without naming them means designing the same failure.
You receive
A ranked problem set with each item traced to its cause.
Stage 3: Design
How the process should run, settled before anything is configured.
Stages, ownership, approval rules, handoffs, required data, exceptions, notifications, escalations, reporting. These are your decisions, not ours. We cannot decide who approves a discount over fifteen percent, and where the decision is not available we record it as open rather than assuming.
Then the technology: which tools stay, which are replaced, what becomes the system of record, how things connect.
You receive
Future-state workflows, business rules, a roles and ownership matrix, a solution architecture, an application map, an integration architecture, an implementation roadmap.
The roadmap is written to be executed by whoever executes it. Several clients have taken it and built in-house or with their existing IT provider. That is a supported outcome, not a lost sale.
Where most engagements start and stop
The first three stages are available on their own as FusionMap. The output is a design and a roadmap any implementation partner can build from. Most clients start there and decide on the build from what it finds.
Stage 4: Implement
The environment gets built to the design.
Modules, fields, layouts, approval workflows, forms, portals, dashboards, and the integrations between systems. Roles, profiles, access levels and data-sharing rules are configured as part of the build rather than added afterwards.
Your data is inventoried, cleaned, deduplicated, mapped and migrated against a validation report. The repeating work gets automated, each automation with its exception handling defined at the same time.
Zoho is where most of our clients end up and we are a Zoho Authorized Partner, so it comes up often. It is not the definition of the service. Clients have finished this engagement on Microsoft, on a mix of platforms, and on tools they already owned and were using at a fraction of their capability.
You receive
A configured production system running on your data, with integrations and automations live.
Stage 5: Enable
Your people can operate it without us.
Training by role, so a person learns the work they do rather than sitting through every module. Separate training for administrators, because administering a system is a different job from using it. A written procedure for every process the system now carries, in the language your team uses. A user guide, an administrator handbook, and an adoption plan with something measurable in it.
You receive
Role-based and administrator training with sessions recorded, an SOP library, user and admin documentation, and a measurable adoption plan.
Stage 6: Stabilize and Optimize
The engagement continues past go-live, typically for ninety days, agreed before the build starts.
Issue resolution. Workflow corrections against what people actually do rather than what the design assumed. Data-quality monitoring. Usage measured against the adoption plan. An enhancement backlog you own.
You receive
A corrected system, measured usage against the plan, and a backlog your administrator can run.
Why this stage is contracted rather than assumed
A technically correct system that employees avoid is a failed implementation. Stage six is the difference between a build that worked and a build that was delivered.
What you own at the end
Current state and future state, for every process in scope.
What each application is for, what is authoritative for each type of record, and how the systems connect.
Running on your data, not on demo records.
So the question of whether it came across correctly has a documented answer.
Including what happens when one of them fails.
Each one with its exception path and monitoring rule defined at the time it was built.
An answer to who can see what, and who is responsible for each application.
In the language your team uses, written so a new hire could run the process without asking.
Sessions recorded, so the twelfth hire gets the same enablement as the first.
Agreed before the build starts, so the corrections month two requires have somewhere to go.
The Digital Adoption service page carries the full list and the three price bands.
Common mistakes we see before we arrive
- The software was chosen first. The process then gets bent to fit the product's defaults, which produces the original problem in a more expensive place.
- Data migration was treated as an IT task. The old system's contents were moved across without inventory or cleaning, and the team decided in week one that the records could not be trusted.
- The engagement ended at go-live. Corrections in month two had nowhere to go and became workarounds.
- Training was the adoption plan. A session happened, attendance was recorded, and nothing was measured.
- The reason the last rollout failed was never established. The new one met the same conditions.
Frequently asked questions
Can we do only the first three stages?
Yes. That is FusionMap, and it is where most engagements start. The output is executable by any implementation partner.
How long does the whole thing take?
Two to six weeks for the assessment. Ten to nineteen weeks for a single systems build. Twenty to forty weeks for a full environment across several functions. Stabilization is typically ninety days after go-live.
Is this a Zoho implementation?
Zoho is what most clients end up on and we are an authorized partner. The decision about which tools stay and what becomes the system of record is made in stage three on the evidence from stage one. Clients have finished on Microsoft and on mixed platforms.
We already own the software. Do we still need this?
That is the common case, and most of the value is in the process design and the data work rather than the licence. A system nobody shaped around the process is what produced the spreadsheets running alongside it.
Can you work with our existing IT provider?
Yes. Stage three produces an architecture and a roadmap written to be executed by whoever is executing it.
What if our team still does not use it?
That is what stages five and six exist to prevent, and it is why the engagement is scoped past go-live. Usage is measured against the adoption plan and the workflow gets corrected against what people actually do.
Do we need this before doing anything with AI?
For agents doing real work, yes. An agent runs against your data and your process, so undefined processes and scattered records produce confident wrong answers at speed. Individual staff using AI for research and drafting is a different question and does not wait on this.
Key takeaways
- Six stages, each with a named deliverable you keep whether or not we build the system.
- This supersedes the six steps we published in 2023. Training was replaced by Enable and Stabilize.
- The first three stages are available on their own, and the roadmap is written for any implementer.
- Process decisions are yours. Where a decision is not available we record it as open rather than assuming.
- Zoho is where most clients end up and it is not the definition of the service.
- Stabilization is contracted, typically ninety days, and agreed before the build starts.
Where to go next
What is digital adoption covers the definition. How digital adoption works explains the six stages as a discipline rather than as our engagement. How to drive digital adoption goes deeper on stages five and six.