# Phase 3 — design and run a POC

> **What you will learn**
> What a POC is really for, how to set its scope, and the test for "it worked."

## The purpose of this phase

> **Verify the effect with a small pilot and collect feedback.**

There is one misconception here.

> **The purpose of a POC is not to succeed. It is to decide whether to scale.**

That difference changes the outcome. Make success the goal and you end up
showing only the cases that go well, then failing after you scale. **Make the
decision the goal and you go looking for the cases that fail.**

## Four activities

### 1. Define an MVP scope (quick wins first)

Do not build everything. Cut it down to **the most frequent and simplest cases.**

With the invoice example:

```
Full scope: 80 suppliers, 12 formats, 400/month

POC scope: top 5 suppliers, 2 formats, 180/month (45% of the total)
           → people keep handling the rest
```

**Covering 45% is plenty to decide with.** If there is no effect here, there
will be none in the remaining 55%.

> **How to narrow scope**
> Start from the highest frequency. Start from the hard exceptions and all your
> time goes there. Exception handling gets attached during the scale-up.

### 2. Build the AI agent or workflow

This is the part where you actually build. The flow diagram from Phase 2 is the
blueprint.

Two things to decide in this phase:

| To decide | Example |
|---|---|
| **Where human approval sits** | anything over the threshold needs approval |
| **How you learn it was wrong** | flagged on the owner's review list after entry |

The second matters especially. **If you do not know it was wrong, you cannot
measure the effect either.**

### 3. User testing and feedback

The person who does the job actually uses it. What they say here is sometimes
more important than the POC numbers.

| What they say | What it means |
|---|---|
| "It's faster if I do this myself" | **structural problem.** Steps probably increased |
| "What happens in this case?" | exception found. Decide whether it is in scope |
| "Checking it is a job in itself" | not trusted. Redesign accuracy or approval points |
| "When can we use this for real?" | **a good sign** |

### 4. Measure the metrics (time / cost / quality)

Measure **by the same method** as the numbers recorded in Phase 1. A different
method means no comparison.

```
                     Phase 1 (before)   POC result
Time per item        6 min              1.5 min (excl. approval wait)
Total hours/month    40 hrs             11 hrs (scaled to POC scope)
Errors               12/month           2/month
Human involvement    every item         18% (over threshold)
```

## Output

> **POC report & scale-up recommendation**

What the report must contain is **what did not work**, more than what did.

```
1. Result summary (the table above)
2. What worked
3. What did not ← the most important part
   - handwritten invoices have low recognition (6% of the total)
   - the first item from a new supplier often gets the wrong account code
4. What scaling requires
   - route handwritten items to a person
   - require approval on the first 3 items from any new supplier
5. Recommendation: scale / scale with conditions / stop
```

## Gate — to move on

> **Did Phase 1's numbers actually move? Are users still using it?**

Both must be yes. One out of two is not enough.

| Numbers | Usage | Verdict |
|---|---|---|
| moved | still used | **scale** |
| moved | not used | structural problem. Start with why not |
| flat | still used | convenient but ineffective. Redesign |
| flat | not used | **stop** and return to Phase 1 |

**"Flat + still used" is the trap.** People like it so it looks like success,
but the metrics are unchanged. Scale it and you only add cost.

## Keeping the POC short

POCs run long almost always because **the scope grew.**

```
POC week 2: "it'd be nice if this case worked too"
POC week 4: "while we're at it, let's integrate that system"
POC week 8: still in progress
```

**Write the scope down at the start and send every addition to the "scale-up
list."** Explained as a matter of order rather than refusal, it is generally
accepted.

## Common misconceptions

### "It's a POC — can we build it roughly?"

**Do not compromise on quality; narrow the scope.** Those are different. A
narrow scope built properly makes the decision valid. A wide scope built roughly
leaves you unable to tell whether a null result came from the design or from the
rough build.

### "If it fails, isn't that wasted time?"

Three to six weeks of POC **prevented a failed rollout.** Compare that to the
cost of scaling company-wide without verification and failing six months later.
**A failed POC is a success** — it stopped an expensive mistake cheaply.

---

## Check yourself

**1. State the purpose of a POC in one sentence.**

<details>
<summary>Answer</summary>

**To decide whether to scale.** Make success the goal and you show only the
cases that go well, then fail after scaling. Make the decision the goal and you
go looking for the cases that fail.
</details>

**2. "The metrics are flat but users keep using it." What is the verdict?**

<details>
<summary>Answer</summary>

**Redesign.** It is convenient but ineffective. The trap is that people liking
it looks like success; scale it as-is and you only add cost.
</details>

**3. What is the most important section of a POC report?**

<details>
<summary>Answer</summary>

**What did not work.** That is where you learn what must be shored up before
scaling. A report containing only successes becomes an incident during the
rollout.
</details>

---

Now design that POC on one page yourself. Forty minutes →
[Design a POC on one page](/guide/ax-try-poc-design)