The first question in an automation project is often: “Which tool should we use?” I would start somewhere else: “What should this process actually do?”

That distinction matters. A workflow can move faster while preserving the same unclear responsibilities, missing information and unnecessary approvals. Speed is useful. But speed alone is not transformation.

A faster handoff is still a handoff.

Consider an illustrative billing workflow. A request arrives by email. Someone copies the information into a spreadsheet. Another person checks it, asks for missing details and passes it to the person issuing the invoice.

It is tempting to connect the inbox to the spreadsheet and automatically generate the next task. That may save copying time. Yet if nobody has defined what makes a request complete, the workflow will still send incomplete work downstream — just sooner.

The better starting point is to clarify the minimum information needed, the point at which it must be available, and who owns exceptions. Only then does choosing an automation become a meaningful design decision.

Five questions before choosing the technology.

1. What outcome are we trying to improve? Faster invoicing, fewer corrections and clearer status are different objectives. Choose one primary outcome.
2. Where does the process really begin and end? Look across teams. Improving one task can move the burden to the next person.
3. Who owns the decision? A notification is not accountability. Define who can approve, reject or resolve an exception.
4. Which steps are necessary? Remove duplication and obsolete controls before encoding them in a workflow.
5. How will we know it works? Establish a baseline and a simple measure, such as elapsed time, correction rate or manual touches.

Start with one workflow. Design for the whole.

A useful first pilot is narrow enough to understand and important enough to matter. Map the current flow, review a few real cases, and identify the decisions that repeatedly interrupt it.

Then define the future flow in plain language. Separate the standard path from exceptions. Decide which actions can run automatically and which need human judgment. Test the design on a small sample before extending it.

The tool may be an existing system, a simple integration or an AI-enabled workflow. The choice should follow the problem, the quality of the information and the level of control required.

Before making the process faster, make its logic clearer.

A question worth taking back to your team.

If you removed the technology from the conversation for twenty minutes, could everyone still agree on the outcome, the owner and the next step?

If the answer is no, that conversation may be your most valuable first automation investment.

This Perspective presents a practical approach to process design. The billing workflow is an illustrative example, not a client case study.