Choose a task with a clear beginning and end.
“Let us automate the office” is too broad an objective. “After receiving suppliers’ reports, prepare a list of missing entries” already describes a trigger, an input and a result. A narrow scope makes it easier to name an owner and compare work before and after the change.
Do not simply select the easiest task. Check whether it recurs often enough and whether anyone needs its result. Automatically producing a report nobody uses merely makes an unnecessary activity faster. A good candidate has a recipient, repeatable data and rules that can be explained.
- What triggers the task?
- What does the person or system receive at the end?
- When do we consider the task correctly completed?
Walk through the process with the person who does it every day.
Ask them to show a normal case on screen, step by step. Note the moments of copying data, extra checking and waiting. Pay attention to informal rules: “we check that supplier separately”, “I always correct that file” or “I have to call someone here”.
These remarks often determine whether automation succeeds. The procedure may describe combining files, while the employee first identifies incorrect units and skips an outdated version. If we overlook that knowledge, the automation reproduces only the visible part of the work and starts producing unreliable results.
The essentials to start with
Describe one task through its input, rules and expected result.
Collect correct, unusual and invalid samples with their expected outputs.
Define the boundary between automatic execution and human decisions.
Collect samples that show the variety of your data.
One correct document is not enough to understand a process. Prepare examples from different sources, periods and variants. Add a file with gaps, a duplicate and a case that recently needed manual correction. Data for initial analysis should have unnecessary confidential information removed.
Attach the expected result and a brief explanation to each sample. If two people produce different answers that they both consider correct, the rule needs to be agreed first. For documents, format, scan quality, table layout and version labelling also matter.
- An ordinary case that presents no difficulty.
- An unusual but permitted variation.
- Incorrect or incomplete input.
- The same document submitted again.
Separate rules from judgement and approval.
Comparing a total, checking an order number and calculating a date under an agreed rule have unambiguous results. Assessing the tone of a message, reading an inconsistent document or interpreting a description may need a different approach. AI can help, but the result still needs suitable verification.
Mark the actions that must remain under human control: sending a quote, approving a change or publishing information. Automation can prepare the full set of materials and highlight differences. It does not have to make every decision itself to make the process noticeably simpler.
- What can be checked against an unambiguous rule?
- What needs interpretation?
- Which step must be approved by a specific person?
Describe exceptions as carefully as the normal path.
What should happen if an attachment is missing? What if the source system does not respond? Who decides whether two similar entries are duplicates? Each situation needs an outcome: retry, hold, notification or referral for manual handling.
Agree whether part of a task may finish successfully despite an error elsewhere. A report based on incomplete data should clearly show its status. In some processes, it is better to hold publication than distribute a result that looks complete. The person handling exceptions must understand the message and know what to do next.
Check the result before letting it trigger further actions.
An initial trial can run alongside the manual process. Compare results using agreed examples and describe differences precisely: an omitted entry, incorrect unit or wrong document version. Saying that “almost everything matches” is not enough to assess the risk.
Also plan to run the same task again. The process should not accidentally send two messages or create two records. Test a loss of access and the return to normal work. Agree acceptance criteria before launch rather than adjusting them later to fit the result produced.
- The result matches the agreed sample.
- Missing information is visible rather than silently omitted.
- Retrying has a predictable outcome.
- Users can check where the data came from.
After launch, observe the whole process, not just the automation’s running time.
Completing one step faster can create a queue at the next. If a report is produced immediately but approval still waits several days, examine the subsequent workflow. Gather information about exceptions, manual corrections and questions from recipients.
Prepare simple instructions: where to check execution, who responds to an error, how to pause processing and when to return to manual work. Source files and tools will change. Whoever owns the automation should hear about those changes before they affect subsequent results.
Bring this to your business
- Test errors, repeated runs and the option to return to manual work.
- After launch, observe waiting time and exception handling as well.
