Understanding Existing Workflows and Finding Automation Opportunities

Before you build anything, you have to know precisely how the customer does the work today — the copy-pastes, the wait states, the spreadsheets holding it all together. This tutorial shows how to study the current workflow, draw it as a process map, and hunt for automation opportunities without breaking what already works.

Table of Contents

• Understanding Existing Workflows
• Why Study the Current Process
• Shadowing and Walking Through the Work
• Mapping Customer Processes
• How to Draw a Process Map
• Reading a Map for Pain
• Finding Automation Opportunities
• Signs a Step Is Automatable

Understanding Existing Workflows

A workflow is the ordered sequence of steps and decisions a person or team follows to finish a job. Understanding it means knowing each step, who does it, what tool they use, and how long it takes.

You can't reliably automate or replace a process you can't describe. And there's an extra trap: the documented process and the real one are usually different. The understanding has to come from what people actually do.

Why Study the Current Process

Three reasons make the current process worth studying even when it's being replaced:

1. The documented process is a fantasy. Someone wrote the ideal version for an audit years ago. The real flow — the one with the workarounds — is what you must automate around.
2. Workarounds are evidence of pain. A homemade spreadsheet exists because the official system failed. Every workaround is a map marker pointing at a problem.
3. You learn the vocabulary and data. The exact words and fields people use ("deal," "case," "order line") are the ones your build should speak.

Shadowing and Walking Through the Work

There are two strong ways to learn a workflow, and you'll usually use both:

• Shadowing — sit with the person while they do the task and ask "what are you doing now, and why?" You see the rhythm, the tab-switching, the copy-paste.
• Walkthrough — have them narrate one specific, recent instance end to end, from trigger to completion, stopping at every decision.

Best Practice: re-use the "last time" habit from the interviews tutorial — have them show you the real thing rather than describe the ideal. Ask to see the artifacts: the shared spreadsheet, the ticket, the approval email.

Mapping Customer Processes

A process map turns the workflow you learned into a visual sequence of steps, decisions, and handoffs. Once it's visible, everyone — you, the customer, engineers — can look at the same picture and argue about the same friction points instead of talking past each other.

Note: maps are for thinking, not for art. A whiteboard sketch or a simple diagram tool is enough. The value isn't the drawing; it's that the invisible process finally became discussable.

How to Draw a Process Map

Every map is built from the same few elements — steps, decisions, handoffs, waits — arranged in order. A simple text version for one job:

[New order received]
        |
        v
[Agent checks stock across 3 systems]   <-- 10 min, tab-hopping
        |
        v
[Order typed into the ERP by hand]      <-- pain: 15 min, typos, no audit
        |
        v
[Order confirmed -> confirmation emailed manually]

The steps to draw one:

1. Pick a single job to map ("process an order" — not "the whole company").
2. List the steps in the order they happen.
3. Mark the decisions, the rework loops, and the wait states.
4. Label each step with who does it, which tool, and roughly how long.
5. Walk the map back through the person who does the work and correct it.

Best Practice: stop when the map is accurate enough to reason about. Perfect maps never ship; useful maps get to the point and stay there.

Reading a Map for Pain

Once the map exists, scan it for five smells:

Each smell is a candidate problem. Handoffs and waits are almost always where hours leak; manual entry is where errors live.

Finding Automation Opportunities

The whole point of studying and mapping the workflow is to find steps worth automating. You're not automating everything — you're ranking the opportunities by what they save and what risk they carry.

Signs a Step Is Automatable

A step is a candidate when it matches any of these:

• Repetitive: the same exact action, over and over.
• Rule-based: a decision that never needs judgment — encode it.
• Data-moving: information transferred between systems (integration).
• Validation work: checking by hand what software could check.
• Scheduled: the same job at the same time each day or week.

Then rank the candidates. A good first automation hits the sweet spot: frequent × boring × low-risk-if-it-gets-wrong.

Best Practice: start with the frequent, rule-based, safe-to-automate steps and keep a human in the loop where a mistake is expensive or judgment is required. Automating the dispute-handling first would produce chaos; automating invoice entry first produces an easy, visible win.

Common Mistake: automating the whole process in one go. Good FDEs land step-shaped automations, prove each one with the customer, and expand outward. Customers adopt automation they can still supervise — and reject the black box that did everything overnight.