# Phase 4 — production rollout
> **What you will learn**
> The four things the scale-up phase actually requires, and how to stop the
> quiet collapse that happens three to six months after rollout.
## The purpose of this phase
> **Scale the verified solution across the organisation and build a continuous
> improvement loop.**
The emphasis lands naturally on "scale," but the hard part is the second half —
**the continuous improvement loop.**
> **Scaling is not widening access. It is embedding.**
Something that worked in the POC quietly falling out of use after a company-wide
rollout is extremely common. It happens because of something the POC had and the
rollout does not — **attention.** During a POC someone looks at it every day;
after scaling, nobody does.
## Four activities
### 1. Build and deploy the production environment
Mind what differs from the POC environment.
| Item | POC | Production |
|---|---|---|
| Scope | 5 suppliers | 80 |
| Exceptions | all by hand | needs automatic routing |
| On failure | the owner improvises | **needs a fallback procedure** |
| Access | one person | the whole team, by role |
**The "on failure" row is the key one.** Work must not stop when the system
stops. A manual fallback path has to be ready.
### 2. User training and onboarding
One person used the POC; now ten people use it. **Those nine have no context.**
Training must include:
| Content | Why |
|---|---|
| What it does for you | sets expectations |
| **What it does not do** | prevents incidents caused by misunderstanding |
| How you know it was wrong | the check point |
| Who to tell if something is off | prevents things being left |
The second matters most. Misunderstand it as "it handles everything" and people
stop checking.
### 3. Monitoring and alerts
Decide **what you will be watching.**
```
Collected daily:
volume / human interventions / errors / average handling time
Alert when:
- error rate exceeds 2× normal
- human intervention exceeds 30%
- volume drops below half of normal (= people have stopped using it)
```
**That third alert matters.** Errors are visible; **not being used is silent.**
You have to catch declining usage with an alert.
### 4. Establish the improvement process
If it is not scheduled, nobody does it.
| Cadence | What |
|---|---|
| Weekly | review errors, look for recurring patterns |
| Monthly | metric review, compared against Phase 1 numbers |
| Quarterly | review scope expansion (fold exceptions into automation) |
## Output
> **Operations manual & KPI dashboard**
### What goes in the operations manual
```
1. What this system does / does not do
2. How to confirm it is working
3. Common problems and responses
4. Fallback procedure on failure ← mandatory
5. Owner contacts and escalation path
```
### The KPI dashboard
Phase 1's numbers have to live **somewhere people keep seeing them.** If they
only exist in a report, nobody looks three months later.
## Gate — to call this phase finished
> **Does it run without hand-holding, and do metrics land on a dashboard?**
If "the owner has to check it every day for it to work," it is not finished.
## The real test is months 3–6 after rollout
What commonly happens in that window:
| Point | What happens | Countermeasure |
|---|---|---|
| Month 1 | unforeseen exceptions | caught by the weekly review |
| Months 2–3 | initial attention fades | automatic alerts watch instead |
| Months 3–4 | the work changes and it no longer fits | found in the monthly review |
| Month 6 | the owner changes | you need the operations manual |
**The last row is the most frequently missed.** When the person who built it
leaves, nobody can fix it, and usage quietly declines.
## And back to Phase 1
```mermaid
graph TD
A["Phase 4 complete"] --> B["Data accumulates in operation"]
B --> C["New improvements become visible"]
C --> D["Phase 1: define the next project"]
D --> E["Faster this time
baseline, experience, and trust exist"]
```
An organisation that finished one project is much faster on the second. It knows
how to measure, who to work with, and above all **that this works.**
## Common misconceptions
### "The POC went well — can't we just open it to everyone?"
That is precisely the most common failure. There are things a POC has and a
rollout does not: training, monitoring, fallback procedures, an improvement
cadence. Without them it quietly falls out of use in three to six months.
### "Building monitoring too — isn't that the tail wagging the dog?"
Without monitoring you **cannot keep proving the effect.** And then you do not
get budget for the next project. One dashboard is the key that opens the next
one.
---
## Check yourself
**1. What does "scaling is not widening access but embedding" mean?**
Answer
That opening up access company-wide is not enough. Training, monitoring, a
fallback procedure, and an improvement cadence have to go with it; without them
it quietly falls out of use in three to six months.
**2. Why do you need a "volume dropped below half of normal" alert?**
Answer
**Because not being used is silent.** Errors are visible; abandonment gives no
signal at all. Catching the usage drop as an alert is what lets you find the
cause early.
**3. What breaks when the owner changes at six months?**
Answer
When the person who built it leaves, **nobody can fix it**, problems get left
alone, and usage quietly declines. The operations manual (does / does not do,
responses, fallback, escalation) is what prevents this.
---
Once deployed you have to prove the effect. Most stop here →
[Measuring and reporting results](/guide/ax-measurement)