Unit 4 · On your own work
Where it goes first
The principle
The first process AI should touch is chosen by volume, judgment density and tolerance for error — never by how visible it is.
By the end: You can score five of your own recurring processes on run-count and tolerance for error, and name the one whose count you do not have.
The situation
Three weeks after the board asked what you are doing about AI, you are looking at a shortlist someone in strategy built. Eight items, ranked by "impact". At the top sits the customer-facing one — the process on the homepage, the one the board would recognise by name. Everyone in the room expects you to start there. Start there and you will spend two quarters learning a single fact: that process is visible precisely because being wrong in it is expensive.
The principle
The first process AI should touch is chosen by volume, judgment density and tolerance for error — never by how visible it is.
Unit 0 ran this on one task in your own week. Here it runs on a portfolio, and its fourth test — is this yours to change — stops being a preference and becomes a veto.
Score each candidate one to five on three dials, then multiply, then apply the fourth. The product is not a strategy. It is an argument you can hold in a room full of people with opinions.
Volume. How many times did it run last month — not how many people touch it, how many times it ran. Five if it runs daily, one if it ran once. Anything you build has a setup cost, and only repetition pays it back.
Judgment density. What share of the work is retrieval, comparison, formatting and drafting, versus calls that depend on context nobody has written down? Five when most of it is the first kind. High judgment density is a reason to avoid it first, not forever — you will not be able to tell whether the output was any good.
Tolerance for error. What happens to a wrong output? Five when it lands in front of somebody who was going to read it anyway. One when it reaches a customer, a regulator, a payment or a machine. A one here is a veto, whatever the other two dials say.
Ownership. Not scored — asked. Can one named person approve a change to this by Friday? A committee means the process is untouchable this quarter however well it scored, so take the next row down.
Now look again at the visible process at the top of the shortlist. It almost always scores one on the third dial. That is what made it visible.
Worked example
Shown here in Claude.
An operations director at a regional industrial distributor has eight recurring processes in a spreadsheet — one per row, with runs last month and the owner. She attaches it and assigns the scoring:
Job: Score each process in the attached file as a candidate for the
first place we use AI.
Inputs: One row per process, with runs last month and the owner. Use
only what is in the file.
Output: A table, one row per process, scored 1-5 on volume, judgment
density (5 = mostly retrieval, comparison, formatting, drafting) and
tolerance for error (5 = a wrong output is read by someone who was
going to read it anyway; 1 = it reaches a customer, a regulator, a
payment or a machine). Add the product of the three. Sort high to low.
Standard: Where the file does not say how often a process ran, write
"unknown" and do not score that row. For every row, add one line
naming the single fact that would change its score most.What comes back matters less than what it exposes:
| Process | Vol | Judg | Tol | Score |
|---|---|---|---|---|
| Quote follow-up chasing | 5 | 4 | 4 | 80 |
| Supplier price-change notices | unknown | — | — | — |
| Customer credit decisions | 3 | 1 | 1 | veto |
Three of eight rows came back "unknown", because nobody had ever counted. That is the finding. The rubric is doing the work, not the model — what the pass adds is that it will not let her skip a row, and it puts the missing counts on one screen where her team can argue about them.
In your tool
The move here is scoring a file you hand over, rather than a paragraph you type.
| Tool | Working from a file rather than pasted text |
|---|---|
| Claude | Attach to the conversation, or to a Project so every conversation in it reads the same file |
| ChatGPT | Upload per conversation, or to a Project that keeps the file available across conversations |
| Gemini | Upload directly, or point it at a file already stored in the same account |
| Microsoft 365 Copilot | Reads the file where it already sits in your organisation's document store; naming the file in the question is the normal route rather than an upload |
Product surfaces checked 2026-08-04.
Try it
Open last month's calendar. Pick the five recurring things your team did more than a dozen times. For each, write one number — times it ran — and one sentence: what happens when the output is wrong. Paper is fine. Five minutes.
You are done when you can say out loud, "we run this about N times a month, and when it is wrong, someone catches it before it leaves the building." If you cannot say N, that process is not a candidate this quarter. Finding N is.
Common failures
- Counting people instead of runs. "All four hundred of us write emails" is not one high-volume process. It is four hundred low-volume ones with four hundred different standards, and nothing you build for it can be checked.
- Starting where the attention is. Beyond the third dial, the visible process is where the first poor output becomes the whole organisation's opinion of AI — and you do not get a second first impression.
- Scoring a process by its owner's appetite for being scored. The rows that come back complete are the rows owned by people who wanted to be on the list, which is not the same set as the rows with the highest product. Enthusiasm belongs in the sequencing conversation, not in the score.