Business process automation: map the work first

You want to automate a business process, and the first instinct is often to pick a tool. That is almost always the wrong order. What determines whether an automation succeeds is the quality of the map of the existing process: who does what, in what order, with which expectations and which exceptions. This article walks through a mapping workshop applied to the quote request process, from receiving the request to sending the response, and shows how to move from an "as-is" map to a "to-be" map without merely speeding up a broken way of working.

Why map before you connect

A poorly described process produces a poorly designed automation. If you plug a tool into a flow nobody has formalized, you encode the current approximations, shortcuts and blind spots into the system. The typical result: quotes go out faster, but with missing information, inconsistent follow-ups and exceptions handled outside the tool, therefore invisible.

Mapping serves three purposes. It creates a shared language between the people who live the process daily and those who will model it. It reveals invisible work, meaning everything nobody documents because "it's obvious." And it provides a decision basis: once the process is written down, you can tell what deserves automation from what deserves fixing first.

This is exactly what a serious audit should deliver before any tool proposal, as we detail in our article on what a useful automation audit delivers.

The mapping workshop: participants and format

The workshop takes one to two hours per process, with the people who actually do the work, not just their manager. For a quote request, that usually means the person who receives the request, the one who writes the quote, the one who validates it and, if possible, the one who handles follow-ups.

The format has four phases. First, reconstruct a recent request end to end, preferably one that went wrong: nominal cases hide the exceptions. Second, name the actors and the states. Third, for each transition, note what triggers the move to the next step and what can block it. Finally, collect expectations: what each actor expects from the previous step, and what they believe they owe the next one.

Take notes as a table rather than a narrative. A narrative flatters memory; a table exposes the gaps.

Describing actors and states

A state is a situation in which the case can sit for a while without any action being required. For a quote request, a minimal map might read: received, qualified, being priced, in validation, sent, followed up, accepted or lost.

Actors are roles, not people. "Sales," "pricing engineer," "management" work better than first names, because people change and roles stay. For each state, document three things: who is responsible, which system or medium holds the information at that moment, and which implicit deadline applies. That last point matters most: implicit deadlines ("we usually reply within a few days") are often the process's real contract, yet they appear nowhere.

This logic of tracking a case through its states appears in many contexts, as we explain for following an administrative case from start to finish.

The transition table and exit criteria

This is the workshop's central deliverable. For every move from one state to another, record the triggering event, the actor, a verifiable exit criterion and the known exceptions. Here is a hypothetical example for a services SME:

Transition	Trigger	Actor	Exit criterion	Frequent exception
Received → Qualified	Request arrived by email or form	Sales	Client identified, need understandable, volume estimated	Incomplete request: manual follow-up, often forgotten
Qualified → Pricing	Need validated	Sales	Brief sent to the engineer	Claimed urgency: qualification bypassed
Pricing → Validation	Pricing done	Engineer	Quote priced with margins checked	Missing cost data: quote suspended with no status
Validation → Sent	Internal approval	Management	Quote reviewed and approved	Approver absent: delay untracked
Sent → Followed up	No reply after deadline	Sales	Follow-up sent and logged	Follow-up done from memory, not documented
Sent → Accepted / Lost	Client's answer	Sales	Status updated in the system of reference	Status never updated after verbal acceptance

This table has a direct benefit: every exit criterion becomes a future application-level check. If "client identified" is the exit criterion for "received," then the automation must verify that condition before moving the case forward, rather than simply firing an action on a schedule.

Deciding on systems of reference

One question comes up at every transition: where does the truth live at that moment? For each state, designate a single system of reference. The priced quote lives in your pricing tool, the validation approval in your messaging or management tool, the case status in your CRM. If two systems both claim to hold the same information, you have a latent conflict, and automation will amplify it instead of resolving it.

This decision also shapes permissions. An email address inside a case file is not the same as a validated status in the reference tool. Likewise, on the tooling side, a transport connection, the vendor's authorization and proof that an operation actually happened are three different things: for example, access to a messaging API with the gmail.modify scope can also allow sending messages when you only intended drafts; restricting behavior to drafts therefore requires explicit application-level controls, as the Gmail scopes documentation makes clear. A Gmail label is not a permission boundary.

Measuring the cost of invisible work

Invisible work is the mental double-checking, the follow-ups done from memory, the back-and-forth to find information, the statuses never updated. It appears on no org chart, but it consumes hours every week. During the workshop, always ask: "how do you know it's time to follow up?" and "where do you note that it's done?" The silences are as instructive as the answers.

Quantifying this work helps, even roughly and hypothetically. If three people each spend, purely as an illustrative example, two hours a week finding or reconstructing the status of open quotes, that is six hours weekly, equivalent to roughly one working day per week spent compensating for the absence of a system of reference. That figure is not a statistic; it is an order of magnitude to validate in your own business, but it changes the conversation: you are no longer automating a task, you are removing a compensation mechanism.

