Someone copies an enquiry from an email into a spreadsheet. They create a customer record, notify a colleague and send a standard reply.
It happens several times a day. It is repetitive. Everyone agrees it is annoying.
That does not automatically mean it is worth automating.
The process might take less time than people think. It might contain decisions nobody has documented. The information arriving might be inconsistent. Or the process itself might be unnecessary.
A process is worth automating when the problem is valuable enough, the work is predictable enough and the likely benefit clearly outweighs the cost and risk of changing it.
That requires more than asking whether automation is possible.
Manual does not always mean broken
Growing businesses often assume that repeated manual work should be removed.
Sometimes that is correct. Repeated copying, checking, chasing and updating can consume time and create opportunities for mistakes.
But a manual process can also be:
- Cheap to run
- Rarely used
- Easy to understand
- Difficult to automate reliably
- Dependent on human judgement
- Likely to change soon
Automating work introduces its own costs. Someone has to design the new process, connect the systems, test it, monitor it and fix it when something changes.
This is one reason technology decisions can feel difficult for smaller businesses. OECD research into UK SMEs found that cost, uncertain returns, unclear relevance and distrust of suppliers remain important barriers to technology adoption.
The answer is not to avoid automation. It is to become more selective about where it is used.
Improve the process before automating it
Before looking at software, write down what currently happens.
For one process, record:
- What starts it?
- What information is needed?
- What steps are completed?
- Where does the work wait?
- Which decisions are made?
- What can go wrong?
- What marks the process as finished?
This often reveals that the visible manual work is not the real problem.
A report may take hours to prepare because information is stored inconsistently. Customer updates may require repeated chasing because nobody owns the handover. An invoice may need checking because the original order details were incomplete.
Automation added on top of these problems can make them happen faster without fixing them.
Look for steps that can be removed, combined or clarified first. A shorter form, shared template, written rule or feature inside existing software may solve enough of the problem without a custom build.
The process can still be worth fixing even when it is not worth automating.
The Pain and Predictability Test
A useful first test is to judge the process on two factors.
How painful is the process?
Pain is not limited to the number of hours it takes.
A process may be valuable to improve because it:
- Delays customers
- Restricts how much work the business can accept
- Creates frequent mistakes
- Causes missed revenue
- Requires expensive staff to perform basic administration
- Depends on one person being available
- Creates a compliance or operational risk
The pain should be observable. “It is inefficient” is too vague.
A better description would be:
Preparing the weekly report takes the operations manager four hours and delays Monday’s planning meeting.
How predictable is the process?
Predictability measures how consistently the work follows known rules.
A predictable process has:
- A clear starting point
- Defined inputs
- Repeatable steps
- Few variations
- Rules that can be explained
- A consistent output
- A clear way to identify exceptions
Research into process selection commonly identifies rule-based work, stable processes, structured digital information, low complexity, high frequency and longer execution times as characteristics that make automation more suitable.
Using the two factors together gives four possible decisions.
High pain and high predictability: A strong automation candidate.
High pain and low predictability: Improve or support the process, but keep important decisions human.
Low pain and high predictability: Automate only when an existing tool can do it cheaply.
Low pain and low predictability: Usually leave it alone.
Six questions to ask before automating
1. Does it happen often enough?
Frequency creates cumulative value.
Saving five minutes from something completed twice a year will rarely justify a custom system. Saving five minutes from something completed 100 times each week might.
Measure the number of times the process runs during a normal week or month. Do not rely on guesses.
2. Is the process stable?
Automation works best when the underlying process is unlikely to change immediately.
A process that is still being designed should normally be tested manually first. Otherwise, every operational change may require the automation to be rebuilt.
Stability does not mean the process must be perfect. It means the business understands what should happen in most situations.
3. Can the rules be explained?
Ask the person doing the work to explain how each decision is made.
Statements such as “I can normally tell” or “it depends on the customer” indicate that part of the process still relies on experience or context.
That does not prevent all automation. Routine preparation can be automated while a person handles the decision.
For example, a system might collect customer information, check that required fields are complete and prepare a quote. A person can still review the scope and approve the price.
4. Is the information consistent?
Automation needs dependable inputs.
The process becomes harder when information arrives through phone calls, handwritten notes, free-text emails and differently formatted spreadsheets.
Before automating, check:
- Whether the required information is normally available
- Whether the same fields are used each time
- Whether records contain duplicates
- Whether different systems disagree
- How missing information is handled
Improving the information collected at the beginning of a process may produce more value than automating the later steps.
5. What happens when it fails?
Every automation will eventually encounter something unexpected.
The important question is whether the failure is visible and recoverable.
Sending an internal notification twice may be inconvenient. Paying the wrong supplier, rejecting a job applicant or changing an employee’s pay could have much more serious consequences.
Processes involving employment, credit, legal rights, safety or other significant decisions need additional safeguards and meaningful human oversight. The Information Commissioner’s Office also advises organisations using relevant automated decision-making to provide routes for human intervention and conduct regular checks that systems are working as intended.
The cost of failure may make a process unsuitable for full automation, even when its rules appear clear.
6. Can the return be measured?
The business should know what improvement it expects before building anything.
Possible measures include:
- Staff hours required each week
- Time from enquiry to response
- Number of orders processed
- Percentage of records containing errors
- Number of overdue customer updates
- Cost of correcting mistakes
- Amount of work dependent on one employee
Record a baseline before making the change. Without one, it will be difficult to tell whether the automation helped.
The Maytime Automation Score
Score the process from zero to two against each area:
- Business pain: Is the current problem costly or restrictive?
- Frequency: Does the process happen regularly?
- Predictability: Does it follow clear rules?
- Information quality: Are the required inputs digital and consistent?
- Exception rate: Can most cases be handled without judgement?
- Measurability: Can the result be compared with a baseline?
Use the following scale:
- 0: Weak
- 1: Mixed or uncertain
- 2: Strong
A score of 10 to 12 suggests a strong candidate for investigation.
A score of 7 to 9 suggests the process should be simplified or tested before automating.
A score below 7 usually means the process is not ready, the problem is too small or important details are still unknown.
The score is a starting point, not a business case. A high-risk process should not be automated simply because it scores well elsewhere.
A worked example
Consider a small service business receiving 40 enquiries each week.
An administrator spends around 15 minutes on each one:
- Copying the details into the customer system
- Creating an internal task
- Sending an acknowledgement
- Asking for missing information
That adds up to ten hours each week.
At an assumed employment cost of £25 per hour, the process represents around £13,000 of staff time each year.
Suppose automation could remove 75 per cent of that work while leaving unusual enquiries for a person to handle. The estimated annual time value would be £9,750.
If the automation cost £4,000 to implement and £100 each month to maintain, the first-year cost would be £5,200. Under those assumptions, the setup cost would be recovered in roughly six months.
This does not automatically mean the business would save £9,750 in cash.
The saved time only creates value if it can be used to reduce overtime, respond to customers faster, process more work or move staff towards something more useful.
That is why the measure matters as much as the calculation.
Start with one controlled process
Do not begin by trying to automate an entire department.
Choose one process with:
- A clear boundary
- A known owner
- Enough volume to matter
- Rules that can be explained
- A manageable failure risk
- A measure of success
Test it with a limited group. Record the exceptions. Compare the result with the original baseline. Then decide whether to improve, expand or stop.
The UK Government’s SME Digital Adoption Taskforce recommends a similar test-and-learn approach: pilot changes, measure the outcomes and adjust them using evidence and feedback.
A small automation that produces a measurable result is more useful than a large system built around assumptions.
Automation should earn its place
The best automation candidate is not necessarily the process people complain about most.
It is the process where a repeated operational problem meets clear rules, dependable information, manageable risk and a measurable return.
Sometimes the right answer will be automation.
Sometimes it will be a form, a checklist, a change of responsibility or better use of software the business already owns.
At Maytime, we start with the operational bottleneck, not the technology. We find where work slows, waits or breaks, then use the simplest suitable solution to improve one process at a time.
Send us one process that is causing problems. We will tell you whether it is worth fixing and what the safest first step would be.