Does your process need AI or automation?
Describe one recurring task and separate stable rules from interpretation of free text. Then choose the smallest process that produces a verifiable result.
You will have a decision record showing what stays manual, what rules can handle and whether AI is needed at all. It includes exceptions and checks before use.
Free, with no sign-up. This example uses fictional data.
Prepare examples from the work
Choose a process with a clear start and finish, such as routing equipment requests. Prepare fictional or approved anonymised examples of typical requests, an incomplete request and an exception. Record who makes the decision today and what they base it on. If employees interpret the same rule differently, clarify the rule first. Do not choose a tool until you know whether the task needs to transfer data, apply a rule or interpret meaning.
A decision template to copy
Copy the template and complete it for one bounded task. A complete fictional example follows for comparison.
TASK What starts the process: [event] Input and source: [fields, document or text] Expected output: [specific result] Responsible person: [role] RULES If [verifiable condition], then [action]. If [required information] is missing, then [stop or request more information]. Exceptions handled by a person: [cases] DECISION Chosen process: [manual work, rules-based automation or a bounded AI step] Reason based on the examples: [what rules can and cannot handle] AI may suggest: [result or "AI is not needed"] Human review: [who confirms which decision and before which action] On error or uncertainty: [safe next step] CHECK Examples and expected results: [typical case, incomplete input, exception] What we measure: [correctness, corrections, total time, cases handled by a person] Unknown before use: [information and the person who confirms it] Decision approved by: [responsible person]
How the workflow works in practice
Illustrative examples with fictional data. They show the process and human review, not the results of a client project.
Route requests using clear rules
- Input
A fictional internal equipment request process. The form requires a request number, department and equipment type. Approved rule: IT handles laptops, and office support handles chairs. An unknown equipment type or an empty required field needs human review. Routing a request does not approve a purchase. The support manager approves the rules before the process is enabled. Examples: Z-101, sales, laptop. Z-102, finance, chair. Z-103, department missing, chair. Z-104, sales, "I need something for fieldwork". Unknown: request volume, exception frequency and whether the process can connect to the existing tool.
- Output
DECISION FOR REVIEW Choose rules-based automation to route complete requests. AI is not needed for the existing categories because the equipment type field determines the recipient. Expected results: Z-101: assign to IT. Z-102: assign to office support. Z-103: keep under review and request the department. Do not assign. Z-104: keep under review and clarify the equipment type. Do not guess a category. Routing does not approve a purchase or change stock. If the tool connection fails, the request stays unresolved and the responsible person receives a notification to review it. To confirm: request volume, exception frequency and technical access to the tool. If free text becomes common, first check whether the form can be improved. Consider AI only to suggest a category that a person confirms before assignment. Status: proposal for the support manager. No record has been changed.
- Process
- Record the input, expected output and person responsible for the result. Limit the decision to one task.
- Check whether clear fields and stable rules can handle typical cases. If they can, prefer rules-based automation.
- Identify exceptions and unknown information. Define when the process stops and hands the case to a person.
- If free text needs interpretation, consider AI only to suggest extracted information or a category. Require review before applying that suggestion.
- Compare the proposed process with manual work on the same examples. Confirm rules and permissions before using real records.
- Human review
- The process owner confirms the rules and the distinction between routing a request and approving a purchase.
- Every example has an expected result, including incomplete input and an exception.
- A connection failure leaves a visible unresolved request.
- Write permissions and the handling of repeated requests are confirmed before use.
- What we measure
- Number of correctly routed requests and incorrect assignments.
- Number of exceptions a person must handle and the reason for each handoff.
- Total processing time, including checks and corrections.
- Number of lost or duplicate requests. Both counts must be zero before accepting the process.
Check before using
- The process owner confirms the rules and the distinction between routing a request and approving a purchase.
- Every example has an expected result, including incomplete input and an exception.
- A connection failure leaves a visible unresolved request.
- Write permissions and the handling of repeated requests are confirmed before use.
- The example is a proposal, not an implemented system. Confirm decisions and permissions before applying it to real records.
Apply it to your process.
Have a process with recurring rules and exceptions? Explore our Automation service and prepare a few examples for a scope discussion.