Automation often begins with a familiar complaint: somebody is copying the same details between a form, an inbox and a spreadsheet every day. The temptation is to start buying software or sketching a custom tool. That can be premature. If the underlying process is unclear, automation simply makes the confusion travel faster.
The better starting point is to choose one piece of work that is repetitive, understood and worth improving. You can then decide whether the answer is a small change, an established product or purpose-built software.
Look for friction, not novelty
Start with the jobs people grumble about because they interrupt useful work. Repeated typing is an obvious clue, but it is not the only one. Watch for information copied into several places, requests that disappear in shared inboxes, status questions that keep coming back and routine decisions that depend on one person remembering the next step.
Ask the people doing the work to keep a short record as the task happens. For each instance, note:
- what started the task;
- who had to take part;
- where the information came from;
- which decisions were made;
- what caused delay or rework;
- how everyone knew the task was finished.
This is more useful than asking for a list of desired features. It shows how the process behaves on an ordinary day, including the awkward cases that a neat diagram tends to miss.
Make sure the process can be explained
A good candidate has a recognisable beginning and end. People may handle some steps differently, but they can explain why those differences exist. The information used in each decision is known, and somebody owns the outcome.
Be cautious if the rules change every week, nobody agrees who approves the work, or important decisions happen in private messages that are never recorded. Software cannot settle a disagreement about how the business should operate. Resolve that first, then describe the process again.
Try the smaller fix before building
Some tasks feel like automation problems because the current process has collected unnecessary steps. Remove those before adding technology. One approval may be enough where two people currently sign off the same decision. A form could collect a reference number once rather than asking staff to retype it later. A better folder structure might solve a retrieval problem without introducing another system.
An established product may already handle the work well. The cost of custom software should be justified by a genuine mismatch, such as a process that matters to the business but cannot be supported sensibly by the tools available. Mighty Digital Studio makes the same point in its guidance on SaaS tools and automation: discovery should be able to recommend a simpler process or a suitable existing tool rather than force every problem into a larger build.
Choose a bounded first candidate
Your first automation project should be small enough to understand without being so trivial that nobody cares whether it works. A useful candidate usually has:
- a clear event that starts the work;
- inputs that can be collected consistently;
- rules that staff can write down;
- an outcome that can be checked;
- a practical fallback when something fails.
Do not begin with the most tangled process simply because it causes the loudest complaints. A smaller route, such as receiving a request and assigning it to the right person, can reveal how the business needs to handle accounts, permissions, notifications and exceptions. Those lessons make the next piece of work easier to plan.
Keep human judgement where it belongs
Automation is useful for moving information, applying agreed rules and prompting the next action. It becomes risky when a system quietly replaces judgement that the business still expects a person to exercise.
Mark each decision as automatic, assisted or human. An automatic step can follow a reliable rule. An assisted step can prepare information or suggest a route, while a person confirms the decision. A human step stays with the named role. Also record who can correct a mistake and what happens when the information is incomplete.
Count the work around the software
The screen people use is only part of the project. Data may need cleaning before it moves. Staff need suitable access. Somebody must answer questions, investigate failures and decide which later changes are worth making. Hosting, maintenance and support continue after launch.
Put those responsibilities into the plan before comparing options. A cheap tool that needs constant manual repair may not be cheap in practice. A custom build also needs an owner inside the business, even when technical support sits elsewhere.
Write a one-page first-version brief
Finish the selection work with a short brief. It should name the users, the event that starts the process, the information required, the rules that can be automated and the result the first version must produce. Add the known exceptions, the fallback route and the person responsible for the process.
Keep later ideas in a separate list. Reporting, customer accounts and extra integrations may be useful, but they should not blur the job of the first version. The custom apps service is built around this sort of early requirement shaping, with the first release defined before development grows around assumptions.
Agree how you will judge the result
Choose evidence that relates to the original problem. You might check whether staff have stopped copying the same data, whether handovers are easier to follow, whether fewer requests go missing or whether corrections take less effort. Record the current position before the change so the comparison has a baseline.
A sensible first automation project leaves the business with a clearer process as well as a useful tool. If you cannot explain the job, the exceptions and the owner on one page, keep working on the process before you build.