Five questions I ask before automating a process

When a business starts discussing AI, I would rather begin with a sentence than a product:

Our team struggles with this task because…

Until we can complete that sentence clearly, I would hesitate to suggest an assistant or an automation. We have not yet agreed on what needs to change.

As I develop my AI skills, this is where I want to apply my project and operations background: understanding the work before deciding how technology should support it.

1. What is the actual problem?

Take a weekly report. The initial request might be, “Preparing it takes too long.” Which part takes too long? Collecting information, matching records from different files, asking people for missing updates or writing a clear summary?

Those are different problems. Giving a team a better writing tool may not help if most of the delay comes from waiting for information.

Whenever possible, I would ask someone to walk me through a real example. Hearing a description of a process is useful. Seeing where someone has to stop, check or chase information gives me a more practical starting point. The moment they say, “I need to ask someone about this,” matters as much as the application they use.

2. Which steps follow rules, and which need interpretation?

Creating a reminder when a due date passes is different from interpreting an unclear customer request.

Where the rules can be defined clearly, I would first consider conventional automation. Where interpretation is needed, I would explore an AI-assisted step with an appropriate review process.

I do not want to add AI to every part of a workflow. In some projects, it may support one small step. In others, it may not be necessary. My preference is to choose a method that fits the work, rather than one that makes the prototype look more impressive.

3. What information will the system use?

I want to know where an output comes from. Is the source current? Are there competing versions of the same record? Which source does the process owner consider authoritative?

Before development, I would separate the information the tool needs from the information it does not need. “Connect everything” would not be my default approach.

If a status summary only requires an owner, a last update and open actions, I would not add unrelated employee or customer information to that flow. A well-written summary does not make outdated source information reliable.

4. What happens when the output is wrong?

I want to discuss this at the beginning, not after the prototype is built. An incorrect suggestion in a draft and an incorrect delivery commitment sent to a customer have different consequences.

The first version should distinguish between actions the system can complete and actions that require approval. My preferred starting point is often: the system prepares, a person reviews, and then the action is completed.

The reviewer also needs to know what to check. Rather than provide only an approval button, I would want to show the source record, the proposed change and any missing information.

That does not mean every step must remain manual forever. It means deciding what can be delegated based on the task and evidence from actual use.

5. How will we know it helped?

“We added AI” is not a useful success criterion for me. For the report example, a pilot might examine preparation time, corrections and records returned because information was missing. Another workflow may need entirely different measures.

I would agree on the starting position and the intended improvement before testing the solution. Otherwise, it is easy to confuse liking the tool with finding it useful.

If the first test does not produce the expected result, I would revisit the assumptions. Did we describe the problem accurately? Did we automate the wrong step? Did we add a review burden to something the user already found easy?

This is the capability I am working to build: understanding a business need, designing a practical response and applying technology where it belongs. Not searching for a problem to fit a tool.

Your experience: Think of a task you would like to automate. Which part takes the most effort: collecting information, following up, making a decision or communicating the result?