When automation comes up, the first question is usually which tool to use. What stalls a project, though, is rarely the tool. It is picking the wrong task to go first. This lesson covers how to measure whether a task is worth queueing.
This lesson deals with the first decision you make when starting with automation: which task goes into the queue. Tool selection, pricing and setup are not the subject here. The goal is that you can pick the most suitable task by measuring it, and explain that choice to someone else with reasons.
By the end you hold three concrete outputs: your task inventory, a written process map of the task you chose, and the current baseline figure for that task. Without these three, whether a system helped afterwards tends to become unmeasurable.
No prerequisites. Software knowledge is not required. Paper and pen, or an empty spreadsheet, is enough.
Automation is the running of a task whose rule was written in advance, without a hand touching it, each time that rule holds. The weight of the definition sits on the part that says written in advance. Where there is no rule there is no automation; what you hold is a wish.
Automation is not a decision maker. It does not learn to decide, it repeats the decision you made. In practice this comes out here: if the person doing the work says it depends, the task is not yet ripe for automation. First open up what it depends means and write down what is done in which case.
A repeating task running on its own according to its written rule. It keeps records, holds the order, does not forget. It returns the same output for the same input.
A repair for a broken process, a mind that replaces staff, or a shortcut for a one off job. When you expect those, the system you build falls short of the expectation.
Tasks that call for judgement, whose exceptions outnumber their rules, whose input arrives in a different shape each time. Automation can assist here, though it cannot take the task over.
Whichever tool builds it, every automation is made of the same five parts. Learning this vocabulary lets you know what to look for while writing your process down. The steps that follow keep filling these five headings in.
The event that starts the automation. A form being submitted, a mail arriving, a time being reached, a record changing status. Each automation wants one clear beginning.
The work done in order after the trigger. Opening a record, sending a message, updating a field, producing a document. The order of the steps is the result itself.
The forks in the road. New customer or returning, amount above the threshold or not, document missing or not. With no condition written, the automation takes the wrong branch at the first different case.
The links between systems. The form to the sheet, the sheet to messaging, accounting to the warehouse. Data passes here, and most errors come out here too.
What happens when something goes wrong. Who gets told, where the record waits, how the work is taken over by hand. Automations built without this part stop quietly.
Businesses tend to want to start at the top layer, yet the upper ones rarely hold before the lower one is in place. Which layer you see yourself on shapes the task you pick next.
Tasks running inside a single system on a written rule: sending a reminder, moving a record from one list to another, producing a document. Tasks here tend to pay back the fastest.
Several systems tied together: a record from a form flowing to a sheet, then to messaging and accounting. Moving here before the rule layer settles tends to double the errors.
The layer that reads text, classifies, prioritises and drafts replies. The decision stays with you, the system only prepares. Without the two layers below, the input to this layer is not dependable.
The symptom is the same in most businesses: the system gets built, used for a few weeks, then nobody opens it again. The setup gets blamed, the tool is swapped, and the second attempt lands in the same place. The cause is rarely technical, it sits in the choice.
A wrongly chosen task has three typical faces. First the rare task: automating something done once a month tends not to cover the setup and upkeep. Second the task whose rule cannot be written: if the person doing it cannot describe the steps, there is nothing to hand to a machine. Third the task that bothers no one: where being wrong carries no cost, automating it carries no priority either.
To choose, you first need to see the options. The inventory is the written list of repeating tasks in your business. Its aim is not to be exhaustive but to be comparable. Noting the work done over one week gives most businesses a workable start.
Build the inventory by asking the people, not by guessing. The person doing the work may run the process differently from how you picture it. Ask the same five questions for each task and write the answers in the same shape.
Do not merge tasks while listing them. Customer follow up is not a task, it is a heading; underneath it sit separate tasks such as sending a quote, making a reminder and updating a record, each of which can be automated on its own. Inventories left at heading level cannot be scored in the next step.
Now you write down the tasks that stood out in the inventory. The test is this: when someone steps into your place, they should be able to do the task end to end from that text. This text becomes both the draft of the automation and the record of how the task runs today.
Fill in the five parts in order while writing. The decision points are the critical part: what is done in which case, where the exception appears. When these go unwritten, the automation you build stops at the first exception and nobody knows why it stopped.
Stop where the writing does not come out. If the process map will not form, the problem is not writing skill, it is the process itself. That task is not ready for automation, and seeing this early costs less than seeing it after the build.
Score the tasks in your inventory against the same three criteria. Scoring takes the choice out of personal preference and makes it comparable. Low, medium and high are enough for each criterion; a score on a 0-100 range works too if you prefer one.
Does the task come up more than once a week? Frequent repetition is where automation earns its keep. On rare tasks the setup and upkeep can outweigh the gain.
Did the map in Step 2 come out? If not, this criterion is low, and waiting is the better call even when the other two are high. Automating a task with no rule means handing the decision to the machine.
What happens when this task is done wrong? If a customer or money is lost, the task is a priority. If there is no cost, automating it carries no urgency.
The criteria do not carry equal weight. Whether the rule can be written is a precondition: if it is low the task drops down the list whatever the other two scores say. Frequency and cost of error complete each other; where one of them is high, the task becomes a candidate.
Sort the scored list and pick not the top task but the smallest among the top ones. The aim of a pilot is not the largest gain, it is showing the method to the team and seeing how the system behaves in your business.
A good pilot is narrow in scope, has a single trigger, produces output you can see, and can be undone by hand if it goes wrong. Where these four hold, the pilot builds confidence in the team. Where they do not, a hiccup in the first attempt can overshadow the whole idea.
Take a photograph of today before the build. If you start without measuring, saying it got better rests on a guess afterwards. Without a baseline to compare against, whether the system helped stays open to argument.
Keep what you measure short. Duration, frequency and error count are enough for most tasks. Record these over one week and repeat the same measurement after the build. Two figures measured by different methods cannot be compared.
Let us run the method end to end on a single example. The example goes through a real estate office, though the steps work independently of the sector.
Inventory: over one week the office writes down its repeating tasks. Recording enquiries coming from portals, calling the enquirer back, updating listing details, preparing contract paperwork, producing the monthly portfolio report.
Scoring: enquiry recording repeats often, its rule can be written, and a late reply costs a customer; high on all three. Contract paperwork is rare and full of exceptions, its rule is hard to write. The monthly report is rare though its rule is clear.
Process map: trigger, a new enquiry landing from the portal. Steps: open the record, assign it to the relevant agent, send an acknowledgement to the customer, send a reminder if no reply went out. Condition: the enquiry goes to the agent of the district it came from. Exception: if the district does not match, the record waits in the office pool and the manager is told.
Pilot: the office builds not the whole process but the acknowledgement and assignment steps only. Narrow, visible, reversible by hand.
Baseline: reply time to an enquiry, weekly enquiry count and the number of enquiries closed without a reply are recorded over one week before the build. The same measurement is repeated afterwards.
To get the return of this lesson, the one thing needed is that you run the exercise below in your own business. It takes a week, and its output becomes the input of the next lesson.
Where you get stuck during the exercise is the weak point of your process. A task whose process map will not come out is a task to tidy up before automating.
Download the task inventory and scoring table (xlsx) · the five questions, the three criteria scoring, the pilot choice and the baseline in one sheet.
The tool comes last. Once the task is picked and its rule written, which tool fits usually becomes obvious. Going in reverse turns into looking for work that suits the tool.
Automation speeds a process up, it does not fix it. Automate a messy process and the mess multiplies at the same speed. The process gets simpler first, automation comes after.
The task eating the most time is usually the most complex one. Going into a complex task on the first build tires the team before they have seen the method.
Automations built without an exception path stop quietly. Nobody notices the stop, records pile up somewhere, and the loss of confidence begins here.
When no baseline is recorded, the result stays open to argument. Even where the system helped, there is no data to show it.
Hearing the process from a single person leads to mistaking that person habit for the rule. When two employees describe the same task, the difference becomes visible.
Before sitting down to a build conversation, you want to be able to say yes to every item below. Where an item is missing, that item is your next task.
The core terms that come up in build conversations. The language of this lesson is built on these.
In this lesson you picked the next task and scored it against three criteria. The next lesson deals with writing that task down: drawing the boundary, writing the steps under who does what and what comes out, marking decision points and exceptions.
The written process is also the input of the third lesson; which fields get collected comes out of that map.
Boundary, steps, decision points, exceptions and the handover test. The pilot task of this lesson gets mapped there.
Which field to collect, how to define it, where it lives.
The whole training section and the modules added since.
If you cannot decide which task to start with, write to us and we can look at your process together.
Get a Quote on WhatsApp