Start with the process, not the tool

Every automation request I receive arrives already named after a product. Almost none of them turn out to be about the product.

Every automation request I receive arrives already named after a product. Can we build a Power Automate flow for this. Could a bot handle it. Would Copilot work here. The tool is in the sentence before anyone has described what is actually going wrong.

I understand the instinct. Naming a tool makes a request sound like a decision has been made, and it moves the conversation from a vague complaint to something that looks like a project. But it also quietly settles a question nobody has asked yet: whether this work should be done at all, in this shape, by anyone.

The request is rarely the problem

When I walk a process with the people who run it, the request and the problem usually turn out to be different things. Someone asks for automation on a step that takes four minutes. Sitting with them, the four minutes are not the issue. The issue is that the step happens three days after the information was available, because it waits on a file that arrives on a schedule set years ago by a system that has since been replaced.

Automating that step makes it a fast step that still starts three days late. The elapsed time barely moves. The person who asked gets what they asked for and does not get what they wanted.

This is why I start every piece of work in the same place: what does this process actually look like today, not on paper, but on a Tuesday.

The questions I ask before any tool is mentioned

• Who starts this, what triggers them, and how do they know it is time?
• Where does the work wait? Not where is it slow, where does it sit still?
• Which steps make a decision, and which steps only move data from one place to another?
• What happens when it goes wrong, and how often is that?
• If we stopped doing this step entirely, who would notice, and when?

That last question is the useful one, and it is the one people find uncomfortable. In a shared services environment I have found steps that survived because a report was requested once, by someone who has since changed roles, and nobody was ever told to stop producing it. Nothing was wrong with the step. It was simply answering a question no one was asking any more.

Automating a step you should have deleted is the most expensive way to keep it.

Waiting is where the time goes

Lean training gave me language for something I had already seen from the IT side for years. When you map a process end to end and separate the time spent working on it from the time it spends waiting, the waiting almost always dominates. People are surprised by this, because the work feels like the hard part. The work is the visible part.

Automation is very good at compressing the working time. It does far less to the waiting time unless you deliberately go after the handoffs, the approvals, the batch schedules and the queues. If you automate without mapping, you optimise the small number and leave the big one alone.

When the tool question finally matters

Eventually it does matter, and by then it is a much easier question. Once you know the process, the choice mostly answers itself. A structured approval that lives inside Microsoft 365 is a Power Automate flow. A form that needs to be filled in the field with validation and offline behaviour is a Power App. A screen-driven task in an application with no usable interface is where RPA earns its licence cost. Something that needs to reconcile two systems on a schedule with real error handling may be better served by a script than by dragging boxes around a canvas.

None of that is a hard rule. But notice the shape: the process characteristics chose the tool. Not the other way round.

What this costs, and what it saves

Starting with the process costs time up front, and it is time that feels unproductive to a stakeholder who wants to see something built. Sitting in a room mapping a workflow does not look like progress. I have learned to be honest about this at the start rather than apologise for it later.

What it buys is that you build fewer things, and the things you build survive. An automation designed around a process that was never examined tends to break the first time the business changes, because it encoded assumptions nobody wrote down. An automation built after redesign has fewer moving parts, because there are fewer steps left to move.

The practical version: before you open a development tool, be able to draw the process on one page, mark where it waits, and name at least one step you are going to remove rather than automate. If you cannot do that, you are not ready to build.