Break the Workflow Into Tasks: Automation Decisions Are Not Made at the Workflow Level

One task is one action, with one output, and one obvious finishing point. If you cannot say in a short sentence what finishing it looks like, you are holding more than one task and you need to split again. Test it against real examples. "Look up the hourly rate for a Level 2 electrician on the commercial rate card" is one task. It finishes when you have a number. "Prepare the quote" is not one task. It finishes when the quote is sent, which conceals a lookup, a calculation, a decision and a piece of writing. The finishing point is the part people get wrong. A task that finishes with "and then you check whether it looks right" contains a second task, the checking. Pull it out and name it, because checking is often the task that decides whether the whole thing can run unattended. A useful discipline: write each task starting with a verb and ending with a noun you could point at. Retrieve the rate. Calculate the subtotal. Draft the covering note. Approve the discount. If the noun at the end is vague, split further. Most workflows that people describe as three steps turn out to be nine or ten tasks once written this way, and that expansion is not bureaucracy. It is where the automatable work becomes visible.

Because an automation encodes exactly one version of a process, and silently breaks every other version. If three people run your intake workflow, you almost certainly have three workflows, and the person who describes it best is not necessarily the person who runs it most. This is the failure we see most often. The owner explains the process, a build gets scoped from that explanation, and it goes live. It works for the owner. It produces wrong output for the two staff who have been handling the tricky half of the volume with a step nobody wrote down, and nobody connects the complaints to the build for a month. So interview each person separately, and ask them to walk through the last real instance they handled rather than the process in general. The general description is the official version. The last real instance is the true one. Ask what they did when the information was missing, what they do for the awkward customer, and which step they skip when they are busy. The reconciliation is the work. When two people describe the same task differently, you have found either an undocumented decision rule or a genuine disagreement about how the business operates, and both are worth more than the automation. Resolving them is usually where the real discovery happens, and it frequently improves the manual process enough that the automation matters less. Our guide on running a process manually three times first covers how to capture those runs so the differences show up on paper.

Sort every task into one of five kinds: lookup and retrieval, transformation and formatting, drafting, checking and comparison, or judgement. The first four are broadly machine work. Judgement is not, and no amount of prompting changes that. | Kind of task | What it means | Machine or human | | --- | --- | --- | | Lookup and retrieval | Fetching a known value from somewhere it already exists: a rate, a stock level, a past invoice, a customer record | Machine, reliably | | Transformation and formatting | Changing the shape of information without adding anything: arithmetic, unit conversion, moving fields between systems, building a PDF | Machine, reliably | | Drafting | Producing new text or structure from inputs: a covering note, a summary, a first-pass schedule | Machine, with a human reading it | | Checking and comparison | Testing one thing against another and reporting the difference: does the total match the line items, is this address in our service area | Machine for the test, human for what to do about a fail | | Judgement | Weighing factors that are not all written down, where reasonable people would disagree | Human | The line that matters is between checking and judgement. Checking asks whether something matches a rule you can state. Judgement asks whether you should do something, and the answer depends on context you never wrote down. If you can put the rule on an index card, it is checking. If you cannot, it is judgement, and it stays with a person. One caution on drafting. A machine drafts fluently and confidently regardless of whether it is right, so drafting tasks need a named reader before the output leaves the building. That is not a hedge, it is a design decision about who owns the output.

Here is the quoting workflow from the opening, written out as tasks. This is the artefact you want at the end of the exercise, not a flowchart of boxes. | # | Task | Kind | Who does it | Why | | --- | --- | --- | --- | --- | | 1 | Pull the job details out of the enquiry form and the photos | Lookup | Machine | The information already exists in a fixed place and a fixed shape | | 2 | Retrieve the current rate for this job type from the rate card | Lookup | Machine | One value, one source, no interpretation | | 3 | Calculate materials, labour and margin into a total | Transformation | Machine | Arithmetic with stated rules, and a machine will not misread its own spreadsheet | | 4 | Check the customer's payment history and outstanding balance | Checking | Machine | The test is a stated rule, so the machine runs it and reports the result | | 5 | Decide whether to discount, and by how much | Judgement | Human | Depends on relationship, pipeline and how much you want this job, none of which is written down | | 6 | Decide whether to take the job at all | Judgement | Human | Same reason, with more at stake | | 7 | Draft the covering note in the business's usual voice | Drafting | Machine, human reads it | Patterned writing, but it goes to a customer, so someone signs it off | | 8 | Send the quote and log it against the job | Transformation | Machine | Moving a finished artefact into two systems | Six of eight tasks are machine work. The two that are not sit next to each other in the middle, which is the outcome you want and the subject of the next section. Note also what task 4 does for task 5: it puts the payment history in front of the person exactly when they are deciding about the discount.

