How to Map Complex B2B Workflows Before a Redesign

A B2B workflow map describes how a specific piece of work progresses across people, roles, and systems. It connects actions to the conditions that make those actions possible and the evidence that shows they succeeded.

The unit of work might be a purchase request, an insurance claim, a laboratory sample, a customer account, or a document awaiting approval. Choose one object to follow. If your map switches between a customer, a contract, and an invoice without explaining their relationships, it will quickly become difficult to interpret.

A useful map answers four questions throughout the process:

• Owners: Who is accountable for moving this item forward, and who may act on it?

• States: What is true about the item now, and what must happen before that changes?

• Handoffs: How does the next person or system receive the work and accept responsibility?

• Exceptions: What can interrupt progress, who resolves it, and where does the work resume?

A user flow can show the screens someone visits to submit a request. The workflow map also follows what happens after submission: review queues, decisions, missing information, automated jobs, and downstream confirmation. Both are useful, but the wider workflow should inform the screen-level design.

Avoid starting with “map the whole platform.” Start with a business outcome that matters and a boundary the team can examine.

For a purchase-request workflow, the starting event could be an employee saving a new request. The successful endpoint could be the purchasing system confirming that a purchase order has been created and linked to that request. Rejection and cancellation are alternative endpoints, not successful completion.

That distinction matters. “Approved” may finish a manager’s task while leaving the business process unfinished. “Sent to purchasing” may describe an attempted handoff without confirming that anything arrived.

Write down the scope before collecting detail: the object being tracked, the starting event, the successful outcome, the alternative endpoints, and the adjacent processes you are excluding. For this example, receiving goods and paying invoices would sit outside the map, with their connection recorded.

Choose the first workflow using a combination of business importance, observed friction, volume, and consequences of failure. A frequent inconvenience and an infrequent but serious failure both deserve attention; they may require different priorities.

Ask people to walk through a recent case from beginning to end. “Show me the last request you returned for changes” usually reveals more than “How does approval work?”

Include the people who initiate the work, receive it, resolve problems, and maintain the systems involved. Managers may explain the intended process. Frontline users can show where it changes under pressure. Engineering and support can help explain what the interface hides.

Useful evidence includes observed sessions, redacted records, support tickets, activity histories, queue data, system events, and existing operating procedures. Follow the work into email, spreadsheets, chat, and external tools when those channels are part of the process.

Record three things separately: what the system allows, what policy requires, and what people actually do. A permission check in the application does not prove that a policy is followed. A procedure document does not prove that a feature exists.

Attach evidence to your notes. A simple reference such as “E03: walkthrough of returned request, operations role, date” is enough to help the team revisit a finding. Mark unsupported statements as assumptions or open questions. Avoid turning a workshop consensus into a verified fact.

Use several contrasting cases: a routine completion, a return for correction, a stalled handoff, and a failure or cancellation. This is a practical starting sample, not proof that every variation has been covered.

“Finance owns it” leaves too much unanswered. Is there an assigned reviewer? A shared queue? A queue manager who handles unclaimed items? Who covers an absence?

Document roles first, then capture how an actual person is assigned. Keep these responsibilities distinct:

• Workflow owner: Accountable for the overall process and its performance.

• Current work owner: Responsible for advancing a particular item now.

• Decision authority: Allowed to approve, reject, override, or authorize a change.

• Contributors and viewers: People who provide information or need visibility without owning the next action.

In the purchase example, procurement might own the overall process, the requester might own a correction, and a budget holder might hold approval authority. These responsibilities can change as the request moves.

An automated service can execute a task, but a human role still needs responsibility for unresolved failures. Document both the service doing the work and the team that investigates when it stops.

Define ownership during waiting periods as carefully as during active work. If a supplier needs to provide missing information, a procurement coordinator may still own follow-up. “Waiting for supplier” should not become “owned by nobody.”

This directly affects interface requirements: assignment controls, permission-aware actions, queue visibility, delegation, and escalation. Give users a clear answer to “Who acts next?”

Status labels often accumulate without shared definitions. “Open,” “pending,” and “in progress” can each describe several different situations.

A state should express something meaningful about the work. Define what must be true for an item to enter that state, who owns the next action, and what can move it elsewhere.

For example, “Submitted” could mean that required fields passed validation, a specific version was recorded, and the request was routed to a review queue. “Approved” could mean that an authorized person approved that version. Neither definition implies that an order exists.

The following simplified example is illustrative; adapt its rules to your organization.

Add definitions for rejection and cancellation even when they sit outside the main successful path. Specify who may use them and whether reopening is permitted.

Keep independent dimensions separate. A request can be approved, have a high priority, and be blocked by incomplete supplier data at the same time. Forcing approval status, urgency, and blockers into one field makes the meaning harder to understand.

When multiple reviews run in parallel, record each review’s status and define the rule that joins them. Does the request proceed only when every required reviewer approves? Can one rejection stop the process? The overall status should follow an explicit rule.

States describe conditions. Transitions explain how those conditions change.

