Scanning your operation

A common pattern: a team picks the AI project that came up in the last leadership meeting. Three months later, the project either works (and was the wrong place to start) or doesn’t (and the leadership team concludes “AI isn’t ready”). Both outcomes are expensive in different ways. Neither was the result of looking at the operation first.

The next chapter — where AI fits — explains what a good fit looks like once a candidate is on the table. This one is about the step that should happen earlier: surfacing the candidates worth examining at all.

It is a four-move method. Inventory, filter, prioritise, pick one. The hard step is the first — looking carefully enough at the actual shape of the work to see where AI could plausibly land. The other three are mechanical once the inventory is honest.

Move 1 — Inventory the work

The mistake most operations make at this step is starting from the AI side: “what could AI do for us?” The list that comes back is generic — drafts, classification, summaries — and translates into nothing.

The move that works is starting from the operation side: “where does the work actually happen, and which of it is dull / slow / repeated?” The list that comes back is specific to the company and immediately legible.

Four entry points into the inventory tend to surface different candidates. A thorough scan uses all four.

By function

Walk the org chart. For each function, write three to five sentences naming the work that takes most of the time. Not titles — work shapes. The unit is “the team spends X hours/week on Y.”

Most of the candidates AI can plausibly help with fall into a small number of shapes, distributed across functions:

Sales. First-draft outreach, prospect research summaries, call note extraction, CRM hygiene (filling in missing fields), proposal customisation.
Marketing. Content drafts — blog posts, social posts, ad copy variations. Audience research synthesis. Brief generation. Brand-voice rewrites.
Operations. Internal documentation, process write-ups, standard operating procedure drafts, meeting note distillation, ticket routing.
Customer support. First-response drafts, classification (urgent / routine, billing / product / account), knowledge-base search, summary of long ticket threads.
Finance and admin. Expense categorisation, invoice extraction, contract clause-checking, recurring report assembly.
HR. Job description drafts, screening summaries, policy Q&A bots, onboarding doc generation.
Engineering and IT. Code drafts and refactors, log analysis, internal tool builds, documentation.

This list is a starting point, not a destination. The operation’s actual list will have items not on this list (industry-specific work shapes) and will be missing items that are on it (functions the operation doesn’t have, or work it does differently). The point of the function pass is to make sure no whole part of the business is missed.

By recurring meeting

The work that shows up in regular meetings is the work the operation has decided is important enough to talk about repeatedly. Look at the standing meetings:

The weekly sales pipeline review — what gets re-asked every week? Often a status update that takes someone an hour to prepare and ten minutes to deliver.
The monthly ops review — what gets compiled fresh each time from the same sources?
The quarterly business review — what slides take the longest to build, and why?

A meeting that exists to recover information that already lives somewhere is, more often than not, masking a candidate.

By the questions the leadership team keeps getting asked

The leader of any function gets the same questions repeatedly. “What’s the status of X?” “How are we tracking on Y?” “What did the customer say about Z?” If the leader is answering the same five questions every week, those questions are a candidate — usually for summarisation or for a small grounded Q&A tool that reads from the systems that hold the answers (see tools and memory).

This entry point surfaces candidates the function-walk often misses, because the work happens to the leader, not inside the function.

By the bottlenecks people complain about

Friction is signal. Where does work pile up? Where do handoffs break down? Where does a person say “I spend half my Monday on this” and not enjoy the part of their Monday they’re describing?

This pass tends to surface the highest-leverage candidates, because the operation has already identified them as painful — they just haven’t been framed as AI candidates yet.

The output of Move 1 is a list. Twenty to forty work shapes, written in the operation’s own language. Most will not be AI candidates. That is fine; the next move is the filter.

Move 2 — Filter against the fit anatomy

The fit anatomy — high volume, language-shaped, tolerates approximate, currently underloved — is the screen. Pass each inventory item through it.

