Start with a task your team can explain step by step, such as turning an incoming email into a support ticket. Record the time it takes and the mistakes that occur today. Those observations give you a baseline for deciding whether automation helps.
This sequence matters because AI is only one component. A production automation also needs identity, source data, schemas, validation, state management, integrations, exception queues, logs, monitoring, and a manual continuation path. Starting with the model usually hides the work that determines whether the automation is reliable and useful.
Related service: AI & Automation services- 01Map the trigger, inputs, states, actors, systems, exceptions, and completion condition.
- 02Record the current volume, queue time, handling time, error and correction patterns, and cost inputs.
- 03Choose a narrow step where variable information creates repeatable friction.
- 04Assign AI, rules, people, and systems explicit responsibilities.
- 05Build a thin end-to-end workflow with validation, approval, audit, and fallback.
- 06Evaluate representative, edge, permission, and failure cases in shadow or draft mode.
- 07Launch gradually, monitor operational outcomes, and expand only with evidence.
SECTION 01
Worked example: turn an enquiry email into a reviewed CRM lead
Suppose a shared inbox receives: 'We need a booking website for three locations. Can you call next Tuesday?' The automation prepares a CRM draft with service = website, location_count = 3, and requested_callback = next Tuesday. It must resolve the date using the message timestamp and business timezone, or flag it for review. It must not invent a budget, phone number or company name.
Prerequisites are an authorized inbox connection, a supported CRM API, agreed field definitions, test accounts, and a person who owns the review queue. This is a design example, not a claim that we ran this workflow for a client or measured its results.
| Step | What runs | Output and failure handling |
|---|---|---|
| 1. Receive | Inbox webhook or scheduled connector | Store the message ID; ignore an already-processed event |
| 2. Interpret | AI extracts agreed fields into a fixed schema | Keep source excerpts; missing facts stay empty |
| 3. Validate | Code checks field types, dates and allowed services | Invalid or ambiguous records enter the review queue |
| 4. Match | CRM search checks the normalized email address | Multiple matches require a person; never merge automatically |
| 5. Approve | Staff reviews the exact proposed fields | Record corrections and approval before creating the lead |
| 6. Write | CRM API creates or updates the permitted record | Use an idempotency key or stored external ID; retry safely |
| 7. Confirm | Workflow verifies the saved record and logs status | Alert on failed writes; leave the email available for manual handling |
SECTION 02
Map the current process at the level people actually perform it
Interview the people who do the work and follow representative items through every inbox, document store, spreadsheet, CRM, ERP, and approval. Record unofficial steps and rework as well as the published procedure. Those hidden actions often explain why a simple diagram does not match operational reality.
For each step, capture the input, output, owner, system, decision rule, wait state, exception, sensitive data, and completion evidence. Note where people interpret unstructured text, search for information, re-enter data, reconcile conflicts, wait for approval, or recover from system failures. The result is a shared operating model, not an AI feature list.
| Field | Question to answer | Why it matters |
|---|---|---|
| Trigger | What event starts one item of work? | Defines intake, identity, timing, and duplicate handling. |
| Inputs | Which records, messages, files, and policies are used? | Reveals data access, quality, permissions, and provenance. |
| States | How does work move from new to complete? | Makes retries, queues, ownership, and reporting explicit. |
| Decisions | Which conditions are rules and which require judgment? | Separates deterministic control from AI interpretation. |
| Exceptions | What makes experienced staff intervene? | Creates test cases and the future exception queue. |
| Completion | What proves the item is correctly finished? | Provides an evaluation target and prevents premature closure. |
SECTION 03
Prioritize a bounded bottleneck, not an entire department
Create a candidate list from the process map and score each item for frequency, handling effort, input readiness, verification, reversibility, consequence, system access, and owner availability. High-volume work is not automatically suitable: a frequent task with unclear policy and high consequence can produce a large exception queue.
A good first slice ends in a useful operating result. “Extract fields” is a technical step; “prepare a validated intake record for review and route incomplete cases” is an end-to-end slice. The second description names the output, validation, user, and exception behavior, which makes it possible to test and deploy without pretending the full process is autonomous.
Strong candidate
Frequent, stable, evidence-based, reversible, system-accessible, and owned.
Needs preparation
Useful but blocked by conflicting policy, missing data, unstable integrations, or no exception owner.
Poor first pilot
Rare, high-consequence, hard to verify, broad in authority, or dependent on tacit expert judgment.
SECTION 04
Assign each responsibility to AI, rules, people, or systems
AI is suited to classification, extraction, summarization, retrieval, comparison, and drafting when inputs vary. Rules are suited to required fields, thresholds, totals, eligibility, permissions, and state transitions. People remain accountable for policy exceptions, ambiguous evidence, financial or contractual commitments, and decisions where context or consequence demands judgment.
Systems of record own authoritative state. The automation should read or write through controlled interfaces, preserve source references, validate schemas, prevent duplicate effects, and reconcile the final result. Do not let a generated response become an unofficial database or allow prompt text to replace identity and authorization controls.
| Responsibility | Best owner | Example |
|---|---|---|
| Interpret variable input | AI with evidence | Classify an inquiry and extract requested service and location. |
| Apply explicit policy | Deterministic rule | Reject an incomplete record or enforce an approval threshold. |
| Make consequential exception | Named person | Approve a credit, scope change, or unusual supplier. |
| Own authoritative status | CRM, ERP, or workflow system | Store the approved record and current work state. |
| Observe and recover | Operations owner plus monitoring | Handle failed calls, stuck queues, retries, and rollback. |
SECTION 05
Build a thin end-to-end slice with controls included
The first build should use real input, perform the bounded interpretation, validate the result, present an approval or exception experience, write the accepted record once, and expose status and logs. This proves the integration and operating model. A polished isolated model demo proves much less.
Use structured outputs where possible, explicit schemas, least-privilege service accounts, timeouts, retries with idempotency, queues for unavailable dependencies, and correlation identifiers across steps. Define no-answer and unknown states. A system that cannot say it lacks enough evidence will often force uncertainty into a confident-looking output.
SECTION 06
Evaluate the workflow before granting authority
Create test cases from ordinary work, edge cases, known errors, missing information, conflicting sources, permission boundaries, malicious content, and dependency failures. Judge end-to-end completion as well as intermediate behavior: retrieval, classification, extraction, validation, tool selection, approval routing, write correctness, and recovery.
Run offline or in shadow mode, then draft mode, then limited action mode. Record human corrections and the time they require. NIST's AI RMF organizes risk work around Govern, Map, Measure, and Manage; that sequence is useful here because ownership and context shape what should be measured and how failures should be handled.
- 01
Approve acceptance criteria and prohibited outcomes before testing.
- 02
Run a frozen representative set and retain failure categories.
- 03
Test prompt injection, permission, tool, timeout, and duplicate scenarios.
- 04
Compare process quality, cycle time, review effort, and unit cost with the baseline.
- 05
Require a release decision from the process, security, and technical owners.
SECTION 07
Measure operational value and expand one boundary at a time
Track work received, correctly completed, corrected, escalated, abandoned, and duplicated. Add queue time, active handling time, exception age, integration failures, unit cost, and user adoption. Segment results by case type and consequence so easy work does not hide a serious failure in a smaller category.
Expansion can mean more volume, another input type, an additional system, less review, or more action authority. Change one boundary at a time and rerun the relevant evaluation. Keep the old path available until the new operating pattern is stable, documented, supported, and accepted by the people responsible for its outcomes.
SECTION 08
Frequently asked questions
Which business process should be automated with AI first?
Choose a frequent, bounded process with usable inputs, a clear completion test, low-cost reversal, stable system access, and an owner who can review exceptions. Avoid beginning with a broad or high-consequence process.
What part of a business process should AI handle?
AI is useful for variable language and document work such as classification, extraction, retrieval, summarization, comparison, and drafting. Deterministic rules should enforce explicit policy, permissions, totals, thresholds, and state changes.
Do AI automations need human approval?
Use approval where an error becomes consequential or difficult to reverse, including payments, commitments, customer account changes, regulated decisions, or policy exceptions. Lower-risk preparation can often run with sampled review and monitoring.
How long should an AI automation pilot run?
There is no universal duration. Run it until the team has enough representative volume, edge cases, failure events, reviewer corrections, and cost data to judge every acceptance criterion—not merely until a calendar date.
PRIMARY REFERENCES
Sources and further reading
These references cover the standards, platforms, or published prices discussed in the guide. Worked examples and checklists are our editorial guidance.
- AI Risk Management FrameworkNational Institute of Standards and Technology
- Generative AI Profile (NIST AI 600-1)National Institute of Standards and Technology
- Agentic AI – Threats and MitigationsOWASP GenAI Security Project
- Working with evalsOpenAI
- Agents SDKOpenAI
EDITORIAL METHOD
About this guide
We use AI to assist with drafting and editing. Catapult AI Work is responsible for the published content. Examples illustrate possible approaches; they are not client case studies unless identified as such.
Budget examples are not Catapult package prices. Check linked provider pages for current fees and plan limits before making a purchase.
Read the editorial policy