From Business Goal to Workflow List: The Step Most Owners Skip Before Buying a Tool

The loudest complaint in a business is usually a small process, and the expensive process is usually invisible because everyone has already adapted to it. If you build from complaints, you will fix the paper cut and leave the haemorrhage alone. Annoyance is a poor signal because it measures irritation per event, not cost per year. A three minute task done twice a day with a clunky login will generate constant grumbling. A quoting process that quietly takes four days and loses one job in five generates no grumbling at all, because nobody is standing next to it waiting. The people inside it have built workarounds, learned the exceptions and stopped noticing. This is the same argument made in digitised is not automated: saving minutes on a step nobody was waiting on does not change the profit and loss. Removing work from a step with spare capacity gives you a slightly nicer afternoon. Removing work from the step where everything queues gives you throughput. Starting from the goal forces the question in the right order. Instead of asking which task irritates you, you ask which sequences of work stand between you and the number. Some of those will be the tasks people complain about. Several will not be, and those are usually the ones worth building against.

Decomposition is three questions asked in order, repeated until the answers stop being abstract. Write the goal, ask what has to happen repeatedly for that number to move, then ask what has to happen before that, and keep going until every answer names something that starts on a schedule or in response to an event. Step one: state the goal as a number and a direction. "Grow revenue 20 per cent" is a goal. "Get better at sales" is a wish. If you cannot say which number you are watching, you cannot tell later whether anything worked. Step two: ask what repeating sequence of work has to happen for that number to move. Answers at this level tend to be broad: more quotes go out, fewer customers go quiet, jobs get invoiced sooner. That is fine for now. Broad answers are a signpost, not a destination. Step three: for each of those, ask what has to happen before that can happen. More quotes go out requires site visits to be booked. Site visits require enquiries to be qualified. Qualification requires enquiries to land somewhere a person actually looks. Three or four rounds of this question and you are no longer describing intentions. You are describing work with a start and an end. Stop when the answer names a trigger. "Every Monday morning" is a trigger. "When a form is submitted" is a trigger. "When we get around to it" is not a workflow, it is a habit, and habits are the first thing to fail under load.

Take a common goal for an Australian service business: stop losing enquiries to slow response. It sounds like one problem. Decomposed, it is at least six workflows, and only two of them are what most owners expect. The first round of questioning gives you the obvious answer: reply faster. But reply faster to what? You cannot reply to an enquiry you have not seen, so before replying there has to be capture. Enquiries arrive by web form, by phone, by text message and occasionally through a marketplace app, and if they do not land in one place then speed is not the constraint, visibility is. The next round exposes the part that actually loses jobs. A fast acknowledgement does not win work. A quote wins work. So the goal reaches past the reply and into qualification, booking, quoting and follow-up. Most businesses that believe they have a response time problem have a quote follow-up problem, because the enquiry was answered in ten minutes and the quote then sat unanswered for three weeks with nobody chasing it. Here is the decomposed list. | Goal | Workflow | Trigger | What finishing looks like | | --- | --- | --- | --- | | Stop losing enquiries to slow response | Enquiry capture and acknowledgement | An enquiry arrives on any channel | Every enquiry exists as one record with a timestamp, and the sender has been told what happens next | | Stop losing enquiries to slow response | Qualification and triage | A new enquiry record exists | The enquiry is marked in scope or out of scope, and out of scope ones have been answered and closed | | Stop losing enquiries to slow response | Booking the site visit or call | An enquiry is marked in scope | A time sits in the calendar of the person attending, and the customer has confirmed it | | Stop losing enquiries to slow response | Quote production | The site visit is finished and the notes exist | The quote has been sent and a copy is attached to the enquiry record | | Stop losing enquiries to slow response | Quote follow-up | A quote has been sent and no answer has arrived within the agreed number of days | The customer has said yes, said no, or has been contacted three times and marked cold | | Stop losing enquiries to slow response | Won job handover | A quote is accepted | The job is scheduled, the deposit is invoiced, and the customer knows the start date | Six workflows, one goal. Notice that the response time problem the owner described is only the first row.

A workflow has three things: a trigger, a sequence and a finishing point. If you cannot name what starts it and what finishing looks like, you are still describing a goal or a department, not a workflow. Run the test on your own list. "Sales" fails, because nothing starts it and it never finishes. "Improve customer communication" fails for the same reason. "Follow up a quote that has had no answer for five days until the customer says yes, says no, or is marked cold" passes, because you can point at the moment it begins and the moment it is done. The finishing point is the half people skip, and it is the half that makes a build possible. Without it, nobody can tell whether the workflow ran correctly or simply ran. A finishing point should be a verifiable state in a system somewhere: a record updated, a message sent, a status changed, an invoice raised. "The customer is happy" is not a finishing point. "The invoice exists and the customer has been sent it" is. The sequence in the middle can stay rough for now. You do not need the task level detail to decide which workflow to work on, and going straight to task detail on all six is how a planning exercise turns into a month. Get the trigger and the finish right on every row first. The middle is the next piece of work, and it only has to be done for the row you choose.