For each transition, capture the trigger, authorized actor, prerequisites, information transferred, receiving owner, and confirmation of success. Include what the user sees if the action cannot finish.

Consider the transition from “Changes requested” to “Awaiting review.” A useful definition might say: the requester corrects the missing fields and resubmits; validation passes; a new version is recorded; the designated review queue receives it; and the requester sees confirmation with the new owner and submission time.

The return path is just as important as the forward path. Reviewers need the reason for the earlier return and visibility into what changed. Otherwise, the next review starts without the context needed to complete it efficiently.

A handoff deserves its own agreement:

A notification is not proof of receipt or ownership. Someone may receive an email without access to the record, or a system may accept a job without completing it. Distinguish notification, queue entry, assignment, and execution wherever that distinction affects the outcome.

For external systems, identify the source of truth for each key value. If the product displays an order as completed, specify the downstream event that justifies that claim. Record delays, failed synchronization, and reconciliation responsibility.

Exceptions expose requirements that the successful path cannot show. A polished submission form offers limited help when the approver is absent or the purchasing integration times out.

Review each step through concrete questions:

• What if required information is missing, stale, or contradictory?

• What if the assigned person is unavailable or no longer has permission?

• What if someone changes the request after approval?

• What if the user submits twice or retries after an uncertain result?

• What if an integration fails, times out, or completes only part of a batch?

• What if another user edits the same record?

• What if the request is withdrawn or a completed action needs correction?

For every relevant exception, document the detection signal, visible status, recovery owner, allowed actions, preserved information, and destination after recovery. Include an escalation or alternative endpoint when recovery is impossible.

Suppose order creation times out. The redesign should not simply offer a generic Retry button. The map must establish whether an order might already exist, how the system checks, and how duplicate creation is prevented. The user needs an honest status while that uncertainty is resolved.

Suppose the requested amount changes after approval. Record whether the change invalidates the earlier approval, who decides that rule, and which state the request returns to. That is a business-rule decision with interface consequences.

Estimate frequency and impact separately. Label estimates as estimates. A rare exception may still deserve explicit support if it can create expensive duplicate work or an irreversible action.

Walk through the map with the people represented in it. Use actual cases and ask where each case would be, who would own it, and what evidence would allow it to move forward.

Check for states with no owner, transitions with no prerequisite, handoffs with no confirmation, and exception paths with no recovery or endpoint. Ask engineering to verify system behavior and operations to verify responsibility and policy.

Resolve disagreements visibly. If users say reassignment is possible but engineering says the system does not support it, investigate the workaround. Do not quietly choose one version.

Keep the current workflow and the proposed workflow separate. Label each map with its scope, version, review date, and remaining uncertainties. A proposed improvement should never appear as an observed capability.

For larger workflows, use a high-level map with linked detail for complicated stages. A swimlane view can make ownership changes visible; a state table can define rules precisely. Use both when they answer different questions, and keep their identifiers consistent.

The map is useful when it changes what the team builds.

Trace each proposed requirement to a specific problem. If approved requests sit unassigned, the requirement might be a visible procurement queue with aging, assignment, and escalation. If returned requests lose context, the requirement might be structured return reasons and a comparison of submitted versions.

Some findings call for a policy or operational change. A redesign cannot decide approval authority or staffing coverage by itself. Name the decision owner and dependency so the interface does not promise behavior the organization cannot support.

Write acceptance criteria around observable outcomes. For example:

When an approved request is sent for order creation, the interface shows that creation is pending. It shows completion only after a linked order is confirmed. If confirmation is uncertain, the request remains visible to its recovery owner and cannot be retried in a way that creates a duplicate order.

Use the map to shape prototype testing as well. Test the routine path alongside correction, reassignment, failure, and recovery. Include different roles and permissions, rather than testing every task as an administrator.

Choose measures that reflect the workflow: elapsed time from the agreed starting event to confirmed completion, time waiting at handoffs, return-for-correction rate, unresolved exception age, and successful completion by scenario. Separate active work time from waiting time where the data allows it. Establish a baseline before claiming improvement.

Download the following structure for each workflow. Use one version for the observed process and a separate version for the proposed changes. Duplicate the step and exception records as needed, linking them with stable IDs such as S01, T01, and E01.

Before using the worksheet to guide design, confirm that every state has an action owner or an explicit terminal meaning; every handoff has an acceptance signal; every important exception has a recovery or endpoint; and every proposed change is distinguishable from current behavior.

A workflow map gives the redesign a concrete foundation: clear responsibility, meaningful status, reliable transitions, and a way forward when something goes wrong. It also gives the team a way to evaluate design decisions beyond visual preference.

The next time someone asks for a simpler dashboard, follow one piece of work through the product first. The most valuable improvement may be a clearer queue, a recoverable failure, or a handoff that finally carries the right context.

Dworkz helps B2B SaaS teams turn complex workflows and data into intuitive digital products. If your redesign involves multiple roles, connected systems, and decisions that need to be traceable, we can help define the workflow and carry it through design and development. Let’s talk.