Framework
AI Adoption and Improvement Framework
Get an AI tool into people's daily work, then keep improving it so they stay with it.
Stage 4 of four: Discovery to Assessment to Solutioning to Adoption and Improvement. A decision to scale arrives from Solutioning with its adoption target, and what this stage learns feeds the next round of Discovery.
Idea lifecycle. Adoption and Improvement is Stage 4 of 4.
The whole AI cycle depends on the users. A tool can pass every test at every gate and still return nothing. This is my method for putting a tool into daily use and improving it after rollout. Put the help inside the flow people already use, keep support in place after launch, measure whether they use it, and fix what they report before they give up on it.
I wrote it for generative AI (GenAI) leads running everyday tools, such as AI-generated dashboards and drafting assistants, most of which never touch a regulated record. When a tool does support GxP (good practice rules for regulated pharma) work, the steps stay the same and a quality layer sits on top.
1. When to use it
- When a tool is about to go live for its first team, after a Scale call at the end of Solutioning.
- When a live tool shows falling usage or rising reviewer edits.
- Before anyone proposes widening a working tool to another team or process.
2. The users are in every stage
Co-design with the people who do the work is required in all four frameworks. Each stage asks something different of them.
- Discovery
Locks the as-is process with them, step by step, as they actually do it.
- Assessment
Scores it, and the value case sets an adoption target next to the value target.
- Solutioning
Checks quality first at each phase gate, then value, real usage against the adoption target, reviewer burden and cost.
- Adoption and Improvement
Proves it sticks after rollout.
3. The seven steps at a glance
Adoption and improvement, in seven steps
Seven steps in order, top to bottom. Step 1: Map the flow with the users. Step 2: Bring the adoption target forward. Step 3: Put lasting support in place. Step 4: Go live and measure use. Step 5: Run the feedback loop. Users report a problem. Information technology staff and the generative AI lead fix those reports first, measure the change against the value-case baseline, rerun past cases, then release the fix. Two outcomes. Fixed fast: check use against the adoption target. Left waiting: users go back to the old way. Step 6: Watch for drift, alongside the loop, through sampled accuracy and reviewer edits, with usage as the early warning. The loop runs for as long as the tool is in use. Step 7: Decide where it goes next, three outcomes. Same team and process: keep improving it here. Proposed widening: assess the scope and any change in intended use before rollout. Below target after fixes: stop or retire it.
4. The steps
- Map the flow with the users, for zero friction
Sit with the people who do the work and walk the flow they use today. Put the GenAI help inside that flow, where they already do the task, so that using it adds no step. In my experience, help that adds steps outside the flow gets skipped. A flow that turns out broken or outdated at this point is the business owner's call. A small fix can happen here, because a tool laid on top of a broken process keeps its defects. A big process change goes back through the Assessment.
The same session is the place to say plainly what changes in each role and what stays. Talk through job worries with the people whose work changes.
- Bring the adoption target forward
Solutioning carries the adoption target forward from the value case. If there isn't one, set it now with the business owner, along with a date to check it. The usual measures are active users as a share of the intended group and how often they use it. Task completion rate shows whether they finish the job with the tool. Solutioning checked usage and reviewer burden at each phase gate. Here you confirm them after rollout, with the business owner who set them.
- Put lasting support in place
Support has to stay as a permanent fixture of the team after launch: a manager trained on the tool, one named technical point person, and work instructions that show the new flow step by step. Name one accountable owner for the tool and its numbers, normally the business owner who holds the value case. That person acts when usage falls.
- Go live and measure use
Use is binary: they use it or they don't. At each agreed review date, count how many of the intended users did the task with the tool, against the target from step 2, and ask anyone who stopped why. Next to usage, track reviewer burden, meaning review time and how much reviewers edit. A draft that saves the author an hour and costs the reviewer two is a net loss.
- Run the feedback loop
Give users one simple way to report a wrong output or a problem, close to where they work. Information technology (IT) staff and the GenAI lead fix those reports first, and tell the person who reported it when the fix is live. Fixes can include prompt tuning or a change to the source data the tool loads.
Measure each change against the value-case baseline. Before a change goes out, rerun a fixed set of real past cases, the regression set, so that a fix for one problem doesn't break something that worked.
- Watch for drift
This is the defensive half of improvement, carried over from the monitoring Solutioning planned. Check a sample of outputs against the acceptance criteria, and keep watching reviewer edits and usage. Changes outside the tool, such as a model update, can shift results without anyone touching the tool. Falling usage is often the earliest warning.
- Decide where it goes next
A tool is specific to a team and a process. Widening it depends on scope. Before giving it to a new team or process, assess the scope and whether the intended use changes. Document the impact of any change and update the evidence and controls before relying on the tool in the new scope, with this stage's numbers as its first evidence. What the loop learns about the current process can feed the next round of Discovery too.
If usage or value stays under target after the agreed fixes, or the tool's running cost, the loop included, outgrows the value measured against the value-case baseline, stop or retire the tool. That closes the AI idea. The need behind it stays open.
5. The rule
Key rule
Adoption owns the improvement loop. If fixes don't get priority, users go back to the old way.
6. Seven barriers, and the step that answers each
These are the barriers I look for when a tool isn't being used. Each one has a home in the steps above.
| Barrier | Where the method answers it |
|---|---|
| A broken or outdated process under the tool | Step 1: fix the flow before adding help to it |
| Job worries among the people whose work changes | Step 1: they shape the new flow and hear what changes in their role |
| Reviewer burden | Step 4: review time and edits tracked next to usage |
| Lost trust after bad outputs | Steps 5 and 6: fast, visible fixes and sampled checks |
| A tool that sits outside the workflow | Step 1: help inside the screens people already use |
| No accountable owner | Step 3: a named owner for the tool and its numbers |
| Procedure, work instruction and training updates for GxP work | Section 8, the notes for GxP tools |
7. Example: a weekly supply summary
A planning team of 12 writes a weekly supply status summary for site leadership, and today each planner spends about 90 minutes on it. A GenAI assistant drafts it from the planning system's exception report. Each planner edits the draft and sends the summary under their own name. The planning manager owns the value case, which targets 10 of 12 planners starting from the draft by week 6, with the planner's review of the draft under 20 minutes.
In the mapping session, the planners point out that they write the summary in the weekly report template, not in the chat window where the pilot ran. The draft moves into the template behind one button. The planning manager is trained first, one IT analyst becomes the named point person, and a one-page work instruction shows the new flow.
In week 3, 7 of 12 planners use it. Two report that the draft misreads late shipments split across two lines. IT restructures that field in the source extract, reruns 30 past weeks kept as the regression set, and releases the fix in four days. By week 6, 11 of 12 use it and review takes about 15 minutes. The planner who still doesn't says the button is missing from her copy of the template, and the point person fixes that the same day. A request to give the same tool to the procurement team needs a scope assessment before rollout.
8. Notes for GxP tools
For GxP tools, add:
- Include updates to standard operating procedures (SOPs), work instructions and training in the change-control plan.
- Agree change categories with Quality up front, so each change gets an impact assessment and the checks and records its category calls for. This is what keeps the step 5 fixes cheap.
- Keep the regression set of real past cases fixed and documented, and plan the review cadence for monitoring results instead of waiting for a problem.
- Quality approves the release of a fix in the change categories that call for it, and an appropriately qualified, authorized person approves GxP outputs before anyone relies on them.
- Treat model, prompt, retrieval (how the tool finds source material), data, configuration and intended-use changes as change records with an impact assessment, as the Solutioning controls set out.
The U.S. Food and Drug Administration (FDA) final guidance on predetermined change control plans for AI-enabled device software functions was issued in December 2024 and updated in August 2025. It sets out what a device maker should put in a predetermined change control plan if it submits one: the planned changes, how they will be developed, validated and put in place, and their impact. I borrow the idea of agreeing expected changes in advance. It comes from device rules, and pharma does not require it.
9. After this stage
This stage runs for as long as the tool is in use. Two things come out of it: usage and value measured against the starting baseline, and what the loop learned about the tool and the process, which can go into the next round of Discovery.
That return path is what makes the four stages one loop. See the frameworks overview for all four.
Want to plan adoption for your AI tool? That is the work I do.
10. Where the detail lives
The detail this stage builds on sits in the earlier articles. Lock the process and what it costs before you look for AI shows the mapping with users. The most valuable AI call you'll make is often "not this one" covers the value case and its adoption line. Solutioning AI in GxP: how to choose the route and prove it in phases covers the usage and reviewer-burden checks at each phase gate.
11. Caveats
This is my own method and my recommendation. It is advisory, not a regulatory requirement and not legal advice. The numbers that count as good adoption depend on the team and process the tool serves.