How Do I Find Workflow Gaps by Watching What People Do, Not What They Say?

Ask a team where work gets stuck and you’ll often hear, “It’s fine,” “We just need better communication,” or “The tool is the problem.” Then watch someone complete a routine task. They copy details from an email into a spreadsheet, message a colleague to confirm a number, update a project board, and later discover the invoice still has the old information.

That gap between what people say and what they actually do is where useful workflow observation begins. It is also where strong problem discovery happens: not in a perfect process diagram, but in the extra steps, repeated checks, and quiet workarounds people use to get through the day.

For service businesses, especially agencies and productized service teams, those small inefficiencies can quietly reduce margins. A few minutes of manual effort multiplied across clients, projects, and staff becomes real delivery cost. The goal is not to catch people doing something wrong. It is to understand why the current process makes the workaround feel necessary.

Why People’s Workarounds Tell You More Than Their Opinions

People describe work from memory, and memory tends to smooth over friction. They remember the general process, not every time they searched an inbox, chased an approval, or retyped information. They may also avoid mentioning a workaround because it feels unofficial, embarrassing, or simply too normal to notice.

But workarounds are evidence. They show where the documented process fails to match the conditions of real work. A team member who keeps a private spreadsheet may be compensating for missing visibility. Someone who sends an invoice draft to a colleague before entering it into the billing system may be filling a quality-control gap. A project manager who forwards an email thread into a task tool may be trying to preserve context that the task record does not capture.

The workaround itself is not automatically the problem. It may be an intelligent response to a genuine Get more information constraint. The problem is that the workaround can become invisible infrastructure: essential to getting work done, but unsupported, inconsistent, and dependent on one person remembering every step.

Frustration Is the Seed of Durable Businesses

Many durable businesses begin with a recurring frustration that people have learned to tolerate. The founder notices a task that is unnecessarily slow, error-prone, or confusing, and builds a better way to handle it. That same pattern applies inside an agency. Repeated frustration can point toward a service improvement, an operational fix, or a productized offer.

To find a worthwhile opportunity, look beyond whether someone dislikes a task. Ask what the frustration costs and how often it occurs. Does it delay client delivery? Create billing errors? Require senior staff to review routine work? Make onboarding unpredictable? A complaint becomes a stronger candidate for problem discovery when it connects to a repeated business outcome.

There is a useful distinction between a one-time annoyance and a durable pain point:

What you observe What it may indicate What to investigate One person dislikes a particular tool A preference or usability issue Does the task fail for others, too? Several people maintain separate tracking sheets A visibility or ownership gap Which information is missing from the shared system? Invoices are repeatedly corrected after sending A handoff, data, or approval problem Where are invoice details first captured and verified? Staff regularly chase updates by email Status is hard to see or trust What event should update the status, and who owns it?

Frustration becomes especially valuable when it points to a repeatable pattern. If the same fix is needed for every new client, every monthly invoice, or every campaign launch, you may have found more than an isolated irritation. You may have found an opportunity to standardize delivery or design a productized service around a real need.

Watch the Work, Not Just the Workflow Diagram

Process diagrams show how a workflow is supposed to run. Observation shows how it runs under everyday conditions: interruptions, incomplete information, urgent client messages, and overlapping deadlines. In practice, both perspectives matter. The diagram gives you the intended route; watching real work reveals the detours.

Choose a common task with clear boundaries, such as turning a signed proposal into a project setup and first invoice. Ask the person doing the work to carry it out as usual, using their usual tools. Do not ask them to demonstrate the ideal process. If they skip a step because they believe you expect them to, you lose the evidence you came to collect.

During the observation, pay attention to:

Where information first appears, and where it is copied next.
How many times someone switches between email, project management, documents, and billing tools.
Where they pause to search, confirm, or wait for another person.
What they record outside the official system, including notes, spreadsheets, and personal reminders.
Which decisions depend on experience or memory rather than a visible rule.
What happens when an input is missing, late, or incorrect.

Ask neutral questions while they work: “What are you checking here?” “What would happen if that detail were missing?” “Where would you look for the latest version?” Avoid questions like “Why don’t you just automate this?” They imply that the person has failed to notice an obvious solution, when the actual constraint may be a client exception, a tool limitation, or an approval requirement.

Follow One Piece of Work Across the Handoffs

A workflow gap often appears between roles or systems rather than within one person’s task. Following a real piece of work from start to finish makes those gaps easier to see. In an agency, that might mean tracing a client request from an email through scoping, delivery, approval, and invoicing.

Start with a real example. Select a recent project or invoice rather than asking someone to reconstruct a typical process from memory.
Trace the information. Note where the client name, scope, rates, dates, approvals, and billing details originate and where they are entered again.
Identify every handoff. Record who passes work to whom, what they pass along, and how the next person knows it is ready.
Look for unofficial signals. Is an email considered approval? Does a chat message mean a task can start? Are people relying on a calendar reminder because the system sends no alert?
Compare the outcome with the intended process. Mark where the work departed from the documented route and what triggered the change.

Email is especially useful to examine because it often becomes a shadow workflow. Decisions, approvals, attachments, and changes may live in an inbox while the official project record contains only a brief status update. The team may appear to have a project system, yet still rely on email to know what is true.

Invoices offer another clear lens. They are a downstream test of whether earlier information was captured accurately. If invoice creation requires someone to compare a proposal, time records, project notes, and a client email, the issue may not be “slow invoicing.” The deeper gap may be that scope changes, approvals, or billing terms were never recorded in one dependable place.

