Ways of working

What to automate first in a small service business

A good first automation does not need to be the most impressive demo. A strong candidate is a small, repeated task that your team already understands, where you can easily check the result and put things right if it goes wrong.

There is no single task every business should automate first. This guide helps you choose your own candidate, or decide that a task needs simplifying before anyone automates it. It includes readiness checks, a decision table, a pilot card you can copy and a simple way to tell whether the pilot actually helped.

A note on terms: business process automation here means software carrying out a defined step for you, such as creating a task, sending an internal reminder or copying details from one system to another. Steps like these follow fixed rules and do not need artificial intelligence (AI).

1. Start with three recurring irritations

List three things that come up again and again in real work and cost time or cause mistakes. For example:

  • copying enquiry details from email into a job list by hand
  • chasing colleagues for the next action on accepted jobs
  • rewriting the same quote introduction each time

For each one, narrow it down to a single step. "Admin" is too broad to automate. "When a quote is accepted, create a delivery task with the job reference and scope" is specific enough to test.

If you cannot describe the step clearly, the work may need mapping first. Write down what happens now, who does it and how they know it is done.

2. Check whether each task is ready

Before you compare savings, check each candidate against these six questions. If the answer to any of them is no, simplify or document the task first.

Readiness check Ready if…
Stable rule You can write the rule down, and people follow it the same way each time
Adequate input The information the step needs is reliably present and in a consistent place
Named owner One role is responsible for the step and for noticing when it fails
Permission to use the data You are allowed to use the data this way, and the automation only touches what it needs
Observable completion You can see whether the step happened, and happened correctly
Fallback route If it goes wrong, the action can be reversed, or there is a clear manual way to finish the job

On data, use only the information the step genuinely needs. The UK regulator's guidance on data minimisation says personal data should be adequate, relevant and limited to what is necessary for your purpose. An internal reminder, for example, may only need a job reference and an owner, not the customer's full contact details. This table is not a data protection review; if you are unsure whether a use is allowed, check before you build anything.

3. Compare the tasks that pass

Copy this table and fill in a row for each task that passed the readiness checks. Use what you observed in recent weeks, not estimates of what might happen.

Candidate table

Task Repeats per week Observed minutes per repeat Stable rule? (yes/no) Consequence if wrong Owner Decision: pilot / clarify first / keep human

Use these rules to reach a decision:

  • Frequency and time show the opportunity. A task that repeats often and takes real time is worth looking at.
  • Risk can overrule the opportunity. If a mistake would reach a customer, move money or affect someone's personal circumstances, a large apparent saving does not make the task a good first pilot.
  • No permission, no pilot. High frequency never outweighs missing permission to use the data, or a consequence you could not accept.
  • "Clarify first" is a good result. It means you found a task to simplify, which can help more than automating a muddled step.

These are prompts for your own judgement, not a scoring model. Do not add up weighted scores and treat the total as a return on investment.

4. Match the level of control to the consequence

Different tasks need different levels of human control. These illustrative examples show the difference:

  • An internal reminder about an overdue task stays inside your team and is easy to check and ignore if wrong. This can be a sensible first pilot.
  • Creating a draft quote can save typing, but a person should review and approve it before it goes to the customer.
  • Sending invoices, taking payments, making decisions about people, or giving customers advice in unclear situations need much stronger controls. One option is to keep these human-led, or to automate only a preparation step.

This is not a suggestion to automate every finance or staff process. It is a reminder that the first pilot should be one where a mistake is cheap and visible.

5. Check the tools you already have

Before buying anything new, look at what your current tools already do. Job management, email, calendar and accounting tools may include rules, reminders or integrations that cover a simple step.

If you do need to connect two tools, check:

  • Compatibility: can they exchange the fields you need?
  • Access: who sets it up, and does it need an administrator account?
  • Limits: are there caps on runs, records or connected users?
  • Cost: what is the recurring cost, and who pays it?
  • Failure visibility: if the connection stops working, who finds out, and how?

Features and prices change, so check them with the supplier at the time. Do not rely on a comparison article.

6. Write a pilot card

Copy this card and fill it in for your chosen task. If you cannot complete a field, the task is not ready yet.

Pilot card

Field Your pilot
The one task
Trigger
Source and required fields
Allowed action (what it may do, and nothing else)
Human approval point
Unique item or reference check (to prevent duplicates)
Where exceptions go
Monitoring owner and backup
How to pause it
Manual fallback
Trial boundary (which jobs, team or period)
Baseline observation window
Success and stop criteria
Review date

