Direct answer
Scope the workflow as a small operating system: name its trigger, inputs, decisions, actions, exceptions, outputs and accountable owner. Automate only after the real path and its failure paths are visible.
Choose one bounded workflow, not a department
The right unit of automation is a repeatable path with a recognisable start and finish—not a broad ambition such as “automate operations.”
A useful workflow can be pointed at while it is happening. A request arrives, someone checks it, a decision is made, an action follows, and a record is updated. If the team cannot agree where the path starts or what counts as finished, the first job is process design rather than software.
Broad scopes hide incompatible jobs. “Automate customer support” may contain identity checks, refunds, product questions, complaint handling and incident escalation. Each has different data, authority and consequences. Treating them as one workflow makes permissions vague and testing almost impossible.
Start with a single path that happens often enough to observe, has an owner who can explain its exceptions, and produces an output that can be checked. A boring, narrow workflow is a better first automation candidate than a dramatic process whose rules change every week.
Name the trigger
Write the event that starts the work: a form submission, a signed document, a status change or a scheduled cutoff. “When needed” is not a trigger.
Name the finish
Describe the observable end state: the approved record is stored, the exception is queued, or the report is published to a named destination.
Name the owner
One role must be accountable for the workflow definition, even when several people perform its steps.
Observe the real process before drawing the clean one
Use completed examples and direct observation to document what people actually do, including side channels, retries and informal judgment.
A procedure document usually describes the intended path. Automation has to survive the path that exists. Ask the operator to walk through several recent examples from beginning to end, including one ordinary case, one exception and one case that stalled. Look at the actual inboxes, spreadsheets, portals and messages involved, without copying sensitive production data into planning notes.
Record every handoff and every place where the operator leaves the nominal system. A spreadsheet may be the official tracker while a private message supplies the context needed to interpret it. A status may look deterministic until someone explains that it is routinely overridden for a particular contract type. These details are not noise; they are the current control layer.
Separate observation from redesign. First capture the sequence faithfully. Then ask which steps can be removed, standardised or automated. Cleaning the diagram too early produces a specification for an imaginary process and forces the missing reality to reappear as production incidents.
Turn the path into states, decisions and evidence
A workflow is ready to specify when each item has a state, every transition has a condition, and consequential decisions point to the evidence used.
Flowcharts are useful, but a state model is harder to misunderstand. Give each item a small set of explicit states such as received, needs review, approved, rejected, completed and failed. For every transition, write who or what can cause it, which data is required and what must be recorded afterward.
Then inventory decisions. Some are rules: if a required field is absent, request it. Some are classifications: decide which queue should receive the item. Some are judgment: decide whether an unusual request is commercially acceptable. The first category is usually safe to automate. The second needs examples and a confidence policy. The third often needs a human owner even if software prepares the evidence.
Do not hide missing evidence inside a model prompt. If a reviewer checks a contract, policy page or account history, make that source explicit. The future system should show which version it used and preserve enough context for another person to reconstruct the decision.
State
What is true about the work item now? Use names that an operator can distinguish without interpretation.
Transition
What event is allowed to move the item, and which actor has authority to cause that move?
Evidence
Which source, field or approval supports the transition, and where will that evidence be retained?
Failure state
Where does the item go when input is missing, a dependency is unavailable or a result cannot be trusted?
Draw the line between assistance and authority
Specify what the system may read, draft, recommend, change and send; anything outside that list remains forbidden by default.
The most important scoping decision is not which model or integration to use. It is how much authority the system receives. Reading a shared inbox, drafting a response, assigning a category, changing a financial record and sending a message are different permission levels. Write them separately.
For every action, define the normal path, the approval path and the stop path. A low-consequence categorisation may proceed automatically while an external message remains a draft. A refund recommendation may be prepared automatically while the transaction requires a named approver. If the rules conflict or required evidence is absent, the safe behaviour is to stop and explain what is missing.
Permissions should also be technically narrow. Give the automation access only to the tools and records needed for the selected workflow. A policy sentence that says “do not change other records” is weaker than an integration that cannot change them.
Measure the baseline and write acceptance criteria
Use a small, auditable sample to define current volume, handling effort, error patterns and exception types, then translate them into testable release conditions.
A baseline is not a promise of future savings. It is a description of the current workload that helps the team decide whether the build is worth doing and whether the new path is better. Count real items over a representative period, note how many require rework, and record where waiting time accumulates. Keep estimates labelled as estimates.
Acceptance criteria should describe observable behaviour. “The automation works” is not testable. “Every processed item records its input, rule version, action and outcome” is. So is “items with missing account identifiers enter the review queue without an external message being sent.” Include ordinary cases, known exceptions and dependency failures.
Create the first evaluation set from historical examples only after removing or protecting sensitive data as required. Preserve the expected outcome and the reason an operator chose it. When the workflow changes, update the specification and the evaluation set together; otherwise the tests certify yesterday’s process.
Correct path
The expected output and state transition occur for representative ordinary cases.
Safe exception
Known edge cases are routed to the right owner with the relevant context, rather than guessed through.
Traceable action
Inputs, decisions, tool calls, approvals and final outcomes can be reconstructed from a run record.
Recoverable failure
Retries are bounded, duplicate work is prevented, and an operator can resume or reverse the process where the workflow permits it.
Ship a thin slice through the whole workflow
The first version should complete one valuable path end to end, with review gates and observability intact, before it expands to more cases.
A horizontal prototype that classifies everything but completes nothing leaves the hard integration and ownership questions unanswered. Prefer a vertical slice: one trigger, one supported case, the necessary data checks, one useful action, a trace and a clear exception queue.
Run the slice in observation or draft mode first when consequences justify it. Compare its proposed decisions with the operator’s decisions and investigate disagreements. Agreement alone is not enough—the operator and system can share the same mistake—so review the evidence and policy behind each result.
Expand only when the current boundary is understood. Add one exception class, permission or destination at a time, along with new evaluation cases. This keeps the automation legible and makes rollback possible. The finished scoping brief should remain a living operating document: workflow states, permissions, evaluation cases, owners and change history in one place.