Our article on automating repetitive tasks explains how to tell repetitive tasks that deserve automatic handling from those hiding a design problem.

As-is map, then to-be map: don't accelerate the mess

The most common temptation is to model the target directly, imagining the "ideal" process. The frequent result: you accelerate a defective path. A quote goes out faster, with the same missing information, and the client more quickly receives an answer they will have to ask you to correct.

The right sequence has two maps. The as-is map, as it actually exists, with its workarounds and exceptions. Then the to-be map, built by asking three questions about every transition: should this step exist? Can it be automatic, and under what condition? Who should remain human, and with what check? A step on the as-is map may disappear in the target, another may be split, a third may become automatic with human validation.

The to-be map must specify, for every automated transition, what happens on failure: retry, wait, escalate to a human. Managing retries and duplicates is not an implementation detail; it is part of the design, as we develop in workflow automation: manage retries and duplicates.

A worked example: a quote request, before and after

Consider a hypothetical example. A services SME receives a request by email. Today: the salesperson reads it, sometimes replies with questions, passes the need to the engineer orally, who prices it in a personal spreadsheet, sends the quote as a PDF by email, then follows up "when they think of it." An accepted quote is often not recorded anywhere except the sent folder.

As-is map: seven states, two of them with no clear owner (quote priced but not handed over, quote sent but with no status tracking). Three competing systems of reference: the salesperson's inbox, the engineer's spreadsheet, collective memory.

To-be map: the request arrives in a single channel with a case identifier. Qualification is a short form that blocks the next step until the fields needed for pricing are filled. Pricing happens in a shared space, validation is a logged action, sending generates a draft the salesperson checks before it goes out, and the case status updates automatically at every transition, with a scheduled follow-up in case of silence. Assisted quote generation can rely on controlled document extraction with human review of sensitive data, following the principles described in our article on document extraction and validation.

The difference is not speed: it is that every transition now has a verifiable exit criterion and a single system of reference. If you later consider adding a conversational agent to qualify inbound requests, the prior mapping will tell you precisely which decisions to delegate and which to keep human; our guide on building a first AI agent starts from the same principle: an exchange protocol like MCP carries context and tools, but does not choose your business rules or permissions for you.

An actionable procedure: run the workshop in half a day

Here is a concrete procedure to adapt to your context:

1. Gather the process's doers for two hours, with a facilitator who does not do the daily work.
2. Reconstruct two recent journeys: one nominal, one that failed or dragged.
3. List the states, then for each: owner, information medium, implicit deadline.
4. Build the transition table with trigger, actor, exit criterion and exceptions.
5. Designate one system of reference per state and note the conflicts.
6. Estimate the weekly time spent on invisible work, even roughly.
7. Draw the to-be map in three columns: remove, automate under condition, keep human with a check.
8. For every automated transition, write the failure behavior: retry, wait, escalate.
9. Have someone absent from the workshop review both maps: whatever they don't understand is a wording defect.
10. Set a review date after a few weeks of real operation to fix the map, not just the tool.

Limits and common mistakes

First mistake: mapping the official process instead of the real one. If people bypass a step, that is information, not misconduct. Second mistake: trying to be exhaustive on the first pass. A map covering the ten main transitions beats a perfect mapping that never gets finished. Third mistake: confusing "automatable" with "to be automated." A repetitive step that carries judgment may be better left human, with a simple automatic reminder.

Finally, the map is not a frozen document. Today's exceptions are tomorrow's rules: when the same exception keeps coming back, it must enter the to-be map, either as a rule or as a check.

Frequently asked questions

Should you map even a very simple process?

Yes, but briefly. Even a three-state process has exceptions and invisible work. A one-page map, with exit criteria and a system of reference per state, is quite enough and will spare you discovering the exceptions after go-live.

Who should take part in the mapping workshop?

The people who do the work, plus someone who decides and someone who will lead the design. A workshop limited to managers produces the official map, not the real one, and the real map is what determines the automation's design.

How do you choose what gets automated in the to-be map?

For each transition, ask three questions: should the step exist, can it be automatic and under what condition, what stays human and why. A transition becomes an automation candidate when its exit criterion is machine-verifiable and its failure has a defined behavior.

What exactly is a system of reference?

It is the single place that is authoritative for a given piece of information at a given moment. If the quote's status is authoritative in the CRM, the inbox is only a transport channel. Every automation must read and write in the system of reference, never in a copy.

Does mapping guarantee the automation will work?

No. It guarantees you are automating the right process, with explicit exit criteria and clear ownership. Execution failures, retries and tool limitations still have to be designed separately. The map reduces design risk, not operational risk.