Review the workflow before you automate it.

Automation is most useful when it reduces repeat work while keeping responsibility clear. That sounds obvious, but many projects begin with a product demo or a request to “use AI” before anyone has described the process it should improve.

A short workflow review gives the business a better starting point. It shows where time is going, which steps follow rules, where judgement is needed, and what a useful result would look like.

Name the outcome first

Ask what should be better when the work is finished. Is the goal faster response, fewer errors, less copying, clearer reporting, a better customer handoff, or more time for a specialist team? One workflow can have several benefits, but a first project needs a primary outcome.

Follow the work from trigger to finish

Write down what starts the process, every handoff, every decision, and the point where the work is considered complete. Include the informal steps people take because the official process does not cover a common situation.

• What starts the work?
• What information arrives with it?
• Who makes each important decision?
• Where does the work wait?
• What tells the team that it is complete?

Separate rules from judgement

Some steps are predictable: checking a field, routing a request, creating a task, or sending a reminder. Other steps need context and experience. Keep the distinction visible so the future workflow can automate repeatable work and give people the right information for decisions that should stay human.

Look at the exceptions

Normal cases are easy to describe. Exceptions are where projects become difficult. Ask what happens when information is missing, the request is unusual, a customer disagrees, a supplier changes a detail, or the result does not meet the expected standard.

Check the data and ownership

Automation needs reliable inputs and a person who can answer when the process changes. Review where the data lives, who can access it, how long it should be kept, and who will own the workflow after launch.

Choose the smallest useful first change

A good first project is large enough to matter and small enough to learn from. Start with a defined workflow, a clear owner, a visible measure, and a way to pause or review the result when the process reaches an exception.