# Adoption is not transformation

> **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.

## In one line

**Adoption adds a tool. Transformation changes the order of work.**

An analogy. A copier arrives in the office.

- Documents you used to write by hand now come out of the copier. → **adoption.**
  The procedure for producing documents is unchanged; only the means changed.
- You decide to produce one good original and copy the rest, eliminating the
  rule that "everyone maintains their own handwritten copy." → **transformation.**
  The tool changed the procedure.

If you install a copier and everyone still writes documents out by hand, the
copier is expensive decoration. AI is exactly the same.

## Why this matters — it splits at six months

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, side by side

Two companies with the same problem. Both spend far too much time on **customer
support.**

### Company A — adoption

**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:

```
Before: read ticket → write reply → send
Now:    read ticket → ask AI → read draft → verify facts → edit → send
```

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.

### Company B — transformation

**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.

### What was different

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.

## How is this different from DX (digital transformation)?

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.

### But it is not "finish DX, then start AX"

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](/guide/ax-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.

### There is still a floor

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.**

- Files are on a shared drive → fine. The formatting can be a mess.
- It is in an internal system and you can get a read-only account → fine.
- It exists only on paper / only on one person's PC / only in one person's inbox
  → **that has to move first.**

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](/guide/ax-phase2-assessment).

## Common misconceptions

### "We gave the whole company accounts, so we transformed, right?"

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.

### "Let people use it first, then change the procedure later."

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.

### "AI is still too inaccurate to hand a procedure to."

Sometimes true, sometimes not. The way to tell is to look at **what happens when
it is wrong.**

- Wrong delivery status → the customer asks again. Small cost.
- Wrong refund amount → money goes out incorrectly. Large cost.

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.**

## Summary

| | 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 |

---

## Check yourself

**1. Why did the number of steps increase at Company A in month four?**

<details>
<summary>Answer</summary>

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.
</details>

**2. What do you count to decide whether your company is transforming?**

<details>
<summary>Answer</summary>

**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.
</details>

**3. How do you separate work AI can take today from work that needs human
approval?**

<details>
<summary>Answer</summary>

**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."
</details>

---

Next: **why now**, specifically — what changed such that things that did not
work before now do →
[Why now](/guide/ax-why-now)