Five Questions That Scope an AI Automation Project

Most AI automation projects don't fail during the build. They fail three weeks before anyone opens a code editor, when a team spends £15,000 in consultancy time trying to describe what they actually want. The scoping phase is where money disappears quietly and momentum dies.

The reason is usually the same: teams start with the technology ("we want to use an LLM for this") instead of the process. If you reverse that — start with the process, expose the breakage point, and then decide what kind of automation fits — scoping shrinks from a six-week discovery to a focused conversation.

Here are the five questions that will get you there.

1. Where does the process crack under volume?

Not "where is the process slow", but where does it break when the load doubles?

A single ops coordinator handling supplier compliance documents at 40 shipments a month is fine — slow, but fine. At 120 shipments, the same person is the bottleneck, documents are missed, and freight gets held. That's the crack. That's where automation earns its cost.

Write one paragraph describing the scenario at 3× your current volume. If it reads like a catastrophe, you've found your target. If it reads like "a bit stressful", keep looking — automation at that point is an optimisation, not a necessity, and the ROI case will be thin.

This also forces you to be specific about the unit of work. Not "document processing" — but "supplier certificates of origin that arrive by email, need to be matched against a shipment reference, and filed into the freight system within four hours". That sentence is a scope. "Document processing" is not.

2. Where does the data actually live?

AI automation is only as good as the data it can reach. This is the question most ops teams underestimate, and it's where data readiness becomes a practical blocker rather than a technical footnote.

Draw a quick map:

• Inputs: Where do the documents, requests or records come from — email inboxes, shared drives, a CRM, a WhatsApp group, a paper form someone photographs?
• Reference data: What does the AI need to check against — a product catalogue, a supplier list, a tariff code table?
• Output destination: Where does the result need to land — a spreadsheet, a TMS, a customer portal, a human inbox?

If your inputs arrive via email and your output needs to go into a system with no API, the automation is still possible but the integration is now a meaningful chunk of the build. You need to know that before you price anything. Surprises at this stage are how a £30,000 project becomes a £60,000 project.

One useful shortcut: ask your team "what would you need to copy-paste if you were doing this manually at midnight?". That list is usually your data map.

3. Who reviews the output — and what does that review look like?

There is no serious AI automation for B2B operations that runs without a human check somewhere in the loop. The question is not whether there's a review step, but what form it takes and at what point in the process.

A lightweight review looks like: the AI drafts a supplier rejection notice, it appears in a coordinator's queue with a confidence flag, the coordinator reads it, clicks approve, it sends. Thirty seconds of human time, full accountability, full audit trail.

A heavier review looks like: every AI-classified document is manually verified before it touches any downstream system. That might make sense for a customs classification workflow where a wrong HS code costs you a penalty. It might be overkill for routing a venue enquiry to the right team inbox.

Be explicit about this before you build. The review model affects the UI, the staffing model, the audit log, and critically — the cost justification. If your reviewer is spending two minutes per record and you're processing 500 records a day, you need to factor in 16 hours of review time. That might still be far cheaper than the all-manual baseline, but it needs to be in the numbers. The Human-in-the-Loop AI Cost Model is a fast way to sense-check this before you commit to a build.

4. What does a failure actually cost?

This is the question vendors rarely ask, because the honest answer shapes the architecture — and therefore the price.

For some processes, a false positive is embarrassing but recoverable: the AI misroutes an enquiry, a person catches it in twenty minutes, no harm done. For others, a failure is a regulatory event: a misclassified import document, a missed compliance deadline, a contract sent with the wrong commercial terms.

You need to know which category you're in before you design the workflow. High-consequence failure means you need stricter confidence thresholds, mandatory human sign-off before any action, and a clear escalation path. It does not mean you can't automate — it means you build in the right guardrails, and you test against the failure mode, not just the success mode.

A practical test: run your proposed workflow mentally against your three worst-case scenarios from the last 12 months. If the automation would have caught them, great. If the automation could have caused them, you know what to build around.

5. Build, buy, or configure?

The answer to this depends on how much your process differs from a standard workflow.

If you're routing supplier enquiries by category, there are SaaS tools that do this reasonably well out of the box. Configure them, connect them to your inbox, and move on. You don't need a custom build.

If you're processing highly specific documents — say, exhibition contractor risk assessments with a non-standard format, cross-referenced against a site-specific checklist — no off-the-shelf product handles that cleanly. That's when a custom workflow pays for itself, because the "good enough" tool either misses half the documents or requires so much manual correction that you've built the bottleneck back in.

The build-vs-buy decision is easier once you've answered questions one through four. If your data is clean, your process is well-defined, your failure cost is understood, and your volume justifies the investment, a custom build scoped tightly is often faster and cheaper than adapting a generic product that almost fits. In-House vs Partner for AI Workflow Delivery covers the staffing side of this trade-off in more detail.

What a good scoping document looks like

Once you've answered these five questions, you should be able to produce a one-page brief that contains:

• The process: one paragraph, specific unit of work, current volume and failure point
• The data map: inputs, reference data, output destination and integration requirements
• The review model: who approves, at what point, what the SLA is
• The failure cost: regulatory, financial or reputational consequence of a wrong output
• The build decision: custom, configured SaaS, or hybrid — with a first-pass rationale

That brief is enough to get a realistic cost estimate from a development partner. It is also enough to run a focused discovery session that takes two days rather than two months. If you're not sure where your numbers land, the AI Project Cost Calculator gives you a first-pass figure for discovery, build, review, and year-one run cost before you start those conversations.

The biggest time-wasters in AI scoping are vague process descriptions and undefined review models. Operators who arrive at those conversations with specific answers — real document volumes, named systems, explicit failure consequences — consistently get better builds at lower cost than teams that hand a vague problem to a vendor and let them define the scope.

Do the five questions first. The vendor conversation becomes much more productive when you're correcting a draft brief rather than starting from a blank page.

When you're ready to go further

If you've done this and found your process is genuinely suited to a pilot, What an AI Ops Pilot Actually Costs in the UK gives you a grounded view of what discovery-to-live looks like in practice — including where costs accumulate that most operators don't expect.

Useful tool

Try Samvara's AI ROI Calculator — Hours saved, annual savings and payback.