Most AI projects stall because nobody agreed what they were for, not because the technology failed. Before you scope an AI automation project, you have to settle a handful of questions that no vendor demo will force on you. This guide walks through seven of them, in the order a studio would raise them in a first workshop.
Three concern the work itself: the outcome, the boundary and the constraints. Four concern authority, failure and ownership. None requires a technical background, but each one, left open, tends to resurface later as a missed deadline or an awkward budget conversation. Settle them early and the rest of the project, from vendor selection to pilot design, becomes far easier to judge.
Spending on AI is rising faster than the evidence of return. A recent Harvard Business Review article on redesigning processes instead of automating them collects the numbers. BCG's January 2026 AI Radar, which surveyed 640 CEOs, reports that companies expect to roughly double AI spending this year, from 0.8% of revenue to about 1.7%. PwC's 2026 Global CEO Survey, in contrast, finds that only 12% of CEOs report both revenue and cost benefits.
McKinsey QuantumBlack's April 2026 analysis, also cited there, finds that 60% of organizations still see no enterprise-wide EBIT impact, even though nearly eight in ten use generative AI in at least one business function. The authors trace much of the gap to a habit Michael Hammer criticised in 1990: pointing new technology at existing processes instead of redesigning them. McKinsey's broader work on AI, automation and the future of work describes the potential to transform businesses, but potential is not a plan.
For an SME the lesson is practical. Teams that scope an AI automation project around outcomes give themselves something to measure, while a vague scope sets the budget, the timeline and the definition of success all at once. A model can be swapped later, but a muddled brief is expensive to unwind. That is why we treat scoping as a set of decisions rather than a document, and the document comes afterwards.
These three decisions determine whether you automate something valuable or merely something visible. They are also the cheapest to change, because nothing has been built yet. Spend your first workshop here.
Start by writing down what the customer or user actually values, which is rarely the intermediate work. The HBR authors call this the outcome test. Their example is Deloitte Australia, which agreed in 2025 to partially refund the Australian government after a report contained fabricated references and a made-up legal quote. AI had sped up the drafting, but the client was paying for reliable assurance, and that depended on source verification.
Wayfair shows the opposite pattern. Working with OpenAI, it embedded models into its catalog and supplier-support workflow, correcting 2.5 million product tags and automating 41,000 supplier-support tickets per month. The authors caution that those figures show scale, not business value, which has to appear in catalog accuracy, search and conversion, and returns. Your version of this decision is one sentence: what improves, for whom, and how will you recognise it?
Take a bookkeeping practice that wants to automate client reminders. The task is sending messages, yet the outcome is complete documents arriving before a deadline. Those two framings lead to different projects, because the second may involve fixing the request itself, not only sending it faster.
Automating one step often just moves the queue. HBR gives the example of coding agents, which can raise the volume of code produced while the constraint shifts to code review, integration testing, security review or deployment. The local gain is real, but the overall cycle may not improve, and it may even slow down. The same logic applies to an invoice process or a support inbox.
So draw the boundary from the trigger to the final outcome. List each hand-off, who owns it, and which system holds the data at that moment. Then ask the diagnostic question the authors suggest: where will the bottleneck move? If you cannot answer, your boundary is probably too narrow. If you cannot afford to cover the whole flow at once, pick one slice with a clear start and end, and name what sits outside it.
Every manual step was designed around some limit: too many items to inspect, too few experts, slow systems. Ask of each step whether that limit still binds. HBR calls this the constraint test. Wayfair's legacy catalog correction relied on suppliers and manual review because people could not continuously inspect millions of items. Generative AI loosened that limit, but not all of it, since ambiguous attributes and low-confidence corrections still went to a human or supplier for confirmation.
Take a distributor that checks every order by hand because a pricing error once cost it a customer. That check answered a past constraint, and it may still be worth keeping. Asking the question deliberately lets you decide, instead of inheriting the habit or deleting it by accident.
The result is a decision rule worth borrowing. Keep work that produces the outcome and still needs scarce judgment. Redesign work built around limits that AI has loosened. Compress necessary coordination and compliance overhead, and drop steps that serve neither the outcome nor a real constraint. Borrowing Lean language, the authors note that automating waste only produces cheaper waste.
Automate a messy process and you get the same mess, only faster.
This is where most scoping conversations run thin. Teams agree on a use case and a tool, then leave open who decides when the AI is unsure, what it may touch and who answers for the result. Those gaps separate a demo from a system a business can rely on. The next four decisions close them.
Everyone agrees a human should stay in the loop, yet few people specify what that means. The HBR authors offer a four-level model called Assist, Approve, Audit and Automate. Choosing among them comes down to two questions: who gets hurt if something goes wrong, and can your organization undo it? Keep more human control when you scope an AI automation project with high stakes or hard-to-reverse actions.
| Mode | What the AI does | What the human does | Fits best when |
|---|---|---|---|
| Assist | Offers drafts, analysis and options | Evaluates, judges and acts | Stakes are high, judgment is tacit, or cases are rare |
| Approve | Prepares an action or recommendation | Approves before anything executes | Speed matters but some risk and uncertainty remain |
| Audit | Decides and executes | Reviews samples and corrects systemic errors | Volume is high and errors are visible and reversible |
| Automate | Executes within guardrails that humans define | Steps in only for exceptions | Tasks are standard, frequent, low risk and bounded by enforceable rules |
Write the chosen mode next to each step in your scope. A single project often mixes them, because tagging routine items may suit Automate while refunds suit Approve and complaints suit Assist. The goal, in the authors' words, is not to be conservative everywhere but to be deliberate everywhere.
Demos show standard cases, while real operations are full of missing fields, ambiguous policies and documents that contradict each other. HBR argues these are not edge cases; they are the work. Before scaling, answer five questions. How will the system recognise uncertainty? What triggers escalation? Who can resolve the exception? How can an action be stopped or reversed? How will corrections improve the next cycle?
Permissions belong in this decision too. In July 2025, SaaStr founder Jason Lemkin reported that Replit's AI coding tool deleted a production database despite written instructions not to change code without permission. In April 2026, PocketOS founder Jer Crane reported that a Cursor agent deleted the company's production database and backups in seconds after finding an overly broad API token. The HBR authors read both as problems of permissions and stop lines, so irreversible actions should default to Approve unless independent controls tightly bound them.
MIT Sloan Management Review's nine questions on agentic AI adds a related habit: map every interaction between language models, tools, internal systems and users. Mapping does not remove risk, but it shows where access restrictions matter and makes unauthorized activity easier to spot.
Throughput numbers are easy to improve and easy to misread. HBR's example is a customer service agent that raises ticket closure rates by ending conversations quickly, which increases repeat contacts and leaves underlying problems unresolved. The dashboard improves while outcomes deteriorate.
So choose one primary measure tied to the outcome from Decision 1, and add guardrails that would reveal gaming. In support, resolution quality and repeat contacts guard a closure-rate target, while in an order process, error rates and returns guard a processing-time target. The authors put it plainly: if a pilot cannot name the guardrails that make its main KPI safe, it is not ready for scaling. Record today's baseline before anything is built, so you can compare honestly later.
A scope with no owner becomes a wish list. Pick one person who can accept or reject scope changes, resolve exceptions and answer for outcomes. MIT SMR's recommendations point the same way: assign explicit roles to both the human manager and the AI system at each stage, with escalation paths and evaluation checkpoints, so people remain answerable. The same article favours recurring assessments and monitoring over a single review at launch, which means the owner's job continues after go-live.
Then fix a time boundary for version one. Choose a window you can defend, list what is explicitly out, and decide in advance what evidence would justify a second phase. The point is not speed for its own sake. A boundary stops the project from absorbing every adjacent request before anyone has seen it work.
Once the seven decisions are made, the written scope fits on one page. Its purpose is to let a stranger, such as an implementation partner, understand what you want and what you do not. The HBR authors propose a sentence template that doubles as a readiness test, and a paraphrase works well as a starting point.
We will improve [outcome] in [end-to-end process] by redesigning [workflow], so that AI handles [role], people keep authority over [decisions], exceptions go to [escalation path], and we measure success by [primary metric] with [guardrails] in place.
The authors argue that a team unable to complete such a sentence has a technology experiment, not a transformation project. We would add that it is also not ready for a fixed quote, because any price would rest on guesses. Use these items as the page itself:
Data deserves its own line in the scope. Note which systems hold the inputs, whether they include personal data, and where the data would be processed. Confirm the privacy position with your data protection adviser before the build starts, since GDPR obligations depend on your data and your setup. This is also the moment to ask what the automation may read, change or send on your behalf.
If the inputs live in older systems, integration is often the real work rather than the AI itself. Our guide to what a legacy software system is helps you recognise the signs, so you can budget for that effort honestly instead of discovering it mid-project.
A pilot is not a smaller promise. It tests the same seven decisions at lower stakes, so it needs an outcome, a metric with guardrails and an exception path just as a full rollout does. Pilots that skip the messy cases tend to look good in a demo and fail in operations, which is the pattern HBR describes under ignoring the unhappy outcome.
Where to start is also a scoping decision. The authors suggest a compounding test: does the step build an asset that makes the next cycle faster, better or more defensible? A catalog correction, for example, can improve the tag definition and confidence rule for the next product. Starting where corrections feed back into the process gives you learning that outlasts the pilot, which is a firmer basis for a rollout decision than a one-off time saving.
Set the rollout trigger before you begin. Write down which result on your primary metric, with which guardrails intact, would move you to a wider release, and which would stop you. That way the decision does not belong to whoever feels most enthusiastic in the review meeting.
Scope also tells you whether you need custom work at all. If your outcome sentence describes a common function, a ready-made product may fit. First Round Review's conversation with Serval's founder, on how lessons from Verkada shaped Serval's AI agents for IT teams, describes an AI-driven IT automation and service management platform that raised $47M. It is a reminder that products now target single, narrow domains, so check for one before commissioning anything bespoke.
Custom work earns its cost when your workflow is distinctive, your exceptions are specific to your business, or the integration with your own systems is the hard part. Our piece on whether you need an AI agent integration platform helps with the platform question. Often an honest scope shows that a configured tool plus one small integration is enough.
A responsible price needs your process, but the drivers are knowable in advance. Cost rises with the number of systems involved, the number of exception paths, the authority level you choose, and the quality of the data. Higher-autonomy modes need stronger controls, logging and review, which adds design effort. Costs and suitability vary by company, so ask a qualified adviser to confirm any estimate against your own process.
Each of the seven decisions removes a source of rework. A clear outcome avoids rebuilding the wrong thing, a bounded workflow avoids surprise integration work, and defined exceptions avoid emergency fixes after launch. If you want a studio's view on your own workflow, the Xerx AI development and workflow automation service starts from exactly these questions.
Choose a process that sits close to the desired outcome, consumes expert time without needing expert judgment, uses digital inputs and can be checked quickly. HBR's authors describe those traits as the best early pilots, and they are not always the biggest problems. Bring that one workflow, a draft outcome sentence, a named owner and a list of the exceptions your team handles every week. That is enough for a useful first hour.
It depends less on documents than on how quickly your team can agree on the outcome, boundary, owner and exception handling. A process with few systems and one clear owner moves faster than one spanning several departments. Treat the written one-page scope as the output of those decisions, not the starting point.
One person who understands the process and can make decisions about it, typically an operations lead or product manager. They should be able to accept or reject scope changes and resolve exceptions. An implementation partner can facilitate the work, but accountability for outcomes stays with your side.
You need to know where the inputs live, who owns them and whether they include personal data. Cleaning the data can itself be part of the scope. Confirm GDPR and privacy questions with your data protection adviser before the build starts.
Start with the lowest level of autonomy that delivers the outcome. Assist and Approve modes keep a person in control, which suits high stakes or irreversible actions. You can move toward Audit or Automate once a pilot shows stable results with your guardrails intact.
Keep reading
A quote for a headless shop looks larger than the platform price suggests. Here is where the money goes, what founders underestimate, and when the spend pays back.
A plain-language guide for founders and business owners on writing a specification your studio can price, build and test against, without writing any code.
A compact worked example of a requirements document, with the quality targets most briefs leave out. Use it to brief a studio and get a quote you can compare.