Work Automation

Most organisations have a handful of jobs that get done the same way every week. Someone opens an email, copies figures into a spreadsheet, formats a quote, sends it, then writes a note to chase it in ten days. None of it is difficult. It is just constant, and it is usually done by people whose time is worth considerably more than the task.

Work automation means handing those jobs to software. Not all of them, and not all at once. Only the ones that are genuinely repeatable, where the rules hold steady and a mistake is either cheap or easy to catch.

Understanding the current process comes first. Watching a task being performed often reveals exceptions that the process document does not mention.

The work that tends to qualify

Quote preparation. A request arrives by email or form. Someone looks up rates, applies the usual discounts, assembles a document and sends it. If your pricing follows rules rather than instinct, most of that is mechanical. The person still decides whether the price is right. They stop doing the typing.

Inbox triage. A shared mailbox that three people watch, where half the messages are routine: delivery queries, invoice copies, supplier confirmations, spam. Sorting, labelling, routing to the right person and drafting the standard replies can be done before anyone opens the mailbox. The unusual messages reach a human faster because the routine ones are already out of the way.

Document extraction. Purchase orders, delivery notes, supplier invoices, timesheets, application forms. Reading numbers off a PDF and typing them into a system is one of the most common and least rewarding jobs in any office. It is also where a lot of quiet errors come from.

Report assembly. The monthly pack that someone spends a day and a half building from five sources. The figures rarely change shape. The pulling, joining and formatting can be done on a schedule, leaving the commentary, which is the part that actually needed a person.

Invoice chasing. Knowing who is overdue, by how long, what was said last time, and sending the right message at the right point in the sequence. The chasing itself is a rules problem. The awkward phone call is not, and stays with you.

How to identify candidates

Start by observing the person who does the job, several times if the task varies. A process document is a useful reference, but it may describe an earlier version of the work.

Three things decide it.

The first is repeatability. If the same inputs produce the same decision, a machine can make that decision. If the answer depends on knowing that this particular customer is difficult, or that the figures are always wrong in March, that knowledge has to be written down before anything can be automated. Sometimes writing it down is the whole benefit and no software is needed.

The second is the total time involved: frequency multiplied by the time per task, alongside its business importance. Compare the likely saving with setup, review and maintenance effort.

The third is the cost of getting it wrong. A mis-sorted email is a minor irritation. A mis-sent invoice is an embarrassment. A mis-calculated payment is a problem. The higher the cost of an error, the more checking the design needs, and the more likely it is that a person stays in the middle of it.

Some tasks should simply be stopped. A report that nobody reads does not need automating. It needs cancelling.

Pilot one task before expanding

Map the task, write down its rules and exceptions, and estimate how much time it consumes before selecting a solution. Agree the assessment deliverables and any costs with the provider.

Choose one task for the first pilot. Run its automation alongside the existing manual process and compare the outputs. Disagreements are the point. Each one either exposes a rule that was missed or a habit nobody had articulated.

Only when the two match consistently does the manual version stop. That period is not wasted effort. It is the cheapest way to find out whether the thing works, before it is quietly doing real damage.

If the pilot shows a smaller saving than expected, reassess the business case before expanding it.

Where a human stays in the loop

Some things do not get fully automated, by design.

Set review requirements according to the consequences of a mistake. A quotation with bespoke commitments or sensitive correspondence may need approval before sending. A routine acknowledgement can use a pre-approved template with clear limits. Include the time needed for review when estimating savings.

Anything involving money moving gets a person. Payments, credit notes, refunds, changes to bank details. That is partly a quality question. It is also a fraud question, and an automated payment path is a target.

Anything with a contractual or legal consequence gets a person. Cancellations, notice periods, anything a regulator would want to see reasoning behind.

And anything the system is unsure about gets a person. A useful design separates clear cases from ambiguous ones and hands over the latter rather than guessing. A system that escalates what it cannot settle is more useful than one that handles everything with unexamined confidence.

Automation done badly creates more work than it saves

This is worth saying plainly.

Badly built automation fails silently. It stops running on a Tuesday and nobody notices until the month end. It encodes a rule that was true when it was written and is no longer true, and it keeps applying that rule confidently. It breaks when a supplier changes their invoice layout, and the failure looks like a missing invoice rather than a broken integration.

Worse, it erodes trust. Once people have been caught out by it, they start checking every output by hand. At that point you have not removed a job. You have added one, and you are paying a maintenance cost for the privilege.

Design for failure. An automation should log what it did, alert a named person when it cannot complete and offer a safe way to pause it. Document the rules in plain English so the process can be maintained in-house or by another supplier.

More on the principles behind this in putting the boring work on autopilot.

When automation is the wrong answer

Avoid automating a broken process. If the underlying workflow makes no sense, making it faster makes it worse. Fix it first, or delete it.

Understand the ongoing maintenance and support requirements. Agree costs, monitoring responsibilities, ownership and exit arrangements before the work starts.

A task done twice a year in twenty minutes may not justify automation. Compare likely maintenance costs with the saving.

Where the work requires interpretation, compare human handling, rules and a limited AI-assisted step. A custom AI system may be worth assessing, but the presence of judgement does not by itself justify building one.

Getting started

Write down the repetitive tasks that consume time, their frequency and the consequences of a mistake. That gives you a starting point for comparison.

Read putting the boring work on autopilot, or request practical help from our sister agency SuffolkWeb. Our editorial approach explains this publication, and you can contact The SEO Blog with a question or correction.