Workflow automation: choosing the first process

It is usually the one someone complains about loudest. That is the one with the most judgment in it, the most exceptions, and the most stakeholders with opinions.

Specific things to avoid first:

• Anything requiring a decision a person would defend. Approvals, pricing exceptions, credit calls, hiring screens. These can be supported by automation later. They cannot be owned by it now.
• Anything touching a system with no owner. If nobody can grant you access or answer questions about its data, the project will stall waiting for a person who does not exist.
• Anything with legal or financial exposure. Payroll, tax, regulated reporting. The failure cost is too high for a first build.
• Anything that changes every quarter. A process whose rules are rewritten regularly will consume more maintenance than it returns.
• The biggest one. Scope grows during discovery, not shrinks. A large first project is a long project, and a long project loses its sponsor.

Score your candidates honestly. The best first process is usually unglamorous.

A candidate passing all four is worth building even if the hours saved look modest. A candidate failing determinism is not ready regardless of how much time it consumes.

The strongest first candidates tend to look like this: data entered in one system that someone copies into another; a notification that someone sends manually after checking a status; a recurring report assembled by hand from two sources; a record created in a CRM after a form arrives somewhere else.

You cannot automate what you cannot describe. Do this with the people who actually do the work, not with their manager.

1. Watch it happen once, in full. Screen share, no interruptions, no explaining. Record it if they consent. You will see steps nobody mentions because they are too obvious to say out loud.
2. Write the steps in order, with the system used at each one. Including the ones that are just reading a screen.
3. Mark every decision point and write the actual rule. Not the official rule. The one applied in practice. These differ more often than anyone expects.
4. Count the exceptions. Ask what happened the last five times it went differently. If exceptions are more than roughly one in five, the process is not stable enough yet.
5. Identify the system of record for each piece of data. Where does the true value live. If two systems disagree, which wins. This question causes more rework than any other when left unanswered.
6. Time it. Per run, honestly. Multiply by frequency. Now you have a number to compare against build and maintenance cost.
7. Note what the person does that is not in the process. Often they catch errors, or chase someone, or apply context. If automation removes that, you have moved a problem rather than solved it.

Step seven is the one most often missed. Manual processes frequently contain informal quality control, and it is invisible until it is gone.

Draw the line explicitly and write it down. Three categories:

Owns. The automation executes and does not ask. Deterministic steps with clear rules and low reversal cost.

Proposes. The automation does the work and a person approves. Use this for anything where the cost of being wrong is meaningful but the work is repetitive. It is also the right way to earn trust in the first weeks: run in propose mode, let a person approve, then promote to owned once the approval becomes a formality.

Escalates. The automation stops and hands over, with everything it knows attached. Every unmatched case, every exception, every ambiguity.

Most first builds should be mostly propose. Resist the pressure to go fully autonomous immediately. Propose mode generates the evidence you need to justify the next phase.

1. Confirm access before anything else. API credentials, permissions, rate limits, test environments. This is the most common source of delay, and it is almost always an organizational problem rather than a technical one. Start it on day one.
2. Build the unhappy path first. What happens when the source system is down, the data is malformed, the record already exists, the field is empty. Build this before the happy path and the project will be shorter overall.
3. Make it idempotent. Running the same step twice must not create two records or send two messages. Assume it will run twice, because it will.
4. Run it alongside the manual process. Both in parallel for a cycle. Compare outputs. Every difference is either a bug or an undocumented rule, and both are worth finding now.
5. Switch over with the manual path still documented. Not deleted. Documented, with a named person who knows how to run it.
6. Watch it for two weeks with someone accountable. Daily, not weekly. Early failures cluster.

An automation nobody can see is worse than no automation, because people assume it is working.

• Log every run. What triggered it, what it did, what it decided, what it skipped. Keep it for long enough to investigate a complaint from last month.
• Make failure loud and addressed to a person. Not an email to a shared mailbox. A named owner, in a channel they read.
• Monitor for silence too. An automation that stops running does not generate errors. Alert on absence, not only on failure.
• Track the escalation queue. Items routed to humans need to be picked up. An escalation that sits for three days is a worse outcome than the manual process it replaced.
• Keep the manual fallback current. Review it when the process changes. An out-of-date fallback is discovered during the outage.

Access takes longer than the build. Start the credentials conversation before scoping, not after.

Undocumented rules surface during parallel running. This is the system working. Budget time for it rather than treating it as a surprise.

The process changes mid-build. Agree a freeze with the process owner, or accept rework.

Nobody owns it after handover. Automation without a named owner degrades quietly. Name the person in the project plan, not at the end.

Success is measured in hours saved and nothing else. Error rate, cycle time and consistency often matter more to the business than the headcount arithmetic, and they are easier to evidence honestly.

The second project is scoped before the first is stable. Give the first one a month of real operation before expanding.

This normally starts as a two-week mapping exercise rather than a build: watch the work, write the steps, find the systems of record, score three or four candidates against the four tests. That often surfaces that the real constraint is systems that do not talk to each other, which moves the work into systems integration before any workflow logic gets built. Where the process is clear and the access exists, it goes directly into AI and workflow automation as a single scoped build with propose mode first.

Agree what better means before the work starts. Hours returned, errors avoided, or cycle time reduced. Pick one as primary, because they lead to different designs.