A task is ready to automate when it has a predictable trigger, consistent information at the start, a clear outcome and a defined response for when something goes wrong. If you cannot describe those four things in a few sentences, you need to map the workflow before building an automation, not after.
What a good automation candidate looks like
Four conditions are worth checking before you commit to building anything.
A consistent trigger. Something reliable starts the task: a form submission, an invoice arriving, an order confirmed, a booking made. The trigger should happen the same way each time, not when someone decides to act.
Predictable inputs. The information the task needs is usually available at the start and in a format the automation can use. Chasing a missing field, or choosing between two plausible values for the same record, is a job for a person, not a rule.
A verifiable outcome. You can tell whether the automation did its job without investigating. A customer record was created; an email was sent; a task appeared on the right person’s list. If the only way to check is to ask the customer, the feedback loop is too long.
Rules you can write down. The decisions involved can be expressed as if/then conditions. A discount applies when an order exceeds a certain value. A booking is confirmed when the deposit clears. A request is escalated when it mentions a specific word. If the right decision depends on context the system does not have, a person should still make it.
When all four conditions apply, automation is likely to work well and be straightforward to maintain. When one or more are absent, it is worth resolving them first.
What a poor automation candidate looks like
Not all repetitive work benefits from automation.
Work where each case is meaningfully different, where the right response depends on background the system does not have, or where the cost of getting it wrong outweighs the time saved is usually not ready. A routine request with a single path from start to finish is a different matter from a complaint where the history matters, the customer’s expectations vary and the right response requires a conversation.
Low-frequency tasks are also worth questioning. If something happens four times a year and takes ten minutes each time, the effort of building, testing and maintaining the automation may exceed what it saves. The automation may also need updating when a connected tool changes its format or API, so ongoing maintenance is part of the cost.
Even so, low-frequency and high-judgement work can sit next to an automation. A regular part of the process can be automated while a person handles the exception. That is often the better first step than trying to automate an entire workflow end to end.
A decision checklist
Before starting any automation project, work through these questions for the specific workflow:
- Can you describe the trigger in one sentence?
- Is the information you need usually available at the start of the task?
- Can you define what a successful outcome looks like?
- Can the decisions involved be written as explicit rules?
- Is the task frequent enough that saving the time is worth the build and maintenance cost?
- If the automation fails or produces a wrong result, who will notice and how quickly?
- When inputs are incomplete or unusual, what should happen?
The last two questions matter most in practice. An automation that works in a demonstration can go wrong when a field is missing, a request arrives twice or a downstream service is unavailable. Handling those cases is part of the design, not a detail for later.
Where UK financial record-keeping fits
If your business still keeps manual or spreadsheet-based records for invoicing, expenses or VAT, the point at which you move to a connected system is worth planning.
VAT-registered businesses in the UK must keep and submit their VAT records using software compatible with Making Tax Digital for VAT, unless HMRC has exempted them. From 6 April 2026, Making Tax Digital for Income Tax also applies to self-employed people and landlords with qualifying income over £50,000, who must use compatible software to keep digital records and send quarterly updates to HMRC. From September 2026, HMRC starts signing up people whose records show qualifying income over £50,000 in the 2024 to 2025 tax year.
If your financial record-keeping is not yet in compatible software, the move to a proper system is a useful moment to review which surrounding tasks (invoice generation, payment chasing, bank reconciliation) could be handled more efficiently at the same time, rather than replicating an old manual process in new software.
Map the workflow before you build
The most useful step before building anything is to write down one workflow from trigger to outcome.
Start with the normal route: what starts the task, what information is available at that point, which steps follow in order, and what the finished result looks like. Then write down the common exceptions: the missing field, the duplicate request, the case that needs a decision.
For example: an enquiry arrives by email → the contact does not yet exist in the customer record system → a record is created → a task is assigned to the right person → the enquiry is filed against the new record. Then: what happens when a record already exists? What if the email does not include a name? What if the system that holds the customer records is unavailable?
That map tells you whether the task is genuinely ready. It also tells you what the automation needs to handle and what it should leave to a person.
Some businesses find that the underlying difficulty is not a task to automate but a connection between tools they already use. Information that has to be copied from a booking system to a customer record is often a simple integration rather than a multi-step automation. It is worth understanding that distinction early. The choosing custom software or off-the-shelf tools article covers when an integration fits better than rebuilding.
Starting with one workflow
It is tempting to approach automation as a broader programme, connecting everything at once. In practice, starting with one workflow makes it easier to test whether the outcome is correct before building further.
One workflow, fully working, with proper handling for the normal route and the common exceptions, is a more useful foundation than several half-built connections running in parallel. It also gives you a real example to judge whether the approach is worth extending.
FleetPad is an example of a platform built around connected operational records spanning a driver companion app and a management view. Hand Painted Backdrops combined a storefront with order management, customer records and internal tools. Both are cases where the connections were shaped around how the business actually worked, rather than what an off-the-shelf integration provided.
For businesses with repeated handovers across several tools, integrations and automation can cover both direct connections and structured multi-step workflows.
Where AI fits into this
If the workflow involves reading, summarising or composing drafts based on content that varies each time, such as an enquiry, a support request or a set of notes, it may overlap with an AI integration rather than a rule-based automation. The two approaches can work together. A rule can route a message to the right queue; an assistant can prepare a draft reply for someone to review. AI integration and consultation covers how to define the scope and limits for that kind of workflow.
What to bring to a first conversation
The most useful thing to bring is a description of the workflow as it works today, including where it breaks down. An anonymised example of a real record, or a short description of where time gets lost, is enough to identify whether automation is the right approach, what it would connect, and where a person needs to stay in the loop.
If you have a workflow that keeps causing repeated manual work, describe it and we can discuss whether it is a good candidate.