Before You Automate: 7 Questions to Ask About the Workflow First

A client asks to automate their quoting process. The request is specific, the frustration is real, and there is usually a tool already in mind.

That request tells you what solution they are considering. It does not yet tell you what is wrong with the workflow.

Before choosing technology, the workflow itself needs to be understood. Delay, rework and frustration are outcomes, and they can be produced by very different underlying causes:

• unclear ownership of a stage
• weak handoffs between people or teams
• missing information at the point work is picked up
• inconsistent process standards
• duplicate work across systems
• fragmented systems that do not share data
• uncontrolled exceptions that bypass the normal path

Automation may well be appropriate. Diagnosis simply comes first, because the same symptom can justify very different responses.

1. What problem are we actually trying to solve?

There are three different statements in play at the start of most engagements, and they are easy to collapse into one.

“We need automation” is a proposed remedy. It becomes a diagnosis only once the operational problem behind it is named, located in a specific stage, and supported by what people actually described.

2. Where does the workflow actually break down?

Map the workflow stage by stage and look for where work stops moving rather than where it feels busiest. In practice, friction shows up as:

• delays between stages rather than inside them
• bottlenecks at a single person or approval point
• rework caused by work returning upstream
• waiting on information, a decision or a system
• manual checks added to compensate for earlier problems
• missed handoffs where nobody has picked the work up
• stalled work that is technically open but not progressing

The highest-friction point is often not where the client first points. Teams tend to name the stage where the pressure lands, which is usually downstream of the stage where the problem was created.

3. Who owns each stage?

Ownership questions are unglamorous and frequently decisive. For each stage, ask who is responsible for moving the work forward, who approves it, what happens when it stalls, and who is accountable for the outcome.

• unclear responsibility, where several people could act and nobody does
• approvals with no named approver or no deputy
• accountability that sits with a team rather than a role
• escalation paths that exist informally or not at all
• stage ownership that changes depending on the customer or job type

Ownership gaps create delay without any technical cause. Work waits because no one is answerable for it. Automating around that gap can hide it — the queue moves faster, but the decision still has no owner.

4. What information is missing at handoffs?

Handoffs are where most workflows lose time. The question is not whether a handoff happens, but whether the receiving team gets what it needs to act.

• incomplete inputs that force the next stage to chase
• inconsistent formats between people, teams or systems
• missing context about what was agreed or why
• repeated clarification through calls, messages and email threads
• information recreated by the next team because it was not captured once

5. What work is duplicated or repeated?

Duplicated work is easy to observe and useful to quantify, because people can usually describe it precisely.

• the same data entered into more than one system
• copying between tools to keep records aligned
• spreadsheets maintained alongside a system of record
• repeated checks performed because earlier stages are not trusted
• manual reconciliation at month end or job close

Some of this is a genuine automation opportunity: stable, rule-based, high-volume copying is exactly what integration handles well. Some of it is a signal of something deeper — a process that has no single source of truth, or a system design that never carried the data the business actually needs. The distinction matters, because automating the second kind embeds the problem.

6. Is the workflow stable enough to automate?

Reliable automation depends on predictable rules and predictable inputs. Before committing, test how stable the workflow really is:

• The steps run in the same order for most cases.
• Exceptions are known, named and handled in a defined way.
• There are clear rules for when a stage is complete.
• Inputs arrive in a consistent form.
• Manual judgement is required only at defined decision points.

Do not automate an undefined workflow.

This is not an argument against automation. It is an argument about sequence. Where a workflow is stable, automation removes effort and variation. Where it is not, standardising the steps and defining the exceptions first is usually what makes the later automation worth building.

7. What should change first?

A useful assessment does not stop at a list of problems. It produces a sequence: what to change now, what follows, and what should wait until the foundation is in place. Changes generally fall into recognisable categories:

• process change — altering how the work is done
• ownership — naming who is responsible and who approves
• standardisation — defining the steps, formats and completion rules
• integration — connecting systems that already hold the data
• automation — removing manual effort from a stable path
• reporting — making performance and status visible
• AI assistance — supporting judgement where rules cannot be fully defined

The decision that shapes the outcome is not “what can we automate?” It is “what should change first?” — and the answer is often ownership or standardisation, because those changes make the later technology decision cheaper and more likely to hold.

The diagnosis determines the decision

The quality of an implementation decision depends on the quality of the diagnosis that came before it. A workflow assessment should make the current process visible, separate symptoms from root causes, identify the evidence behind each finding, and clarify what should happen next.

With that in place, technology can be evaluated against a defined operational problem rather than a vague request. That is the sequence WorkflowMD is built around: diagnose the workflow, establish what is actually causing the delay, then decide what should change — and only then choose the tools.

Understand what should change before you automate it.