Start with a recurring task that has clear rules, a known problem and an owner. It might involve assigning enquiries, transferring approved information or flagging something missing. The best first automation is often one you can understand, check and repair when something goes wrong.
The aim does not have to be saving the largest number of keystrokes. Better visibility, fewer forgotten tasks and clearer responsibility may matter just as much. Before choosing tools, decide which part of the working day you want to improve and how you will recognise the difference.
Find the work repeated between systems
Ask the people doing the task to show it from beginning to end. Follow a normal case: where does the information come from? What gets copied? Where does someone have to search or ask? Where does the case wait? Use the actual steps, not just the procedure describing how things were meant to work.
Record the exceptions too. An order may change, the same customer may send two enquiries, or a department may lack capacity. These situations are part of the process. If automation only handles the perfect case, it may shift work into troubleshooting rather than reduce it.
Assess value and risk before setting priorities
Compare a few candidates. For each task, consider its frequency, effort, error rate and the consequences of an error. Include time for checking, training and maintenance. A frequent task is not automatically a good choice if its rules keep changing.
- Understand the task. Describe what starts the work, what information it needs and when it is complete.
- Limit the trial. Choose one handover, an owner and a way to handle exceptions.
- Check the value. Review time spent, errors and follow-up before expanding to more tasks.
A useful first trial is often easy to reverse and produces a visible result. An internal reminder may be easier to check than a system sending binding proposals to customers. Tasks requiring judgement can still receive support: the system can gather the information while a colleague makes the decision.
Example: from a form to an accountable colleague
Imagine a fictional service business where all enquiries arrive in a shared inbox. Some get forwarded, others receive a direct reply, and absences make responsibility unclear. The first improvement could be giving each enquiry a case record, an owner and a visible status.
The rule could assign enquiries by service and location. If information is missing or no rule fits, a named person receives the case for clarification. An internal check highlights cases without a next step. The customer receives an accurate acknowledgement, while a person still assesses the need and prepares any proposal.
This is a limited workflow you can test without rebuilding the whole business. You still need to decide where contact details belong, how an existing customer is recognised and what happens after a duplicate submission. The same enquiry should not become two active tasks simply because a transfer is retried.
Start with the tools you already have
Check whether your existing CRM, form or workplace tools can handle the task. A clearer routine and better settings may be enough. An integration becomes relevant when systems need to exchange information. A custom system may make sense when standard tools do not adequately support the process.
Distinguish between information that should be shared and the system that defines its correct value. If both the customer record and order system can change the same address, you need a rule for which value takes precedence. Otherwise, an automatic transfer may simply spread outdated information faster.
PEC Platform brings together several aspects of customer and project work. The project shows why responsibility and information need to be considered across functions. It does not mean a smaller business needs the same scope.
For Boxx, we have worked on digital product choices and the follow-up around orders. Kjetil also has a business development role through K28. The relevant lesson here is to consider what must carry through from a customer’s choice to the work behind it: product, need and next action.
Agree what happens when something stops
An automation needs an owner after launch too. Agree who receives error alerts, who can fix problems and how the work will be handled manually during an investigation. It should be possible to see whether a task is complete, waiting or failed. “Nobody has complained” is not a checking method.
Test normal cases, missing information, duplicates and interruptions before starting. Check permissions and use test data. When a system or field changes later, assess whether the connection still works. Include operation and changes in the costs, not just the initial setup.
Measure the whole task before expanding
Compare the time from start to completion before and after the trial, using comparable cases. Include checking and corrections. Also note whether fewer cases are forgotten or a colleague can take over more easily. Some improvements concern reliability even when the time saving is small.
If the work involves interpreting free text, AI could be part of a later trial. It still needs clear boundaries and checking. Read how to choose a useful first AI task.
Start by writing down one task you currently perform manually: what starts it, who does it and where it gets held up. This gives you a practical basis for assessing integrations and automation.
