Start with a piece of work you recognize
“We need AI automation” leaves a business owner with too many possible starting points. Choose a workflow you can describe from an observable trigger to a useful outcome. A customer inquiry arrives and receives an appropriate response. A supplier document is reviewed and added to a record. A support issue reaches someone who can resolve it.
Walk through the current process before choosing a tool. Notice where information is already structured, where someone interprets it, where a decision is made, and where an action changes a system. These are different kinds of work. Treating them separately makes it easier to decide where AI could help and what needs to be defined first.
Separate interpretation, rules, and authority
AI can help interpret variable information: summarize a message, extract requested services, compare a request with reviewed business context, or draft an acknowledgment. Those outputs still need checks appropriate to their use. An extracted detail may be missing or wrong; a plausible draft may contain an unsupported promise.
Ordinary automation follows explicit conditions and actions. It can create a record when required fields are present, assign a task using an agreed rule, or flag a response that has missed its target. Human authority determines the outcome, approves consequential actions, and resolves exceptions. A useful system can combine all three roles without giving the model control of the entire process.
Inspect six workflow zones
At CoreUX, we use six zones as a practical map: Capture, Understand, Decide, Create, Execute, and Monitor. A real workflow may loop, branch, or skip a zone. Use the map to inspect the work, rather than force every business process into the same sequence.
Scroll sideways to see all columns.
| Zone | What to inspect | A useful boundary |
|---|---|---|
| Capture | Forms, messages, documents, calls, or system events. | Preserve the source and distinguish structured fields from extracted details. |
| Understand | Extraction, classification, summarization, and normalization. | Define expected fields and a route for missing or uncertain answers. |
| Decide | Priority, ownership, eligibility, or a proposed next step. | Separate recommendations from the authority to act. |
| Create | A draft response, summary, report, or other artifact. | Specify allowed sources and the review needed before use. |
| Execute | Creating records, assigning tasks, updating systems, or sending messages. | Permit explicit actions using checked inputs. |
| Monitor | Unfinished work, exceptions, failed actions, and recovery. | Make failures visible to someone responsible for resolving them. |
Follow one customer inquiry through the map
Imagine a small service business receiving an email asking about a project. The example is illustrative. Capture saves the original message and records when it arrived. Understand extracts the requested service, the location if supplied, and the questions that still need an answer. The output should leave missing details blank or mark them as unresolved.
Decide compares the request with approved service and routing information. The result might suggest a service category and an owner, with a reason a person can inspect. Create prepares an internal summary and a proposed acknowledgment. A reviewer checks the business promises and any uncertain details.
Execute then creates the permitted CRM record and assigns the next task. Sending a message is a separate action whose approval rule must be explicit. Monitor checks whether an owner exists, required information is still missing, or the task has stalled. An exception reaches a person with the original inquiry and enough context to continue the work.
Use AI where variation creates a real task
If a form already supplies the selected service and an agreed rule identifies the owner, routing may need no AI interpretation. If an email describes several needs in different language, extracting and proposing a category could be useful. The difference is the work the system must perform.
Write down what the model receives and what it should return. For inquiry classification, that might be the original message, a short approved service list, and a defined set of categories. Include an “unclear” outcome instead of requiring a confident choice every time. Try examples that contain incomplete requests and conflicting details. Review the errors before deciding whether the output is suitable for the next step.
Design the exception before connecting the action
A workflow needs a way to continue when the happy path breaks. Consider what happens if the source is incomplete, the model cannot classify it, the CRM is unavailable, or the assigned person is absent. Each condition needs an observable state and a responsible owner.
For the sample inquiry, keep an unresolved request in an exception queue with its source, the problem, and the next action. An integration failure should preserve the work for recovery. Repeated delivery should also be considered: ask how the system recognizes an inquiry it has already processed so a retry does not silently create duplicate work. These are design questions to resolve and test during a pilot.
Answer six questions before a pilot
Select one recurring workflow and complete this checklist with the people who operate it. A missing answer tells you where alignment or investigation is needed. The checklist is a starting point for scoping; the intended use still determines the level of review and testing.
- Frequency: does this workflow repeat often enough to justify maintaining a system for it?
- Trigger: what exact event starts a new piece of work?
- Inputs: which sources may it read, and who keeps those sources current?
- Output: what artifact or state should exist when the work is complete?
- Authority: who approves consequential decisions and outward-facing actions?
- Recovery: who receives incomplete, uncertain, rejected, or failed work?
Test a small transition
Begin with a narrow candidate, such as preparing an internal inquiry summary for review. Keep the source beside the result and ask the reviewer to identify missing details, unsupported statements, and useful information. Record what was checked and what still failed.
Only connect further actions after the team understands that output and its limitations. This gives you concrete evidence for the next decision: improve the input, revise the task, add a rule, change the review, or stop the pilot. The six-zone map helps locate the opportunity. The observed behavior of your workflow determines whether to continue.