Worked example (hypothetical)

This example is an illustration, not a ScalePass client or a measured result.

Field Example
The one task Remind the accountable team member when an accepted delivery handoff has no agreed next action recorded
Trigger A job is marked "handoff accepted" and, by the agreed check time, no next action is recorded
Source and required fields Job reference, accountable team member, handoff status, next-action field
Allowed action Send one internal reminder to the accountable team member. It does not contact the customer, send a quote or change the job
Human approval point None for the reminder itself; the team member decides the next action
Unique item or reference check One reminder per job reference per check; if a reminder for that job is already open, do not send another
Where exceptions go If the job has no accountable team member, or the trigger data is incomplete, add it to a manual review list
Monitoring owner and backup Operations lead; backup is the delivery lead
How to pause it Switch off the rule in the job tool; the operations lead and backup both know where
Manual fallback Operations lead checks accepted handoffs at the agreed time each day, as before
Trial boundary One service line, for an agreed number of weeks
Baseline observation window The same number of weeks before the pilot, using the same manual check
Success and stop criteria Keep if fewer accepted handoffs are found without a next action and the reminders need little correction. Stop if duplicates or wrong reminders keep appearing, or if the review work outweighs the manual check
Review date End of the trial period

If the accountable person is away, the reminder still goes to them, so the manual review list must include absent owners. The backup checks that list, or reassigns the job.

A reminder only works if the team has already agreed who owns each job and what the next action should be. For new enquiries, our guide to managing customer enquiries covers setting an owner and next action. Agree those before you automate anything around them.

7. Test it with invented cases first

Before the pilot touches real work, run it with clearly invented test jobs. Check each of these:

  1. Normal case: the action happens once, correctly, for the right job.
  2. Missing input: a required field is empty. The item goes to the exception list instead of causing a wrong action.
  3. Duplicate trigger: the same event fires twice. Only one action results.
  4. Changed or cancelled job: the job changes or is cancelled before the action runs. Nothing inappropriate happens.
  5. Destination unavailable: the receiving tool is down or rejects the item. Someone finds out, and the work is not lost.
  6. Owner absent: the responsible person is away. The backup can see and handle the item.

For each test, check two things: the intended action happened exactly as intended, and nothing else happened that should not have. If a step fails, do not let it simply retry an action that reaches a customer or moves money. Check what actually happened before repeating it.

8. Run a limited pilot and measure honestly

Start small, inside the trial boundary, with someone reviewing the results. Then compare against your baseline.

Use this calculation to keep the numbers honest:

  • Gross repetitive minutes = observed repeats × observed minutes per repeat.
  • Net observed time change = baseline manual minutes − (remaining human review + exception handling + maintenance minutes), measured over a comparable period.
  • Record setup time and recurring tool costs separately. Do not net them into a single figure.

Count staff time, not how quickly the job reaches the customer; the two are different. Do not multiply a few weeks of results into a yearly saving. Decide to keep, adjust or stop based on what you observed, including errors and exception work. How many times the automation ran is not evidence that it helped.

9. Write down who looks after it

If you keep the automation, record:

  • the owner and backup
  • how to pause it
  • where exceptions and failures go, and who checks them
  • the manual process to use if it stops
  • when it will next be reviewed, and what changes would trigger an earlier review

Keep this with your other operating instructions, so it is not lost when the person who set it up moves on.

Common questions

What should stay human?

Anything where a mistake would be costly, hard to reverse or hard to spot. That includes customer advice in unclear cases, money movements and decisions about people. Automation can still prepare information for the person who decides.

Should I buy a new tool?

Not first. Check what your existing tools already do. Buy something new only when the step, owner and fallback are clear, and the current tools cannot support it.

Is automation the same as AI?

No. Fixed-rule automation (when this happens, do that) does not require AI. AI may help with some tasks, but it is not needed for a reminder or a copied field, and it can make results harder to check.

How do I handle failures?

Decide in advance where failures go, who checks them and how to pause the automation. Test failures before going live, and make sure a failed step never blindly repeats an action that reaches a customer.

What counts as an improvement?

Less human time on the task, including review and exception work, with no rise in errors. Compare against a baseline from the same type of work.

ScalePass helps service businesses connect the tools they already use, one agreed and scoped improvement at a time. If you have a step that is ready and want help connecting it safely, Explore connected systems.

Back to the blog