The question has changed
For a long time the limit was technical. A team wanted its enquiries logged, its posts queued and its monthly figures assembled without anyone opening a spreadsheet, and the honest answer was that the tools weren't there, or that the build cost more than the work it replaced. That has stopped being true for most of what a marketing team does on a weekly cycle. The limit now sits somewhere less interesting: whether a process is settled enough to describe, and whether anyone can say what it currently costs in time.
So the first question in a strategy session isn't what could run on its own. It is which parts of the week are stable enough to hand over, and who looks after them afterwards. We have seen automations built on a process that changed the month after handover, and someone in the client's team then has to unpick a system they did not build. That costs more than the manual version ever did.
This is where most of the disappointment with automation comes from. The build works. The judgment behind it was never made, so the team is left with a faster version of a process that was not worth keeping.
Four conditions do most of the sorting, and they are meant to be hard to pass.
The conditions a task has to pass
The first is a trigger somebody can name. A form submission, a completed job, a deal reaching a stage, the first Monday of the month. If a task starts because a person remembered it, it has no trigger yet, and giving it one is the actual piece of work. With follow-up, that is often the whole job.
The second is that the steps run the same way every time, in the same order, with the same fields. We write them down in the session, in the words of the person who does them. When that person keeps saying that it depends, the dependency is either a rule nobody has written down, in which case we write it, or it is judgment, in which case it stays with a person.
The third is that someone can count the time. The team's own estimate is enough to start with and we record it as an estimate, in their words, against the tasks they named. What matters is that a number exists and the team said it out loud, because that is what the work gets read against at day thirty.
The fourth condition applies to the output. Somebody has to want the result. A weekly report that goes to a channel nobody opens does not become useful because it assembles itself, it becomes a report nobody opens, produced faster. The better recommendation is to stop making it, and that recommendation costs us a build.
None of the four needs a tool to answer. They get answered in a room with the people who do the work, a list of tasks on the table, and somebody willing to say out loud that a step exists only because a manager asked for it two years ago.
What we leave alone
Work that carries judgment stays with a person. Pricing exceptions, the reply to a customer with a real complaint, the decision about what a campaign is going to say. Speed isn't the constraint on any of them. We will automate the assembly around a judgment, so that the record is in front of the person and a draft is waiting, and we leave the decision where it is.
Processes that are still being invented stay manual. A campaign format that has run twice is not a process, it is an experiment, and automating an experiment fixes whichever version of it happened to exist that month. We wait until it settles. That is unpopular in the room, because it delays a build both sides want, and it prevents most of the rework we would otherwise be paid to do.
Work that comes round rarely is usually not worth it. An annual planning spreadsheet that swallows a full day is a smaller prize than a report that takes a short sitting every Monday morning, and teams nominate the annual one first because it is the one they dread.
Work with unreliable inputs waits for the inputs. Where a CRM holds duplicates, missing sources and names that were typed in wrong, a sequence built on top of it sends the wrong message to more people and faster than any person could. The cleaning gets automated first, or the build waits.
Where the hours actually sit
The tasks a team volunteers in the first ten minutes are the big rare ones, the quarterly deck and the annual budget spreadsheet, because each of those ruins a week and gets remembered for it.
The hours are somewhere quieter. They are in the retyping of enquiry details that were already on the form, the message asking whether a quote arrived, the Monday pull of figures out of two ad platforms and the CRM, the review request after a completed job. Nobody complains about any of these, because each one takes minutes. Counted across a month they are most of where the week went.
We get at them with a narrower question. We ask what happened in the last five working days, in order, and which tool each step ran in. People can reconstruct a week. Nobody averages a year accurately, and the averages people offer are usually a description of the worst month they can remember.
That is also why the session asks who does a task and how often before it asks how long it takes. Frequency is the figure people answer accurately, and it sets the order of the build. A short task on a weekly trigger is worth more than a long task on an annual one, almost every time.
