It happens on a schedule or a trigger
Something starts the work: an email lands, an order posts, a date passes. Work that begins because a person noticed is work whose volume you cannot yet measure.
Optional analytics and marketing cookies stay off unless you allow them. Cookie policy · Privacy policy
Deciding what to automate is a shorter conversation than most people expect. Four signals say a workflow is worth building against, two say leave it alone, and one map settles the rest. It is written out here in full, with nothing to register for.
Something starts the work: an email lands, an order posts, a date passes. Work that begins because a person noticed is work whose volume you cannot yet measure.
Not "the team knows what to do". If the rules can be stated, the exceptions can be named, and someone can say what happens in each, the process is describable enough to build against.
The same fields in roughly the same places. Variation is fine and expected; unbounded variation means the first piece of work is standardising the input, not automating the process.
Volume, time per item, people involved, rework rate. An estimate is enough to start. Without one there is no baseline, and without a baseline there is nothing to price an outcome against.
Saying this early is cheaper for everyone than discovering it in month three, and it is the part of the method that makes the other four signals worth trusting.
A process being redesigned, a system being replaced or a regulation arriving next quarter. Automating the version that is going away buys a migration, not a saving.
A quarterly task that takes an afternoon does not repay a build, an operating arrangement and the attention of keeping it correct. Say so early; it is cheaper than finding out in month three.
What starts the work, and how the system finds out. Almost every automation that fails in production fails here first.
Every place data is read from or written to, including the spreadsheet nobody mentions in the first conversation.
Each point where a person chooses, what they are choosing between, and what information they use to choose it.
Where work sits because it is queued behind a person, an approval or another system. Waiting is usually the largest number on the map and the one nobody has measured.
The awkward cases. One real exception tells you more about the process than ten clean examples, and the exception path is what decides whether the build is four weeks or twelve.
A useful automation has an explicit uncertainty path: below a confidence threshold, the item queues for a person rather than proceeding on a guess. If nobody has decided what that threshold is, the system does not yet have one.
Anything where a wrong answer carries a material consequence: money leaving, a commitment made to a customer, a record a regulator will ask about. Approval gates are a design decision, not a fallback.
An upstream system will be unavailable at some point. The question is whether the work waits safely and resumes, or is silently lost, and that is answered when the system is built rather than when it happens.
It should be, for as long as the new one has not proven itself on real volume. A cutover with no way back is a decision you only get to make once.
A named response path, agreed before launch. If the answer is "the operations manager notices in the morning", the system is not operated, it is merely deployed.
No baseline was captured on this engagement.
No baseline was captured on this engagement.
No baseline was captured on this engagement.
No baseline was captured on this engagement.
Bring one process and roughly what it costs today. If the answer is that it should be left alone, that is the answer you get.