High volume. Does this work happen often enough to repay the work of building or buying around it? A weekly task at a 200-person company is high volume. A monthly task probably is not.
Language-shaped. Is the input and output mostly text, or readable as text (transcripts, structured documents, descriptions, code)? Numerical work and physical work fail this screen.
Tolerates approximate. Is 90% right useful — because a human catches the rest, or because the cost of an occasional miss is bounded? Anything where exact correctness is the whole point fails this screen.
Currently underloved. Is this work that gets delayed, that nobody volunteers for, that the team would happily hand off? If the work is well-loved and well-staffed, AI is competing with a working solution.

Most of the inventory items will fail at least one property. The ones that pass three or four are the candidates. Typically a forty-item inventory leaves eight to twelve candidates after the filter.

A second screen at this stage is the bad-fits patterns covered in the next chapter — safety-critical without oversight, exact-number, strict-consistency, unverifiable output, undocumented company knowledge. Candidates that pass the four-property anatomy but trip the bad-fits screen should be flagged as harder-than-they-look, not eliminated outright. Some are workable with the right shape of human review around them; some are genuinely not.

Move 3 — Prioritise on value × effort × risk × reversibility

The filter leaves a short list of plausible candidates. The temptation now is to pick the highest-value candidate and pilot it. That is usually the wrong move.

The first pilot’s job is not to maximise immediate return. It is to teach the operation how AI lands in its own seams — how the work changes, how the team responds, what governance is needed, what gets reviewed, what breaks. The candidate that teaches most per unit of risk is the right first pilot, even if it is not the highest-value option on the list.

Four axes weigh in:

Value. How much time, money, or quality lift if the pilot works? Order of magnitude is enough; precision is wasted effort at this stage.
Effort. How much work to stand it up? Off-the-shelf product vs. light custom build vs. heavy engineering. Time-to-first-output is the proxy.
Risk. What is the blast radius if the AI is wrong and nobody catches it? Internal draft = low. Customer-facing autoreply = high. Financial-decision input = very high. (Building trust covers the patterns that gate each level.)
Reversibility. Can the operation pull the plug if it isn’t working, or is the change embedded in a way that’s hard to undo? Tools that augment current work are usually reversible. Tools that replace a process are usually not.

A useful rough ranking: sort the candidates by a rough product of value × reversibility, divided by effort × risk. The candidate that comes out near the top is typically not the most ambitious one. It is the one with workable value, manageable effort, contained blast radius, and an easy off-ramp if it doesn’t pan out. That is the candidate the operation can run a real experiment on without breaking anything.

Move 4 — Pick one to pilot

Three or four candidates will cluster at the top of the ranking. Pick one.

What makes the right pick at this stage is not “which one has the best business case on paper.” It is “which one will produce a clear yes/no answer fastest.” A pilot that runs for six months and ends with “it sort of helped, hard to tell” has cost the operation more than the time and money — it has cost it confidence and momentum.

Picks that produce clear answers tend to share three features:

A measurable before-state. The operation knows the current time-per-unit, throughput, or quality bar of the work without AI. (More on this in how you know it’s working.)
Bounded scope. One function, one shape of work, one team. Not “AI for support” — “AI-drafted first responses for tier-1 support tickets in the SaaS product line.”
A low blast radius. Wrong output is caught before action. Internal drafts, classification with human review, summarisation with the source attached. Saves the operation from learning two lessons at once if the first attempt has bumps.

The other candidates from the top of the list become the second-year roadmap. They are not abandoned; they are sequenced.

A worked example

A made-up company to walk through the moves concretely. Northwind Industrial — a 200-person distributor of specialty industrial parts, mid-sized, profitable, mostly B2B. Headquartered in the US, with operations in two countries. Not yet using AI in any structured way.

Move 1 — Inventory. A two-hour workshop with function leads. The list (abbreviated):

