MODULE 3 · LESSON 1
Free — no login requiredSign in to track progress, save quiz attempts and enrol in the full course.
Sign in to track progress / enrolThe Qualification Screen
Qualification is triage, and its purpose is to fail candidates cheaply. Every candidate that reaches a business case should already have survived this.
Run the gates in order. Stop at the first failure.
Gate 1: Can you state it in one sentence?
"For each [item], decide [what], using [what information]."
- "For each inbound invoice, extract supplier, amount and PO reference from the PDF."
- "For each support ticket, decide which of six queues it belongs in, using the ticket text."
If it takes a paragraph, the candidate is either several projects or nobody has thought about it yet. Both mean stop.
The frequent failure here is the compound candidate: "handle supplier onboarding end to end". That is six decisions, and it must be split before anything else can be assessed.
Gate 2: Does the answer exist in the input?
Whatever a person uses to make this judgement — is it present in what a system would receive?
This kills more candidates than any other gate, and it does so for a reason that keeps recurring: experienced people use context nobody wrote down. A claims handler knows this broker submits sloppy paperwork. A scheduler knows this customer always calls to change the date. That knowledge is real, it drives the decision, and it is in nobody's database.
Gate 3: Is the outcome recorded, and how many are there?
You need the historical answer in a queryable form, and enough of them. Ask for the actual number rather than accepting "we have lots of data".
Also ask how far back it remains valid. Records from before a process change, a system migration or a pricing change may describe a world that no longer exists.
Gate 4: What happens at one error in twenty?
Ask it exactly that way. It forces a concrete answer, and it produces one of three:
- "Somebody notices and fixes it" — proceed.
- "It would be caught downstream" — proceed, and find out where.
- "It goes to a customer / a regulator / a patient and nobody would know" — stop, or redesign so there is a human in the path.
Gate 5: Will anyone's behaviour change?
Name the person, the moment and the tool. "The triager sees a suggested queue in the ticket list and accepts or overrides it."
If the answer is a report, a dashboard, or "the team will have better visibility", the candidate has failed. This is the MIT NANDA finding as a gate: a tool that does not enter the workflow changes nothing.
The hundred-case sample
Any candidate that clears all five gates earns a sample before it earns a business case. The method comes from AI for Non-Technical Teams and it is the single most informative afternoon in this whole course.
Take a hundred genuinely random real cases — not last week's, not a curated set — and sort them by hand:
Interpretation:
- 85+ straightforward — strong automation candidate. Automate the bulk, route the rest.
- 60–85 — viable, but the business case is assistance rather than automation, and must be argued that way.
- Under 60 — not an automation project. Possibly a good assist project. Anyone promising headcount reduction will be wrong.
You also get three things free: the recurring themes in the hard pile become your exception paths, the sorting itself is the beginning of an evaluation set, and you now have a defensible number to put in a business case instead of a vendor's estimate.
Data problem or modelling problem?
A distinction worth making explicitly, because it determines what to do next.
A modelling problem means the data exists and the question is whether a system can learn the mapping. This is a technical team's question, and usually answerable in weeks.
A data problem means the information needed is absent, inconsistent, unrecorded or trapped in a system nobody can extract from. No modelling skill fixes it.
Most failed candidates are data problems misdiagnosed as modelling problems — which is why they survive so long. A technical team will gamely attempt the model, and the failure arrives months later looking like a technical shortfall.
When you find a data problem, say so plainly and propose the data fix as its own small project. It is unglamorous, it is cheap, and it is frequently the highest-value thing on the list.
Rejected candidates come back. Someone new arrives, a vendor pitches the same thing, an executive reads an article, and eighteen months later the organisation re-litigates a decision it already made — usually without access to the reasoning.
Write a short note for every candidate you kill. Four lines:
Candidate. One sentence, in the gate-1 format.
Where it failed. Which gate, specifically. "Gate 3: outcomes not recorded — the assigned category is overwritten on escalation, so historical records show the final team, not the correct first routing."
What would change the answer. The precise condition. "If we add a first-routing field and populate it for six months, this becomes viable."
Date and who decided.
This does four things. It stops the same idea being re-proposed without new information. It turns rejections into a backlog of preconditions — a list of cheap data fixes that would unlock future projects, which is genuinely valuable planning material. It protects you, because a decision with recorded reasoning is defensible where a remembered one is not. And when someone does re-propose it, you can answer in thirty seconds instead of running the analysis again.
The last point matters more than it sounds. The cost of re-litigating decisions is one of the larger hidden costs in any organisation trying something new.
A candidate clears all five gates. A hundred-case sample yields 55 straightforward, 30 awkward and 15 genuinely hard. What should the business case claim?
The five gates
Click to flipState it in one sentence; the answer exists in the input; the outcome is recorded and countable; one error in twenty is survivable; and someone's behaviour actually changes. Run in order, stop at the first failure.
Click to flip backQualification exists to fail candidates cheaply. Run five gates in order — one-sentence statement, answer present in the input, recorded and countable outcomes, survivable errors, and a named change in someone's behaviour — then spend an afternoon hand-sorting a hundred real cases before writing any business case. Diagnose data problems as data problems rather than letting a technical team discover them months later, and write down every rejection so it does not come back without new information.