What you can explore
1. What problem would this solve?
People move the same information between tools, and nobody has mapped the exceptions. A procedure may look straightforward while exceptions, missing fields and handoffs occupy the team’s attention. The first job is to document these variations.
2. What could become easier?
- See where repeated work happens.
- Know what must remain human-led.
- Identify simpler changes before using AI.
The aim is to make a clearer decision, with practical checks before relying on AI output.
3. What practical support could include
A possible starting point: A workflow-mapping and automation suitability review. A scoped engagement might produce:
- Before-state workflow and handoffs
- Task-frequency and variability inventory
- Exception and error-path map
- Responsibility and human-approval points
- Prioritized automation candidates
Any practical support would be scoped to the task, available information and agreed responsibilities.
4. Why this approach?
We distinguish deterministic rules, possible AI assistance and decisions that should remain with staff. The process map includes error paths rather than showing only the easiest case.
5. What evidence supports these recommendations?
A step-by-step hypothetical inbox example shows how to separate automation opportunities from claims about any actual client’s workflow. OWASP supplies background on model-driven actions.
6. How might we work together?
Observe a process; list exceptions and data classes; draw responsibility lanes; identify candidates for a controlled trial.
Practical guide: how to make this decision
Worked sample: see the steps before automating
A fictional service team receives enquiries by email, copies details into a tracker, searches for an owner, then sends a reply. Draw as-is steps first: email arrives → staff checks required fields → duplicate search → owner assignment → reply drafted → human approval → response sent. For the to-be version, automate only the deterministic intake and duplicate flags; keep uncertain classifications and the final send in human review.
| Control point |
Normal case |
Exception and human response |
| Contact fields |
Name, email and topic provided |
Missing consent or contact detail → hold, do not enrich automatically |
| Duplicate check |
Match an existing case identifier |
Similar name but different email → show candidates, do not merge |
| Category |
One unambiguous request type |
Multiple topics → route to a person |
| Reply |
Approved template, checked facts |
Unsupported policy claim → return to reviewer |
The scoped deliverable is a process map plus validation, handoff and exception register, not a claim that any platform has been configured. Use synthetic enquiries in the initial exercise.
Evidence and important limits
- OWASP describes prompt-injection threats and practical mitigations; it does not establish that the user’s system has a vulnerability. [S01]
Evidence references
Start with a map of the work as it really happens
Automation begins with observing work, not with choosing an AI tool. Imagine an operations assistant who opens a shared inbox, reads incoming requests, copies names and reference numbers into a tracking sheet, checks whether an attachment is present and sends an acknowledgement. A procedure document might describe a straightforward sequence, while everyday practice includes missing attachments, repeated messages, incorrect reference numbers and requests sent to the wrong department. Those exceptions are often where an automation attempt fails. A useful workflow review therefore records the happy path and the exceptions. NIST's AI Risk Management Framework Playbook recommends understanding context and documenting operational responsibilities before risk decisions [PLAYBOOK]. It does not prescribe a particular vendor or guarantee an outcome.
Build a task inventory before discussing an AI agent
Capture each step in a simple inventory with fields for trigger, volume or frequency, person responsible, system used, information handled, variation, errors and current check. Frequency may be observed or estimated, but label it. A task that occurs regularly and has clear rules may be suitable for ordinary software automation without a language model. A task with variable, ambiguous text might benefit from assisted classification, subject to testing. A task involving judgment about disputed cases should usually retain a person. Ask employees where they make workarounds: manually correcting names, searching for the latest template or resolving duplicate requests. These are clues about process design, not proof that artificial intelligence is needed.
Illustrated workflow: incoming service requests
This is a hypothetical office example, not an observed client process. The current workflow is receive → read → copy details → search policy → update tracker → acknowledge → escalate unusual cases. The proposed review divides it into three categories. A basic rule might assign a date and unique identifier. An AI-assisted step might suggest a request category from approved examples. An employee would still resolve conflicting information, check policy and authorize an external acknowledgement. If the system cannot identify a required field, it should produce a needs review status rather than inventing the missing entry. Mapping these boundaries changes the initial question from “Can we automate the inbox?” to “Which steps can safely be standardized, suggested, reviewed or left manual?”
| Workflow step |
Potential approach |
Example failure |
Essential check |
| Capture receipt time |
Existing rule-based function |
Wrong timezone |
System timestamp test |
| Extract stated request category |
Assisted text classification |
Two different intents in one message |
Reviewer confirms category |
| Match a customer record |
Approved deterministic lookup |
Similar names |
Authorized identifier match |
| Draft an acknowledgement |
AI-assisted template draft |
Invented promised response date |
Human review before sending |
| Approve exceptional request |
Human decision |
Policy exception mishandled |
Named supervisor |
Measure task characteristics, not fashionable terminology
For each step, record how often it is performed, how much the input varies, whether the output can be checked, the consequences of an error, and whether the necessary system access is authorized. A useful two-axis grid places repeatability on one axis and consequence of error on the other. Frequent, low-consequence, well-defined tasks deserve consideration first. Variable, consequential actions demand stronger testing and explicit authority. “Easy to automate” should never be inferred solely from how long the step takes. A brief approval action may be more consequential than an hour of drafting. Similarly, high task volume does not justify a system that routinely mishandles rare but important exceptions.
Make the human-check path visible
Draw lanes for the requester, employee, approved software, AI-assisted component and supervisor. Show who owns each decision and who can stop or correct it. A proposal becomes incomplete when the diagram ends at “AI sends response” without specifying who checks that response, whether the customer is informed appropriately, and how a mistake can be fixed. OWASP's guidance on excessive agency and improper output handling identifies security concerns when model-generated content is allowed to trigger actions without sufficient constraints [OWASP]. The exact controls depend on what the system can access and do. For a first mapping workshop, document the actions that should remain read-only and those that would require authorization.
Identify the information that automation would touch
An incoming email might include personal contact details, a contract, or internal operational information. Inventory the categories and the organizational owner of each dataset; do not merely ask whether content is “sensitive” in the abstract. Check whether an approved environment exists, whether access follows employees' roles, and whether a draft would be stored or passed to another system. If an AI tool cannot be used with the required data, an offline synthetic example can still help map the work. No participant should paste private records into an arbitrary assistant just to demonstrate feasibility. If permissions are uncertain, record a blocking dependency instead of recommending that the team proceed.
Define exceptions before creating a test
Write down at least five exception types relevant to the task: missing field, contradictory details, duplicate request, unsupported document format and request outside the approved policy. For each, specify the intended outcome—ask for clarification, route to a person, reject the operation, or hold the record. A test pack that contains only clean examples hides the most important operational burden. An evaluator should also check false positives, where a system believes a case is routine but it actually needs special handling. Add an exception log with date, example type, observed behavior, reviewer and action taken. This log later helps distinguish prompt changes from genuine process improvements.
What a useful workflow deliverable contains
The finished mapping pack should show the current process, candidate future process, separate rules-based and AI-assisted steps, human checkpoints, data permissions, and unresolved exceptions. It can recommend simple fixes such as clearer request forms, improved naming conventions or removing duplicate entry before recommending new software. That is a meaningful result, even if no AI pilot is approved. A good diagram makes the proposed intervention visible enough for another team member to question or reproduce it. It should also identify the intended process owner who will maintain the procedure after any changes.
How this service differs from pilot planning
Workflow mapping asks where repeat work occurs and which steps are good candidates for change. A pilot takes one chosen step and tests an agreed implementation on representative examples. Customers who already know the task, have approved input data and need acceptance tests should move to the pilot offer. Customers who cannot yet explain what staff actually do need mapping first. These are different decisions, and separating them prevents duplicated directory pages with the same advice. A next-step recommendation should be grounded in process observations, not an assertion that automation will necessarily reduce work. Human review itself can create work and must be considered when evaluating a proposal.