Because someone has to notice the machine finished. That noticing is unpaid, unscheduled and easy to forget, and it is the reason a workflow with six alternating handoffs runs slower than the manual version it replaced. This is the point that almost never gets stated when automation is scoped. Teams count the minutes a machine saves and treat the handovers as free. They are not free. Each switch from machine to human costs a notification that lands in a queue, a context switch for the person, the time before they open it, and the risk that they do not. Each switch from human back to machine costs the person remembering to trigger the next stage. We are not aware of a reliable public benchmark for the cost of a mid-workflow handover, and we are not going to invent one. What we can say from building these systems is that the elapsed-time cost of a handover is usually larger than the processing time of the task on either side of it. A task that takes the machine four seconds and the person ninety seconds can sit for six hours because it landed in a shared inbox at 4pm. So group the tasks. Two long stretches beat six alternating handoffs, even if the six-handoff version automates more tasks in total. Order the workflow so the machine does everything it can before it needs a person, presents one consolidated decision, then does everything it can afterwards. In the quoting example, tasks 1 to 4 run unattended, tasks 5 and 6 are one human moment, and tasks 7 and 8 run unattended. One handover out, one handover back. That is the shape to aim for, and it is worth reordering tasks to get it.

Keep them human, and make the machine assemble everything the person needs to decide in one place. Automating the assembly around a decision is frequently the highest-value automation in the whole workflow, even though it automates no decision at all. Think about what actually consumes the time in a judgement task. It is rarely the judging. A quote decision takes about fifteen seconds of thought once you know the customer's history, the current pipeline and what the job is worth. What takes twenty minutes is opening four systems to find those three things, and the twenty minutes is why the decision waits until Thursday. So build the brief, not the decision. Have the machine gather the payment history, the previous jobs, the margin on similar work and the current schedule, and present them as one short summary with the decision stated as a question. The person answers in a sentence. The workflow continues. This also handles the reliability problem cleanly. A machine that assembles evidence and a human who decides is a design where the machine's mistakes are visible: if it pulled the wrong customer's history, the person reading it notices. A machine that decides and a human who occasionally spot-checks is a design where the mistakes are invisible until they are expensive. The first design is worth building. The second is the one that turns up in the 95 per cent of AI pilots that deliver no measurable return, a figure reported by MIT in 2025.

Because it is what you hand a developer, and it survives staff turnover. A tool subscription expires, a platform changes its interface, the person who built it leaves. A written map of what your workflow actually does outlasts all three. A developer cannot work from an ambition. Given "automate our quoting", they will build the version that is easiest to demonstrate. Given a numbered list of eight tasks, each with a kind, an owner and a stated rule, they will build the thing you meant, and you will find out during scoping rather than during acceptance that tasks 5 and 6 were never on the table. The map is also the fastest onboarding document your business will ever produce. When the person who runs the workflow leaves, the replacement gets the list rather than a fortnight of shadowing, and the tasks the machine handles keep running while you hire. Keep it boring and keep it current. A numbered table in a shared document beats a diagramming tool nobody has a licence for. Date it, name the people you interviewed, and revise it when the process changes rather than when the automation breaks. If you want a structured starting point, our free workflow audit scores your processes on hours, consistency and risk, which tells you which workflow to map first.

How small should a task be? Small enough that you can name one output and one finishing point in a short sentence. "Retrieve the rate for this job type" is a task. "Prepare the quote" is four or five tasks wearing a coat. If your description of a task contains the word "and", or ends with "then check it", split it again. Most workflows people describe as three steps are nine or ten tasks. Do I really need to interview everyone who runs the process? Yes, separately, and ask each of them to walk through the last real instance rather than describe the process in general. Different people run the same workflow differently, and an automation encodes exactly one version and quietly breaks the others. Reconciling those versions is the actual work, and it usually improves the manual process before you build anything. Which tasks can a machine handle reliably? Lookup and retrieval, transformation and formatting, and checking against a rule you can state. Drafting too, provided a named person reads the output before it leaves the business. What a machine cannot do is judgement: any decision that weighs factors nobody has written down, where reasonable people would disagree. If you cannot put the rule on an index card, keep the task human. Isn't more automation always better? No, because every switch between a person and a machine mid-workflow costs someone noticing the machine finished. A design that automates six tasks across six handovers often runs slower than one that automates four tasks across two. Group the machine work into stretches, put the human decisions together, and aim for one handover out and one back. What if a task is judgement but takes ages? That is usually assembly time, not thinking time. The decision takes seconds once the person has the customer history, the pipeline and the margin in front of them. What takes twenty minutes is opening four systems to find them. Automate the assembly and present one short brief with the decision stated as a question. The judgement stays human and the delay disappears. What do I actually hand a developer? A numbered table of tasks, each with its kind, its owner, the stated rule where one exists, and where the handovers fall. That document is worth more than a tool choice, it survives the person who wrote it leaving, and it is the difference between a build that matches your process and a build that matches a five-minute conversation.