A recurring business problem often gets described as an automation problem because automation sounds like the obvious upgrade. But three very different problems can look similar from the outside:
Handoff problem
The work is mostly fine, but ownership, timing, or required information becomes unclear when it moves between people or systems.
Process problem
The steps themselves are inconsistent, unnecessary, incomplete, or depend too heavily on memory and improvisation.
Automation problem
The process is already understood and repeatable, but people are spending time performing predictable work software can do reliably.
Step 1
Start with the symptom, not the solution.
Write down what is actually making the work harder. Avoid diagnosing it too early.
The second version gives you something you can test. The first version has already chosen a tool before the problem is understood.
Step 2
Ask five questions.
Is the work itself clear?
If two capable people would perform the task in very different ways, you probably have a process problem before you have an automation problem.
Does the problem appear mainly when work changes hands?
Missing context, duplicate follow-up, unclear ownership, and “I thought they had it” are strong handoff signals.
Is the same decision being made over and over?
If people keep re-deciding a predictable rule, standardization may solve more than automation initially.
Is the repetitive part actually predictable?
Software is strongest when inputs, rules, and expected outputs are sufficiently clear. Ambiguity still needs judgment.
Can you tell whether the result is correct?
If nobody can verify the outcome, automating the task may simply make mistakes happen faster.
Decision table
Look for the pattern underneath the complaint.
| What you keep seeing | Likely problem | Smallest useful first step |
|---|---|---|
| “I thought someone else handled it.” | Handoff | Name one owner and define what must travel with the work. |
| The same task is done differently every time. | Process | Write the shortest usable standard and test it with real work. |
| People copy the same information between systems every day. | Automation | Automate one stable transfer with visible error handling. |
| Customers wait because nobody knows what happens next. | Handoff + process | Define the trigger, owner, and next state before adding software. |
| Staff repeatedly calculate, rename, sort, or validate predictable data. | Automation | Use deterministic software before asking AI to reason about it. |
| Errors keep recurring even after reminders. | Process | Change the system so the right action is easier than the wrong one. |
Three quick examples
The same symptom can lead to very different fixes.
Start with ownership.
If messages already arrive reliably but nobody owns the response until morning, fix the handoff first. Automation can help later with intake, routing, and alerts.
Stabilize the process.
If staff interpret order requirements differently, first clarify the required fields, checks, and exception path. Automating an unstable process preserves the instability.
Automate the repetition.
If the same clean data is copied, compared, calculated, and formatted every day, ordinary software may remove most of the effort without adding an AI decision-maker.
Do not automate yet
Automation is a multiplier. Make sure you like what it is multiplying.
- The desired outcome is still disputed.
- Ownership changes depending on who happens to be available.
- The inputs are incomplete or unreliable.
- Exceptions are more common than the normal case.
- Nobody can define what a correct result looks like.
- The proposed automation costs more attention than the problem currently does.
Five-minute worksheet
Describe the problem in one page.
Describe the observable problem.
Name the people or systems involved.
Those are candidates for standardization or automation.
Keep ambiguity visible instead of hiding it inside automation.
Pick one observable outcome before changing the system.
The smallest sensible next step
Do not ask “How much can we automate?” Ask “What is making this harder than it needs to be?”
Once the problem is clear, the right level of technology becomes much easier to choose.
Bring us the problem