Recognize Tool Sprawl and Patchwork Workflows

Tool sprawl is not simply having a lot of software. A team can use several tools effectively when each has a clear role and information moves reliably between them. Patchwork appears when people must manually bridge the tools: copying data, reconciling conflicting versions, or asking colleagues which record to trust.

During workflow observation, map the movement of information rather than making a list of subscriptions. For example:

A client sends a request by email.
An account lead copies the request into a project board.
A delivery lead re-enters scope details in a work document.
Finance checks the original email to prepare the invoice.

Each transfer creates a chance for delay, omission, or mismatch. The goal is not to force every task into one platform. It is to decide what information needs a reliable home, what system owns the current status, and which handoffs should be explicit.

Separate Necessary Exceptions from Accidental Complexity

Not every variation is waste. A premium client may have a different approval path for good reasons. A rush project may need a legitimate exception. The important question is whether the exception is visible, understood, and repeatable—or whether it depends on someone remembering a private rule.

Write down exceptions as they occur. If the same variation appears repeatedly, decide whether it belongs in the standard workflow, a defined service tier, or a clear exception policy. This is one way to turn operational complexity into a product decision rather than allowing every client engagement to become a custom process.

Account for Agency Operations and Productized Services Pressure

Agencies feel workflow friction sharply because time is both a delivery input and a major cost. A small amount of coordination work can erode the margin on a fixed-fee engagement. When the offer is productized, the pressure is greater: the promise depends on predictable scope, repeatable delivery, and clear boundaries.

Observation helps test whether a service is genuinely repeatable. If every project requires the team to reinterpret the brief, rebuild the task list, chase the same approvals, or manually reconcile the invoice, the delivery model may be carrying hidden custom work. That does not mean the service cannot be productized. It means the repeatable parts and the exceptions need to be distinguished.

Look for signals such as:

Senior staff repeatedly resolving routine handoff questions.
Delivery teams starting work before scope or approval is clear.
Project status being rebuilt in meetings because tools are out of date.
Invoices needing manual interpretation of work completed.
Different team members using different definitions of “ready” or “done.”

These are not simply efficiency issues. They affect what the agency can promise, how many clients it can serve, and whether work can be delivered consistently without adding more coordination overhead.

AI Is Raising Expectations Faster Than Workflows Can Keep Up

AI-driven tools have changed what teams expect from routine work. People now assume that information can be summarized, routed, drafted, and updated quickly. This expectation can be helpful, but it can also create pressure to automate a workflow before anyone understands it.

Automation does not remove ambiguity. If an email contains a vague request, an AI system may classify it quickly but still leave the team unsure about scope. If invoice data is inconsistent, automation can move the inconsistency faster. If approvals are informal, a tool cannot reliably infer when work is authorized without a clear rule and trustworthy source.

Use observation to identify tasks where AI or automation might help, then check whether the inputs and decisions are stable enough. Good candidates often include repetitive extraction, summarization, reminders, and routing—provided a person can review exceptions. Before automating, ask:

Is the information available in a dependable format?
Can the team explain the decision rule in plain language?
What happens when the system is uncertain or the request is unusual?
Who owns checking the result, especially for client-facing details and invoices?

The aim is not to avoid AI. It is to avoid automating a patchwork process and then mistaking faster movement for better operations.

Turn Observation into Problem Discovery

Good observation generates clues. Structured problem discovery turns those clues into a useful decision. After watching a workflow, summarize the friction without jumping immediately to a software recommendation.

A practical problem statement might read: “When a client changes scope by email, the delivery lead updates the task board, but billing does not receive a reliable signal. Finance checks several records before invoicing, which delays billing and creates correction work.” This is more actionable than “We need to integrate our tools,” because it identifies the event, the handoff, and the consequence.

Then estimate the pattern. How often does it happen? How many people are involved? What does the delay or rework affect? You do not need a perfect time study at the start. A few observed cases, paired with examples from recent work, can help distinguish a recurring system issue from one unusual project.

A Simple Field Guide for Your Next Observation

Pick one workflow. Start with a frequent, consequential task such as onboarding, scope changes, approvals, or invoicing.
Watch multiple examples. Include different people or clients so you can see what is consistent and what is exceptional.
Record actions, not judgments. Note the copy, search, wait, message, check, and re-entry steps without labeling them wasteful in advance.
Ask what the workaround protects. A manual check may be preventing an error. Understand its purpose before removing it.
Find the underlying gap. Look for missing ownership, unclear rules, unreliable status, scattered information, or unnecessary duplication.
Test a small change. Clarify one handoff or establish one trusted source of information before redesigning the entire system.
Measure the result. Track whether rework, delays, corrections, or follow-up messages actually decrease.

Fix the Friction People Have Learned to Live With

To find workflow gaps, do not rely only https://instaquoteapp.com/how-do-i-find-workflow-gaps-by-watching-what-people-do-not-what-they-say/ on interviews, process maps, or software audits. Watch real work unfold. Notice what people copy, where they pause, which email they search, and what they track outside the official system. Those behaviors show you where the intended workflow and the practical workflow have diverged.

Approach workarounds with curiosity. They are often the team’s best attempt to compensate for a missing capability, unclear rule, or broken handoff. When you understand the frustration behind them, you can decide whether to improve the process, adjust the service design, connect tools, or leave a useful exception intact.

That is the practical value of workflow observation: it turns everyday friction into evidence. And when you use that evidence for disciplined problem discovery, you can build operations—and, sometimes, durable services—around problems people genuinely need solved.