How to Scope an AI Automation Project Before You Build Anything

Automation proposals often jump from problem to diagram too quickly. A workflow can look clean on a whiteboard while the real process depends on exceptions, manual judgment and data that lives in three places.

1. Map the current process

Document who starts the process, where the information arrives, each tool involved, who makes decisions and how the process ends. Include manual workarounds; they often reveal the real requirements.

2. Capture volume and timing

How many times does the process run per day? Are there seasonal spikes? Does it need a response in seconds or by tomorrow morning? Volume changes architecture and cost.

3. List every system and access constraint

CRM, email, spreadsheets, databases, forms, calendars, internal tools and vendor APIs. Note authentication methods, rate limits and whether the client can actually provide the required access.

4. Separate deterministic rules from AI judgment

Write exact business rules first. Then identify the ambiguous tasks where a model could help: reading a message, extracting intent, summarizing context or drafting language.

5. Write the ugly exceptions

Missing email. Duplicate customer. Two orders with the same reference. Angry message. API timeout. Model output that does not match the requested format. Exceptions are not edge decoration; they are part of the scope.

6. Define approval and autonomy

Name actions the workflow may perform automatically and actions that require human approval. This is especially important for payments, refunds, account changes, legal communication and sensitive customer data.

7. Agree on success metrics

Minutes saved per case, average response time, percentage of leads routed correctly, number of missed follow-ups or error rate are measurable. “AI-powered” is not.

8. Scope the handoff too

Who receives documentation? Who gets credentials? Who is trained? Who owns alerts when a workflow fails? What maintenance is included? A reliable system needs an owner after launch.

FAQ

How detailed should the first scope be?

Detailed enough that the core inputs, outputs, systems, rules, risks and acceptance criteria are clear. Do not spend weeks documenting a pilot before validating basic feasibility.

Should the client choose the automation tool?

The tool should follow requirements. Existing stack, hosting preferences, security constraints, team skill and integration support matter more than trendiness.