If every workflow on your list is already tidy, you have written down the ones you are proud of rather than the ones costing you money. A useful list has rows on it that you would rather not show anyone. There is a natural pull towards documenting the parts of the business that are already documented. Those are easy to describe, they make you look organised, and they produce a clean page. They are also, by definition, the parts that already work. Nothing on that page is going to change a number. The rows worth having usually share a few features. Somebody has to remember to do them. They live partly in one person's head and partly in a spreadsheet nobody else opens. They have an exception that everyone knows about and nobody has written down. When you ask two people how the workflow runs, you get two different answers, and both are confident. That discomfort is diagnostic rather than embarrassing. A workflow that two people describe differently is not badly run, it is unspecified, which is a different and much more fixable problem. Writing it down is the first time anyone has had to reconcile the two versions. In our experience that reconciliation, not the software, is where most of the value in an automation project actually gets created.

In most small service businesses the constraint is not a system, it is the join between two systems where a person is doing the integration by hand. Look at your list for the rows where information leaves one tool and arrives in another because someone typed it. The pattern is easy to recognise once you look for it. The enquiry arrives in a web form and gets copied into the job management app. The site visit notes live in a phone and get retyped into the quote. The accepted quote gets re-entered into the accounting software. Each transfer takes a few minutes, so nobody counts it, and each transfer is a place where a job can quietly stop moving because the person who does the copying was on site all day. This is covered in more detail in the join between your tools is a person. The short version is that these joins are invisible on an org chart and invisible in a software audit, because no tool is failing. The failure is in the space between the tools, and the space is staffed by a human with a memory and a to-do list. When you score your workflow list, the rows with the most hand transfers usually rank highest, for two reasons. The work is repetitive and rule based, which makes it a good build. And the delay it causes is the delay the customer feels, which ties it directly back to the goal you started from.

The list is not the decision. Once you have six or eight workflows with triggers and finishing points, score them, because the next question is which single one you build against first. The three things worth scoring are hours, consistency and risk. Hours tells you the size of the prize: how much time the workflow consumes per week, costed at the loaded rate of the person doing it, not the rate you wish they were on. Consistency tells you whether it is buildable yet: a workflow two people describe differently will encode one person's version and break for everyone else. Risk tells you how the build has to be shaped: work whose wrong output is expensive and hard to catch gets built as draft and review with a person approving, not left running unattended. We built a free tool that does this scoring. The workflow audit walks through your list and scores each workflow on hours, consistency and risk, with no email required to see the result. After scoring, take the top row and break it into its individual tasks, deciding task by task which ones a machine does and which stay with a person. If you would rather start from the broader survey and interview process instead of a single goal, the AI readiness audit covers that path and produces a comparable list from the other direction.

How many workflows should a decomposed goal produce? Usually between four and eight for a single goal in a business of 5 to 50 people. Fewer than four generally means you have stopped at the department level and one of your rows is really three. More than ten usually means you have started listing tasks rather than workflows, which is the right detail for later but too granular for choosing where to start. Do I need to decompose every goal before building anything? No. Take one goal, the one you would name if someone asked what is holding the business back this year, and decompose that. A single goal produces enough workflows to keep a small business busy for two quarters. Decomposing three goals at once produces a document nobody reads. What if a workflow spans two teams and nobody owns it? That is a strong candidate rather than a problem. Workflows that cross a boundary between two people or two systems are where work waits, and waiting is what your customer experiences as slowness. It does mean you need to name one owner before you build, otherwise the automation inherits the same ambiguity that caused the delay. Is this the same as process mapping? It is one level above it. Process mapping documents how a workflow runs, step by step. Decomposition works out which workflows exist and which one is worth mapping. Doing detailed maps of all eight workflows before choosing one is a common way to spend a month and build nothing. What if the goal is just revenue growth? Then ask what has to happen more often, or fail less often, for revenue to grow. Usually it resolves into more quotes going out, a higher proportion of them being accepted, or existing customers coming back sooner. Each of those decomposes into workflows in the same way. Revenue itself is never a workflow, because nothing triggers it and it never finishes.