What you will learn How "we adopted AI" differs from "we transformed with AI," and where you can see the difference. We follow two real company trajectories side by side.
Adoption adds a tool. Transformation changes the order of work.
An analogy. A copier arrives in the office.
If you install a copier and everyone still writes documents out by hand, the copier is expensive decoration. AI is exactly the same.
An organisation that only adopted and one that transformed look nearly identical for the first three months. Both create accounts, people try it, and the reaction is "this is neat."
The split comes at six months.
| Adoption only | Transformation | |
|---|---|---|
| 3 months | usage up, positive reaction | usage up, positive reaction |
| 6 months | usage declining, "I don't really need this" | that work cannot go back to the old way |
| Metrics | unchanged | one of time, cost, or quality moved |
| Cost | stays elevated | offset by a reduction elsewhere |
"I don't really need this" is the failure signal of adoption. Transformed work cannot be reversed — the old procedure is already gone.
Two companies with the same problem. Both spend far too much time on customer support.
Month 1. Every support agent gets an AI account. The guidance: "use it when you write replies."
Month 2. Agents start drafting replies with AI. A draft comes out; they read it, fix it, send it.
Month 4. Something strange. Ticket volume is flat but agents say they are busier. Here is why:
The steps did not shrink; they grew. AI produces a draft, but a new job appeared: checking whether the draft is right. Reviewing is easier than writing, but it is not free.
Month 6. Half of them do not use it. "It's faster to just write it." The account cost keeps going out.
Month 1. Before handing out any accounts, they analyse three months of tickets. The result:
| Type | Share | Character |
|---|---|---|
| Delivery status | 41% | answer is fixed; only needs an order number |
| Return procedure | 19% | answer is fixed |
| Product specs | 22% | the answer is in a document |
| Complaints and exceptions | 18% | requires judgement |
Month 2. Instead of helping agents, they decide to stop 82% from reaching agents at all. Delivery status and returns are wired to the order system and answered automatically; spec questions are answered from the product documents.
Month 4. Tickets arriving at the support team are down to 18%. Everything left requires judgement. Headcount is unchanged, so time available per ticket is five times what it was. Complaint handling quality goes up.
Month 6. It cannot be reversed. Turn off the automatic answers and the team cannot cope.
A and B used the same technology. Exactly one thing differed.
A made "AI help with what people were doing." B made "work stop arriving at people."
A left the procedure intact and inserted AI into it. So steps increased. B redrew the procedure. So steps decreased.
Explaining that distinction usually draws this question immediately.
"We've been doing DX for years. How is this different? Shouldn't we finish DX first?"
Continuing the photocopier analogy, there are three layers.
| What moves | Example in an office | |
|---|---|---|
| Computerisation | Records, from paper to a screen | The ledger becomes a spreadsheet |
| DX | Procedures, from people's hands to a system | Approvals move to groupware; the system knows who approved what, and when |
| AX | Judgement and coordination, from people to machines | Whatever would get an approval rejected is caught before it is submitted |
Computerisation moves records, DX moves procedures, AX moves judgement. The layers look like they stack in that order, and for the last twenty years they did.
Older automation presupposed structured data. You had to put things into a form the system could read before you could hand a procedure to it. That is why "DX first" used to be correct.
That premise is now weaker. Why now covers this in detail, but in short: messy input can be handled. A scanned contract, a document someone wrote their own way, an email with attachments — all of it used to be "something you have to tidy up first," and now it can go in as it is.
So a plan that says "we'll start AX once DX is done" usually means we will not start. DX is not the kind of work that finishes.
The premise is weaker, not gone. One thing is still required.
The material for that job has to sit somewhere reachable without a person fetching it.
This is not a call to run a company-wide DX programme. You only need to check whether the material for the one job you picked is reachable. That check comes back as "data source mapping" in the assessment phase.
Account count is an adoption metric. The transformation metric is the number of procedures that disappeared. Can you count the work steps that vanished in the last six months? If not, you are still adopting.
Backwards, and it rarely works. People first learn how to use it inside the current procedure, that becomes habit, and a later proposal to change the procedure meets "we're using it fine, why change?" For A to change procedures at month six is harder than starting from scratch.
That does not mean letting people try it is bad. It means do not call that transformation. It is an exploration phase, and you should decide in advance what you intend to learn from it — Company B's month one was exactly that.
Sometimes true, sometimes not. The way to tell is to look at what happens when it is wrong.
The first can be handed over today; the second needs human approval in the loop. "AI is too inaccurate" usually comes from not making this distinction and treating everything as the second case.
| Adoption | Transformation | |
|---|---|---|
| What changes | the means | the procedure |
| What you count | users, usage | steps removed, metrics moved |
| People's work | unchanged + AI review | reallocated |
| At six months | reversible with no consequence | cannot be reversed |
1. Why did the number of steps increase at Company A in month four?
Because they kept the existing procedure (read → write → send) and inserted an AI step into it. When AI produces a draft, a new job appears: reviewing the draft. Writing did not go away; review was added, so the total went up.
2. What do you count to decide whether your company is transforming?
The number of work steps that disappeared. Account counts and usage are adoption metrics. If you cannot name specific procedures that vanished, you are still in adoption.
3. How do you separate work AI can take today from work that needs human approval?
By the cost of being wrong. If the worst case is the customer asking again, hand it over; if money goes out wrongly or it is hard to undo, put approval in the loop. The common mistake is treating everything as the second case because "AI is inaccurate."
Next: why now, specifically — what changed such that things that did not work before now do → Why now
HyperTeamsBefore: read ticket → write reply → sendNow: read ticket → ask AI → read draft → verify facts → edit → send