Automation design should begin with the work as it actually happens. A process map makes the trigger, people, systems, decisions, information, exceptions, and completed result visible before a tool or model is selected.
Choose one bounded workflow
Do not begin with a department-wide label such as sales, finance, service, or operations. Choose one recurring workflow with a clear beginning and end.
Examples include:
- receive and route a new customer request;
- review and approve a purchase request;
- extract and validate information from an incoming document;
- create a recurring operational report; or
- prepare and approve a customer follow-up.
Name the person accountable for the completed result.
Record the trigger and endpoint
Write down the event that starts the workflow and the evidence that marks it complete. A trigger may be an email, form submission, uploaded file, new record, schedule, status change, or sensor event.
The endpoint should describe the business state, not the activity. “Notification sent” may be a step. “Request assigned to the correct owner with a complete record and response deadline” is closer to a completed result.
Map the normal path
For each step, capture:
- the person or system performing it;
- the input required;
- the decision or action;
- the system of record;
- the output created; and
- the next owner.
Use the language of the people who perform the work. Avoid cleaning up the map so much that manual handoffs, spreadsheets, shared inboxes, and undocumented judgment disappear.
Map exceptions before selecting technology
Ask what happens when information is missing, a record already exists, an approval is late, a user lacks permission, a vendor is unavailable, a result is disputed, or the case does not fit an approved category.
For each exception, define:
- Detect: how the condition becomes visible.
- Route: where the case goes next.
- Own: who makes or coordinates the decision.
- Record: how the reason and outcome are retained.
Exceptions often determine the real scope, review burden, and integration requirements.
Measure the current process
Use available evidence to establish a baseline. Depending on the workflow, useful measures may include:
- volume by day, week, or month;
- time from trigger to completion;
- active handling time;
- queue age and backlog;
- rework, duplicates, and corrections;
- exception volume by reason;
- handoffs and approval delay; and
- cases that remain unresolved.
If a reliable baseline does not exist, define how it will be observed during validation. Do not invent savings from assumptions.
Identify the actual constraint
The map may show that the primary constraint is not a manual step. It may be missing ownership, inconsistent rules, incomplete source data, delayed approval, unavailable integration, or too many service variations.
Some constraints are resolved through process design, policy, data cleanup, or a change in responsibility. Automating an unstable rule can make inconsistency move faster.
Separate rules, AI, and human judgment
Mark each decision according to the appropriate mechanism:
- Deterministic rule: the condition and approved action can be expressed clearly.
- AI-supported interpretation: varied language, documents, images, or context must be classified, extracted, summarized, or retrieved.
- Human judgment: uncertainty, consequence, policy, or accountability requires a person.
A production workflow often uses all three. The design should make transitions between them explicit.
Validate systems and access
List every application, database, inbox, file store, API, identity, and vendor involved. Confirm available interfaces, required licences, environments, credentials, data permissions, and the owners who can approve access.
A line on a process map does not prove that two systems can be connected safely.
Define acceptance and ownership after launch
Describe the evidence required for the normal path, known exceptions, unauthorized inputs, failed integrations, monitoring, administrator controls, documentation, and handover.
Name who will review exceptions, maintain credentials, monitor failures, approve changes, support users, and coordinate vendors after launch.
Choose the next step
A bounded workflow with a named owner, validated access, known exceptions, and testable acceptance may be ready for an AI Automation Sprint. A workflow with unresolved process or architecture questions may first need a focused blueprint.
Bring one workflow and the people who operate it
Book an Implementation Fit Call to determine whether the workflow is ready for technical validation or needs prerequisite process work.