# Phase 1 — define the problem

> **What you will learn**
> What to investigate and what to write down. The numbers produced in this phase
> become the only basis on which success is later judged.

## The purpose of this phase

> **Define a specific business problem AI can solve.**

"Specific" is the operative word. "Let's improve customer support" is not
specific. "Delivery status enquiries are 490 a month and take 4 minutes each" is.

## Four activities

### 1. Analyse the current process

Look at **how it is actually done.** Not the procedure written in the document —
the real one. They are almost always different.

Sitting next to the person and watching one item end to end is fastest. What
comes out while you watch is the valuable part:

> "Oh, the system is supposed to do this but it doesn't, so we keep a separate
> spreadsheet"
> "Only one person knows how to do this step"
> "We're supposed to check here, but when it's busy we just pass it through"

That is **the real procedure, which is in no document.**

### 2. Identify repetitive, time-consuming tasks

**Attach a time to every step.**

```
Invoice processing (per item)
  1. download the attachment from email     30 sec
  2. check contents (amount, line, account)  3 min
  3. enter it into accounting                2 min
  4. file and archive the original          30 sec
  ────────────────────────────────────────────────
  6 min each × 400/month = 40 hours/month
```

This is where **which step is an AI target** gets decided. Steps 2 (checking)
and 3 (entry) are targets; 1 and 4 need only plain automation.

### 3. Assess AI suitability

Not every repetitive task is an AI target. Filter with this table.

| Check | Suitable | Unsuitable |
|---|---|---|
| What is the input | documents, text, conversation | physical work, structured numbers only |
| Is judgement needed | there is a fuzzy judgement | 100% expressible as rules (→ plain automation is better) |
| If it is wrong | reversible | not immediately reversible (→ needs human approval) |
| Exception rate | under 20% | half are exceptions (→ narrow the scope) |

**If it is "100% expressible as rules," there is no reason to use AI.** Plain
automation is cheaper and more accurate. AI is for the part you cannot write as
rules.

### 4. Estimate ROI

```
Current cost:
  direct time    40 hrs/month × labour rate = A per month
  rework         19 hrs/month × labour rate = B per month
  total          (A+B) per month

Expected saving:
  human time remaining after automation  8 hrs/month (exceptions)
  saving                                 (A+B) × ~80%

Investment:
  build          about 3 weeks
  running cost   C per month (model usage etc.)
```

> **Note**: this is a **projection.** It does not need to be accurate — **the
> order of magnitude** is enough. A plan that spends six months on a 40-hour
> monthly task has the wrong order of magnitude.

## Output

> **List of suitable work & ROI projection**

It does not have to be an elaborate document. One table will do.

| Work | Hrs/month | Rework | Exceptions | Data | Est. saving | Rank |
|---|---|---|---|---|---|---|
| Invoice entry | 40h | 19h | 12% | email + PDF | 80% | 1 |
| Delivery enquiries | 33h | — | 8% | order DB | 90% | 2 |
| Monthly report | 16h | — | 40% | several sheets | 50% | 3 |

## Gate — to move on

> **Does every candidate have numbers for current time and cost?**

This gate is the most frequently ignored, and ignoring it **costs you latest.**
Ending up at the six-month review saying "it's definitely faster but I'm not
sure how much" is [Failure 2](/guide/ax-failure-modes).

### If you cannot get the numbers

| Situation | What to do |
|---|---|
| No records exist | **measure for just two weeks.** The owner notes volume and time |
| It varies by person | write a **range**, not an average (4–9 min each) |
| Strong seasonality | write peak and off-peak separately |
| Truly unmeasurable | **deprioritise** it. What you cannot measure you cannot prove |

## Common mistakes in this phase

### Collecting too many candidates

Starting with "let's gather everything" produces twenty and turns Phase 1 into
two months. Look at **three to five at a time** and pick one. The rest are the
next round.

### Writing it at a desk without the owner

Only the owner knows the real procedure. Define it from documents and system
screens and you miss every exception case. Those exceptions are what later break
the POC.

### Starting from "what should we use AI for"

Covered [earlier](/guide/ax-choosing-tasks), but worth repeating. Collect
problems first, attach solutions later.

---

## Check yourself

**1. Why look at "the real procedure" rather than "the documented procedure"?**

<details>
<summary>Answer</summary>

Because they are almost always different. "The system doesn't do it so we keep a
spreadsheet," "only one person knows this step," "when it's busy we pass it
through" — these are the real procedure and appear in no document. Miss them and
the exception cases break the POC later.
</details>

**2. Why should you not use AI for work that is 100% expressible as rules?**

<details>
<summary>Answer</summary>

**Because plain automation is cheaper and more accurate.** AI is for the fuzzy
part you cannot write as rules. Using it where rules work costs more and
introduces room to be wrong.
</details>

**3. What do you do if you have no record of current time and cost?**

<details>
<summary>Answer</summary>

**Measure for two weeks.** The owner noting volume and duration is enough. If it
varies by person use a range instead of an average; if it is seasonal, split it.
A project you truly cannot measure gets deprioritised — what you cannot measure
you cannot prove.
</details>

---

Next, the phase that confirms "can it be built" →
[Phase 2 — data and system assessment](/guide/ax-phase2-assessment)