Sales — outbound emails to new accounts (45 min/lead, ~200 leads/month); custom quotes built from a product catalog (30 min/quote, ~80/week); CRM cleanup (Friday afternoons, ~3 hr/rep/week).
Customer support — order-status questions (60% of inbound, mostly answerable from the order system); returns paperwork (manual, 15 min/return, ~100/month); ticket triage (manual, 3 levels deep).
Operations — weekly inventory variance report (one analyst spends 6 hr/week assembling); supplier onboarding paperwork (~20 hr/new supplier, ~4 new/quarter).
Finance — invoice matching against PO line items (manual, ~15 min/invoice, ~600/month); expense report categorisation (~10 hr/week for the controller).
HR — onboarding doc packets (~4 hr/new hire, ~3/month).
Leadership — quarterly board prep (3 weeks of pulling numbers from five systems).

Move 2 — Filter. Running each item through the four properties:

Outbound sales emails — high volume ✓, language-shaped ✓, tolerates approximate ✓ (rep reviews before sending), underloved ✓. Candidate.
Custom quotes — high volume ✓, language-shaped (kind of — also has numbers), tolerates approximate ✗ (numbers must be exact), underloved partially. Flag as harder-than-it-looks (numbers belong in a tool, not a prompt).
CRM cleanup — high volume ✓, language-shaped ✓, tolerates approximate ✓, underloved ✓. Candidate.
Order-status questions — high volume ✓, language-shaped ✓, tolerates approximate ✓, underloved ✓. Candidate. (Also: probably a grounded Q&A tool with read access to the order system.)
Returns paperwork — medium volume, language-shaped ✓, partially tolerates approximate. Maybe.
Ticket triage — high volume ✓, language-shaped ✓, tolerates approximate ✓ (escalation safety net), underloved ✓. Candidate.
Inventory variance report — low volume (weekly), partially language-shaped, exact-number territory. Flag.
Supplier onboarding paperwork — low volume, language-shaped ✓. Maybe.
Invoice matching — high volume ✓, exact-number territory ✗. Flag (rules engine more than AI).
Expense categorisation — high volume ✓, language-shaped (descriptions), tolerates approximate ✓, underloved ✓. Candidate.
Onboarding doc packets — low volume, language-shaped ✓. Maybe.
Board prep — quarterly, mixed numbers + narrative. Maybe.

The filter leaves five strong candidates: outbound emails, CRM cleanup, order-status questions, ticket triage, expense categorisation.

Move 3 — Prioritise. Sorting on the four axes:

Candidate	Value	Effort	Risk	Reversibility
Outbound emails	Medium	Low (off-the-shelf product)	Low (rep reviews)	High (turn it off)
CRM cleanup	Medium	Low	Low	High
Order-status Q&A	High	Medium (needs system access)	Medium (customer-facing)	Medium
Ticket triage	Medium	Low-Medium	Low (escalation gate)	High
Expense categorisation	Low	Low	Low	High

The ranking that comes out: outbound emails and CRM cleanup are both low-risk, low-effort, reversible. Ticket triage is close behind, with slightly more complexity. Order-status Q&A is the highest-value candidate but also the highest-effort and most customer-facing — a riskier first pilot.

Move 4 — Pick. The conversation at this point is the most useful conversation a leadership team can have about AI at the start of an adoption arc. Northwind’s leadership picks outbound sales emails as the first pilot. Not because it is the highest-value option (it isn’t), but because:

The before-state is measurable: average minutes-per-lead, response rate, quality bar.
The scope is bounded: one team (the outbound rep team), one shape of work (cold emails to new accounts).
The blast radius is low: rep reviews before sending.
The pilot will teach the operation how AI lands in a real workflow without anything customer-facing breaking if it goes wrong.

Order-status Q&A goes onto the second-year roadmap as the candidate to revisit once the operation has learned how AI behaves inside one workflow. CRM cleanup and ticket triage queue behind it.

The reading the rest of Module 5 builds on

The output of a scan is not a single answer. It is a ranked list, a chosen first pilot, and a sequenced roadmap of the next few. The remaining chapters of Module 5 — the fit anatomy, build vs. buy, project shape, measurement, what to watch for in production — are about turning the chosen pilot into a working system without the predictable failure modes.

The scan itself is the work most operations skip and then regret skipping. Done once carefully, it pays back across every subsequent AI decision the operation makes for years.