How to choose your first business automation

Choose a first automation by looking for a task that happens often, follows a recognisable pattern and has a clear owner. Start small enough that you can compare the new process with the old one. A dramatic-sounding idea is less useful if nobody can describe the inputs, exceptions or the correct result.

This worksheet helps you shortlist tasks. The scores are a discussion aid, not a measured business case.

List the work as it happens today

Write down three recurring tasks in ordinary language, such as copy form enquiries into a tracker, prepare a weekly status email or turn meeting notes into action items. For each, note who does it, how often, where the source information lives and what a finished result looks like.

Do not start with a product name. A request for “an AI agent” does not tell you which work should change or how anyone will know it helped.

Score the candidates

Give each item a score from 1 to 3. A higher number means it looks more promising for an early, contained automation. These example scores are illustrative.

Add the scores, but do not treat the total as a command. A task involving personal data, payments or customer promises may need stronger controls even if it scores highly. A task with no clear owner is not ready. If the source data is unreliable, improve the collection step first.

For instance, an illustrative form-to-tracker task might score 3 for frequency, 3 for process clarity, 2 for exceptions, 2 for access and 3 for review: 13 out of 15. A proposed AI-written customer reply might also happen daily, but if unusual requests are common and no one can check the draft promptly, its exception and review scores should be lower. The point is to expose those differences before choosing a project, not to crown the largest number.

Walk through one candidate

Suppose a team copies website enquiries into a shared tracker each morning. This is a hypothetical example. The action is frequent, the input is a form submission, and the output is a new row assigned to the right person. A simple rule could copy the fields and route by service type. A person could review unusual messages before responding.

The first version does not need to answer customers automatically. Define success as every test enquiry appears once, with the right details, and failures are visible to the owner. Include duplicate handling and a manual route when the integration is unavailable. Then measure actual time and errors before claiming a saving.

Write the boundary before the build

A one-page brief is enough for a first conversation:

• Trigger: what event starts the work?
• Sources: which approved systems and fields may be used?
• Output: what should be created or changed?
• Review: who checks exceptions or approves external actions?
• Failure: who is told, and what is the manual fallback?
• Measure: what baseline and later result will you compare?

If you cannot fill in those lines, observe a few real runs of the current process. A useful first automation is one you can explain, test and recover when it fails. See the automation service or describe a workflow when you have a candidate.