What should you investigate before automating a business process?
Investigate what starts the work, why the step exists, who needs its output, which information and decisions it requires, and what happens when the normal route fails. Use a real case rather than only the official procedure. The difference between intended and actual work can reveal a missing input, unclear authority, or a workaround that keeps the service functioning.
A company can become faster at work it keeps creating unnecessarily. An employee requests a missing document. Another checks the current version. A manager approves a routine item because nobody has agreed where the team's authority ends. Software can accelerate each exchange while the same uncertainty continues to circulate.
The recurring task is visible. Its cause may sit in another department or an earlier customer touchpoint. That is why the first useful conversation often includes the person doing the work, the person supplying its inputs, and the person receiving the result.
In an illustrative construction business with $10 million in revenue, an estimator repeatedly asks sales to clarify drawings. Revenue does not explain the cause. The relevant questions concern which drawing reached estimating, what revision applied, and who was responsible for confirming it. An automated chase might send the same unresolved question faster.
How do you distinguish a root cause from a plausible explanation?
Describe the observed event, collect supporting records, and test explanations against what happened. Ask which evidence would distinguish competing causes. A questioning method can help you look beneath symptoms, but a persuasive sequence of answers does not establish causation. Several conditions may contribute to the same repeated task.
ASQ's Five Whys guidance provides a method for asking beyond the first symptom. Pair those questions with the actual request, instructions, records, and people involved.
Consider an illustrative quote that returns to sales for more information. The customer may never have received the document instructions. The product may still be undecided. Or sales may already hold the information in a record the quoting team cannot access.
These are different problems. A reminder can repeat an unclear instruction, demand a decision the customer cannot yet make, or ask for something already supplied. Calling all three “incomplete requests” hides the decision about where to intervene.
People's workarounds deserve the same curiosity. A spreadsheet may exist because the approved system does not preserve the current scope. Removing it without understanding its job can remove the record people were using to deliver the service.
When should you improve information or authority instead of adding automation?
Improve information when people cannot find or understand an answer they need. Clarify authority when routine decisions return because nobody knows who may make them. Consider integration when confirmed information must move between systems. Automation becomes a stronger candidate when the task, inputs, decision boundaries, and failure route are understood.
| Observed situation | A question that changes the brief |
|---|---|
| Customers ask whether a service is included | Where should that boundary be explained before inquiry? |
| The same file is requested repeatedly | Does the company already have it, and can the next person find it? |
| Every routine quote needs the owner | Which knowledge or decision authority is missing? |
| Confirmed data is copied between tools | Can a controlled transfer preserve its source and state? |
An illustrative accounting firm might improve document instructions before building an automated chase sequence. A design studio might clarify which selection authorizes purchasing before adding approval reminders. Those interventions concern how work begins and how decisions travel, not simply the speed of the task at the end.
Sometimes the existing step is valuable. A human review may protect an unfamiliar commitment. A conversation may help the client discover what they need. The investigation should identify which part creates understanding or control and which part compensates for a gap elsewhere.
What should a useful automation brief include?
A useful brief states the user and task, input sources, expected output, decision limits, exceptions, owner, failure route, and evidence for success. Record the problem and the explanation being tested as well as the proposed implementation. This gives the team a way to evaluate the solution when real work differs from the demonstration.
A NATA Intervention Decision Record captures the observation, supporting evidence, alternative explanations, options considered, bounded change, and review condition. It applies NATA's Notice. Ask. Think. Act. sequence to a decision someone can inspect.
The record should answer ordinary operating questions. What may the system send without review? What must remain unresolved? Who receives an exception? What happens when an input is missing or a transfer fails?
A technically correct reminder can still interrupt a conversation already taking place. A polished draft can make an uncertain record look settled. Those are business design questions to resolve before increasing volume.
How do you test whether the automation improved the whole experience?
Trial the change on defined cases and compare the original difficulty, total effort, waiting, correction, and outcome quality. Include the customer and the teams before and after the automated step. A faster task is not enough if it creates more form-filling, cleanup, or uncertainty elsewhere.
State what would support keeping the change and what would cause concern. Then return to those conditions rather than treating a successful system run as the result.
For employees, ask whether the change provides better information or adds another system to maintain. For customers, check whether it helps them understand and act. Every additional request, reminder, and handoff becomes part of the experience of the brand.
Complete certainty is rarely available before acting. A bounded trial makes it possible to learn without pretending the diagnosis is finished. Keep the original reasoning so a later business change can be connected to the part of the system that depends on it.
The recurring task may identify useful work for automation. It may also point to an earlier decision the company has never made clearly. Finding that distinction is part of doing the implementation well.
Frequently asked questions
Should every repetitive task be automated?
Repetition identifies a task worth examining, not an automatic implementation decision. Check whether it should be prevented, clarified, retained for judgment, or automated with an appropriate exception route.
Is root-cause analysis a reason to delay implementation indefinitely?
No. Define the observed problem, working explanation, trial boundary, and review conditions. Gather enough evidence to make that bounded decision, then learn from the actual work rather than waiting for a complete model of the company.
How should you measure the financial benefit?
Separate released capacity, lower spending, and additional revenue. Measure the remaining work and what the released capacity enabled. Do not turn every hour removed from a task into payroll savings or sales without evidence of that business effect.
Sources and case basis
ASQ's linked Five Whys guidance supports the questioning method. The intervention record and Notice. Ask. Think. Act. application describe NATA's working approach, not an independently validated assessment. Construction, accounting, quoting, and design situations are illustrative; no client outcomes or industry benchmarks are claimed. Prepared and revised November 4, 2026.