Leverage is a precise idea: a small input producing a disproportionate output, repeatedly. Most AI deployments fail this test not because the technology underperforms, but because it was applied to a step that was never the constraint.
The test for leverage
Before any AI project, four questions. If you cannot answer all four with a number, you are buying novelty.
- How often does this task run? Under 20 times a month, automation rarely repays its own maintenance.
- What does one run cost today? In minutes, and in the seniority of the person doing it. Ten minutes of a director's time is not ten minutes.
- What happens downstream when it is slow or wrong? This is where the real number usually lives — a two-hour quote delay that costs a 20% win rate matters far more than the two hours.
- Can the output be checked cheaply? If verifying the AI's answer takes as long as producing it, there is no leverage. This single question eliminates most bad ideas.
The four legitimate patterns
Nearly all durable AI value in operating businesses falls into one of four patterns. Recognising which one you are attempting sets the expectations correctly.
1. Reading — turning unstructured input into structured data
Supplier invoices, delivery notes, RFQs, emails, scanned forms, engineering drawings. The task is extraction against a known schema.
Why it works: the output is verifiable field-by-field, errors are visible immediately, and the volume is high. Expect: 85–95% straight-through processing with a human queue for exceptions. Do not expect: 100%. Design the exception path first, not last.
2. Drafting — producing a first version a human finishes
Quotations, scopes of work, tender responses, job descriptions, customer replies, incident reports.
Why it works: the blank page is the expensive part, and editing is far faster than composing. Expect: 50–70% reduction in time-to-first-draft. Do not expect: to remove the reviewer. The reviewer is the control.
3. Classifying and routing — deciding where something goes
Ticket triage, enquiry qualification, expense coding, quality-defect categorisation, document filing.
Why it works: the decision is repetitive, the categories are stable, and mistakes are cheap and reversible. Expect: the elimination of a queue, not of a role. Do not expect: good results if your categories are ambiguous to your own staff — the model will not resolve what humans dispute.
4. Explaining — answering questions over your own material
Internal policy, product specifications, historical job records, maintenance manuals, contract terms.
Why it works: knowledge held by two or three people becomes available to everyone, at 2am, without an interruption. Expect: real gains where documentation is good. Do not expect: anything at all where documentation is poor. This pattern amplifies your knowledge base; it does not create one.
Where AI is not the answer
An honest list, because attempting these is the most common way to burn a budget and the organisation's patience:
- Deterministic rules. If it can be written as an if-statement, write the if-statement. It is cheaper, faster, auditable, and never hallucinates.
- Arithmetic and reconciliation. Matching payments to invoices is a database join. Do not send it to a language model.
- Anything with a single, legally exact answer where you cannot check the output — statutory filings, safety certifications, regulated disclosures.
- Processes nobody has defined. Automating an undefined process encodes today's confusion permanently.
- Low-frequency, high-variance judgement. Pricing a one-off bespoke contract. The volume never justifies the build, and the variance defeats the pattern.
Sizing the gain before you build
A one-page calculation that takes twenty minutes and prevents most bad projects:
- Volume — runs per month (V).
- Current unit cost — minutes per run × loaded hourly rate ÷ 60 (C).
- Realistic residual — what still needs a human afterwards, honestly stated as a percentage (R). For reading tasks assume 15%; for drafting, 40%.
- Downstream effect — the value of the step being faster or more consistent (D). Often larger than the labour saving; state it even if the estimate is rough.
- Annual gain = V × 12 × C × (1 − R) + D.
- Against build cost + annual run cost + the cost of the exception path you must staff.
If the ratio is under 3:1 in year one, do something else. There is always a better candidate — and if there is not, the constraint is elsewhere in the business.
Implementation sequence that survives contact with reality
- Pick one workflow with a named owner. Not a department, a workflow. Ownerless pilots die at the first obstacle.
- Run it manually for two weeks and record everything. Inputs, outputs, edge cases, disagreements. This becomes both your specification and your evaluation set.
- Build the narrowest version that could possibly help. One document type, one customer segment, one region. Narrow scope is what makes the quality measurable.
- Shadow-run it. The AI produces output alongside the human for two weeks. Nobody depends on it yet. Compare, count disagreements, categorise them.
- Set the confidence threshold from real data. Above it, straight through. Below it, human queue. This number comes from your shadow run, never from a vendor's default.
- Go live with a rollback. One switch returns to the manual process. Its existence is what makes the team willing to try.
- Re-measure at 30 and 90 days against the baseline you captured in step 2. Publish it honestly, including where it underperformed.
The three metrics that tell you it is working
- Straight-through rate — the percentage completed with no human touch. Should rise and then plateau. A plateau is fine; a decline means drift.
- Time-to-complete, end to end — including the exception queue. If this has not moved, you have shifted work, not removed it. This is the most commonly hidden failure.
- Reversal rate — how often a human overrides the output. Under 5% and you may be over-reviewing; over 20% and the model is not ready for that scope.
What separates leverage from hype
Leverage is boring, narrow, measured, and owned by someone whose job gets easier. Hype is broad, demonstrated rather than measured, owned by a committee, and described in capabilities rather than outcomes.
The practical discipline is simply this: find the constraint first, apply the smallest possible intervention to it, measure against a baseline you captured beforehand, and expand only along evidence. Firms that do this compound a real advantage. Firms that start with the technology and search for a use case fund an education — usually a costly one.
