Every Monday, an office manager opens last week’s sign-up form, copies each name and email address into a spreadsheet, and sends the same welcome message to each person by hand. It takes most of the morning, and now and then a mistyped address means a welcome goes nowhere.

Workflow automation means handing steps like these to software: when the form is submitted, a new row appears in the spreadsheet, the welcome goes out and the team gets a notification, without anyone doing it. The way to start is small and deliberate, in five steps:

1. Pick one frequent, rule-based task that is safe to get wrong
2. Write down the steps and fix the obvious flaws first
3. Start with one trigger and one action
4. Test it and log every run
5. Name an owner and review it regularly

Workflow automation in one sentence: when this happens, do that

Workflow automation is software carrying out the steps of a recurring process by rule. Something happens, called the trigger: a form arrives, an email lands, a date comes round. The software then performs set actions, such as adding a row, sending a message or creating a task.

It comes in three sizes: rules inside apps you already use, such as email filters; platforms that connect separate apps; and robotic process automation, or RPA, the large-company version, in which software “bots” copy the path a person takes through screens. Much of the research here comes from RPA; we apply it to smaller tools because they handle the same kind of task: typically rule-based, well structured and repetitive, such as moving data between applications, as a 2020 review describes them.¹

The reason it works is also its limit. Software follows its rules exactly, at any hour and without typing errors. It follows them just as exactly when they are wrong, and it can miss patterns an experienced person would spot at once.¹

For the office manager, the Monday chore becomes three rules: when the form gets a new entry, add a row to the sheet; when a row is added, send the welcome message; if the email field is empty, flag the row for a person. The test for any task: if you cannot write it down as “when X happens, do Y,” it is not ready to automate yet.

Guides on email rules and platforms are planned under automation and no-code workflows.

Software is good at rules and poor at judgment

Software takes over tasks with explicit rules, while tasks that need flexibility, judgment and common sense have proved the hardest to automate, the MIT economist David Autor wrote in 2015. In a 2015 review of workplace automation, Autor argued that computers substitute for people in routine, codifiable tasks while raising the value of the problem-solving, adaptability and creativity that people supply.²

“Routine” in this sense does not mean dull. It means every step can be written down, as in simple bookkeeping or the sorting and storing of structured records. The catch, Autor argues, is that much of what people do well they cannot spell out as rules, so there is nothing for software to follow.²

In practice, a rule covers only the cases its author thought of. When Telefónica O2, a UK mobile operator, had automated back-office processes, some customers excitedly pre-ordered a new iPhone several times. A person would have seen one customer wanting one phone; the software shipped several. The company learned that processes it thought fully rule-bound needed extra “common sense” rules once people were taken out, according to a 2015 London School of Economics case study by Mary Lacity and colleagues.³

Follows clear rulesNeeds judgmentFrequentOccasional

Frequent, Follows clear rules: Automate firstthe best first candidates

Frequent, Needs judgment: Automate the rule partsend the judgment calls to a person

Occasional, Follows clear rules: Use a templatea full automation may not pay back

Occasional, Needs judgment: Keep it humanrare and judgment-heavy

The practical lesson is to split tasks, not jobs. An expense claim has a rule part (is a receipt attached, is the amount under the limit?) and a judgment part (was this dinner a genuine client expense?). Automate the first and route the second to a person. A 2018 OECD working paper makes a related point about whole jobs: people in the same occupation often do quite different tasks, so it estimated automation risk job by job rather than by job title.⁴

The best first candidates are frequent, boring and stable

Research on software bots mostly agrees that good automation candidates are rule-based, repetitive, stable, fed by structured digital data and light on exceptions. A 2020 structured review led by Rehan Syed of Queensland University of Technology collected these traits from the literature, noted some dissent, and warned how thin the evidence behind them is.¹

The study

Limited evidence

Which tasks suit software bots? Syed and colleagues' 2020 review

The review drew from the literature a list of traits for tasks suited to bots: highly rule-based, high in volume, mature and stable, standardized, well documented, low in exceptions and fed by structured digital data. A few sources it cites dissent, saying medium volumes or temporary processes can suit bots too. It also judged that methods for choosing tasks lack empirical validation and were largely developed by software vendors on limited anecdotal evidence.¹

These traits are the practitioners’ majority view, not tested rules, but each has a clear reason. Frequency multiplies the saving. Bots need a prescribed rule for every eventuality. Every change to the process, a screen or a business rule becomes a repair job. Poor input data makes bots fail or do the task wrongly. And each exception needs its own branch, which is why the review reports that letting a specialist handle a rare exception by hand can be cheaper than programming for it.¹

Copying weekly sign-ups into a sheet passes on every count; answering customer complaints fails on most, because each one needs a judgment and a personal reply.

We add one test of our own: the task should be safe to get wrong. The review notes that because bots run with little human oversight and can be copied at scale, a flawed one can cause damage at scale.¹ Start where a mistake would be annoying, not costly.

Map the process before you automate it

Automating a messy process makes the mess run faster, because software repeats every step exactly, including the ones nobody needs. The 2020 review reports that the literature stresses optimizing processes before automating them; one consulting report it cites takes the opposite view, and some sources see automation as a way to standardize a process.¹

Telefónica O2 is a documented example of fixing first. The company spent about two years removing processes nobody needed and simplifying the rest, including a legacy check on shipped orders that was no longer worth running because the order process had become almost error-free, and it later stressed that this work should come before automation. Its first trial, in 2010, automated two high-volume, low-complexity processes, one of them swapping a customer’s SIM card.³ The caveat: this is one company’s success story, from a research program sponsored by the vendor whose software it used.

At desk scale, say invoices reach you by email, by post and through a supplier portal. Write every step on paper, cross out the steps nobody needs, and ask suppliers to use one route before you automate anything. The habits in how to find and fix the flaws in a recurring process apply here: follow one real case from start to finish and mark each point where work waits or is sent back.

Will it save time? A worked example

An automation saves time only if the minutes it removes over a year exceed the hours spent building, testing, fixing and checking it. The table below is our illustration with assumed figures, not a measurement.

The row that is easiest to forget is upkeep: bots cannot monitor themselves, the 2020 review notes, so a person has to. Time is also not the only gain: the same review collects reports of fewer errors such as incorrect data and missed steps, mostly from case studies rather than comparisons.¹

The lesson from the arithmetic: if a task is rare, a template or a checklist usually beats an automation.

Automations fail quietly, and people stop watching

People stop watching an automation closely once it has worked well for a long time, so its rare failures can go unnoticed, the psychologist Lisanne Bainbridge of University College London warned in 1983. Her irony: automation leaves people with the job of watching for rare failures, and watching a system in which almost nothing happens is something people do poorly.⁵

The reason is attention. Writing about control rooms and flight decks and drawing on studies of vigilance, Bainbridge noted that even a highly motivated person cannot keep up effective visual attention to a source of information on which very little happens for more than about half an hour. A sheet that has filled itself correctly for months is that kind of source. She also warned that unused skills fade, and argued that automatic systems should fail obviously.⁵

A 2010 review by Raja Parasuraman and Dietrich Manzey, which we read only in abstract, found this complacency when other tasks compete for attention, in experts as well as novices, and simple practice did not cure it.⁶ Trained professionals are not immune either, as what AI literacy does and does not protect against describes for doctors given flawed AI advice in a small trial.

1. Cases that follow the rules: the automation runs them from start to finish
2. Odd cases: anything the rules do not cover goes to a person instead of being forced through
3. The log: every run leaves a record, and a named owner reads it on a fixed day

Back to the office manager, as an illustration. Say a colleague renames the email column in the sign-up sheet. The welcomes stop, and nobody notices for three weeks, until a new member asks why she never heard back. The idea was fine; nothing made the failure visible.

Myth

Once an automation is set up, it runs itself.

Fact

Processes, screens and rules keep changing, and software cannot tell when its own rules have gone stale. Every automation needs someone who checks it.

The practical rule: give every automation a named owner, and write down how to do the task by hand. Keep a run log and check it on a fixed day each week against one simple count, such as rows added against form entries received; Bainbridge observed that people can write down numbers without noticing what they are, so reading the log alone is not enough.⁵ And make failure visible: switch on your tool’s failure alert, so a broken run reaches a person.

How to build your first workflow automation

Build your first workflow automation the way the 2020 review’s consensus advice suggests: think big, but start small, automating part of a process before the whole.¹

1. Pick one frequent, rule-based task that is safe to get wrong

Run your candidates through the five questions above and choose the dullest one that passes. At work, check your employer’s rules on connecting apps and accounts first.

2. Write down the steps and fix the obvious flaws first

List every step as it is really done today, workarounds included. Remove steps nobody needs and standardize the input, for example with required fields on a form.

3. Start with one trigger and one action

Build the smallest useful version: when a form entry arrives, add a row. Add the welcome email once that link has run cleanly for a couple of weeks.

4. Test it and log every run

Test the awkward cases as well as the tidy one: an empty field, a duplicate entry, an unusual name. The review warns that recording a task as a person does it captures only the “happy path,” where nothing goes wrong.¹ Make sure every run leaves a record, such as a log sheet or a daily summary.

5. Name an owner and review it regularly

Write down the owner and the manual steps where colleagues can find them. Check the log weekly for the first month, then monthly. When the process changes, the owner updates the automation; when nobody needs it any more, switch it off.

WiserHours

From chore to first automation

• Choose one weekly-or-more task that passes the five questions
• Write its steps on paper and cut the ones nobody needs
• Standardize the input, for example with a form
• Build one trigger and one action
• Test empty, duplicate and unusual entries
• Turn on failure alerts and keep a run log
• Write down the owner and the manual fallback
• Put a weekly log check in the calendar

Find this checklist online:
https://wiserhours.com/automation/workflow-automation-for-beginners/#checklist-workflow-automation-for-beginners-first-build

What the evidence supports, and where it runs out

The strongest evidence explains which tasks computers can take over; advice on choosing and running small automations rests mostly on case studies, practitioner consensus and human-factors research from other settings. Use the candidate traits as a starting filter, not a proven formula; your own run log is the real test.

The bottom line

Practitioner advice and simple arithmetic both favor small automations: a frequent task with clear rules and a predictable input, watched by someone after launch. Start with one low-stakes chore: tidy the process, automate one step, make failures visible and give it an owner. Anything bigger can wait until that one has run cleanly for a month.