B2B Customer Journey Mapping: A Map You Can Check
A worked B2B purchase map and copyable worksheet connect role-specific accounts to dated records, preserve disagreements and turn a disputed handoff into a checkable next step.
B2B customer journey mapping connects the decisions people at one account make as they evaluate, buy and use an offer. A useful map lets you inspect the handoff between those decisions: what was sent, what the next person could act on, and what remains uncertain.
Consider a fictional regional electrical-parts distributor evaluating proof-of-delivery software to replace emailed delivery photos and paper signatures. Its goal is to help branch staff retrieve usable delivery evidence when a customer disputes a shipment. The company, roles, dates, records and quotations in this walkthrough are invented.
The operations lead says the technical pack went to IT on September 8. The IT reviewer says useful review material didn't arrive until September 15. The supplier must decide whether to change its follow-up, the review pack or something else. A CRM label such as “waiting on IT” doesn't settle that question.
The map below keeps both people's accounts visible, connects them to records and turns their disagreement into a check someone can carry out. You can copy the same structure for your own research.
One purchase has several individual paths
The distributor's operations lead wants a delivery record that branch staff can find. The IT reviewer needs to assess where shipment data and images go, who can access them and how long they're kept. Finance needs an acceptable commitment. Those responsibilities meet in one evaluation, but the people doing them don't necessarily start together or wait for the same information.
Purmonen, Jaakkola and Terho's B2B customer journey framework connects individual buying and usage paths and gives attention to both purchase and use. For your map, that means keeping the people who evaluate an offer connected to the people expected to make it work.
Give the purchase an account identifier and a separate evaluation identifier. Here they're DIST-07 and POD-2026-09. Use the same identifiers in every interview note and event row. A later renewal could have another evaluation identifier within the same account.
The scope is the first discussion of the delivery-evidence problem through first branch use. The available reconstruction ends on October 5, 2026. A purchase order is present; first use hasn't been checked. That gap stays in the map.
Several role accounts can describe one evaluation; they don't become independent purchases. If you need to decide whom to recruit and how to verify their involvement, our B2B market research guide covers that work. Don't add a finance or procurement lane solely because those titles appear on a standard committee chart.
A shared chronology makes the handoff visible
Begin with dated events before assigning stage names. GOV.UK's experience mapping guidance starts from captured user experiences, aligns common events and adds supporting artifacts. In an account map, keep a separate description of each person's activity inside that shared chronology.
The identifiers below keep each event linked to its supporting record or interview. Interview dates are when a person's account was recorded, which may be later than the event it describes.
Event date | Role paths and evidence for DIST-07 / POD-2026-09 |
|---|---|
September 2, 2026 · E01 | Operations: identifies a disputed delivery as the trigger for the evaluation in interview INT-OPS-01, recorded October 2. Known: incident ticket ART-01 records the delivery-evidence inquiry. Reported: that inquiry made a new system a priority. IT's involvement at this point is unknown. |
September 8 · E02 | Operations → IT: email ART-02, sent at 10:14, forwards a supplier overview and a portal link. Known: the message and its contents. IT: later recalls opening the overview, in INT-IT-01, recorded October 5. Whether the linked technical files were accessible then is unknown. |
September 10 · E03 | IT → Operations: review ticket ART-03 requests the data fields collected, storage location and retention period. Known: the request was logged. Whether operations understood it as a request for missing material or clarification isn't recorded. |
September 15 · E04 | Supplier → IT: portal history ART-04 records an upload of data-flow-v2.pdf. IT: reports this was the first review-ready information. Operations: reports believing the earlier pack was complete. These accounts conflict over what was available and usable before this date. |
September 18 · E05 | IT: ticket ART-05 approves the deployment described in the reviewed materials. This records a technical decision within that scope. Finance's purchasing decision remains a separate step. |
September 25 · E06 | Finance: signed purchase order ART-06 records the software purchase. Operations / branch users: no first-use evidence has been collected by the October 5 cutoff. A signed order doesn't fill that part of their path. |
This map shows a specific dependency. Operations hands information to IT, but sending an overview and making a review possible are different events. The gap deserves investigation; it doesn't yet establish who caused a delay.
Keep events outside the supplier's systems when they're relevant. A branch conversation, an internal budget discussion or a comparison with the existing paper process can change the decision without producing a website visit. GOV.UK's whole-problem mapping guidance helps frame the wider task across organizational and channel boundaries. Your funnel can sit alongside this account record, but its stages describe your process rather than prove what each buyer has resolved.
Evidence status belongs to the claim
Use four plain labels:
- Known: a checked record supports the specific event or fact stated. ART-02 supports the email's timestamp and documented message contents.
- Reported: a person describes an experience, interpretation or recollection. Keep their role, interview date and the event they're describing.
- Unknown: the relevant evidence hasn't been obtained or can't settle the question. Leave the field open.
- Conflicting: accounts disagree about a consequential detail. Preserve both statements and link the records involved.
The labels aren't scores for whether you trust a person. An interview transcript makes it known that a participant said something; the historical event they describe may still be reported. An upload timestamp shows when that version entered the portal, not when someone read or understood it.
Split a sentence when its parts have different support. “Operations sent an email on September 8” can be known while “IT had everything it needed on September 8” remains unresolved. Giving the whole sentence a green confidence label would hide the distinction.
Our customer journey research guide develops the connection between recorded actions, customer accounts and competing explanations. Here, the additional job is to preserve that connection across people in the same purchase.
Two credible accounts can describe different handoffs
Operations says: “I sent the complete technical pack on September 8. After that we were waiting on IT.” The reviewer says: “I could open the overview, but I didn't have information I could review until September 15.”
Record the statements separately. Combining them into “a seven-day IT delay” would turn the disagreement into an unsupported cause. Create a reconciliation record linked to E02–E04.
Reconciliation field | Worked entry |
|---|---|
Question | What material could the reviewer access before September 15, and was it sufficient to start the required review? |
Operations account | INT-OPS-01, October 2: believes the pack forwarded on September 8 was complete for review. |
IT account | INT-IT-01, October 5: reports that review-ready information first arrived on September 15. |
Shared facts | ART-02 records the forwarded overview and portal link. ART-03 records the September 10 request. ART-04 dates the v2 upload. None establishes the contents and permissions of the earlier linked files. |
Still unknown | The September 8 portal version and access permissions; whether another approved copy existed; what work the reviewer could start; whether review capacity also affected timing. |
Check and owner | The researcher asks the supplier's document owner for the relevant historical version and access record, then checks those items separately with operations and IT. Obtain only the records needed and authorized for this review. |
Current resolution | Open. “Forwarded” and “review-ready” refer to different milestones. The existing evidence doesn't establish the cause or length of avoidable delay. |
Ask both people what they mean by “complete” before showing them your interpretation. Have the reviewer identify the specific input needed for the first review task. Check whether that input was actually in the accessible version at the time. A current portal screenshot can't establish earlier access.
Different findings would lead to different action. If a required field was missing, revise the pack. If the field was present but inaccessible, repair access. If the reviewer had usable information but couldn't begin, investigate how reviews enter the queue. More than one condition may apply. The map keeps those possibilities available until evidence narrows them.
Questions that recover each role's part
Ask people to reconstruct their own involvement before asking them to explain everybody else's. Use a recent evaluation and material they can appropriately share.
For the operations lead or sponsor:
- What happened just before you decided the existing delivery-record process needed to change?
- Show me what you sent to the reviewer. What did you expect them to do next?
- What, if anything, told you they had enough information? Which reply or action did you see?
For the technical reviewer:
- What was the first task you needed to complete in this evaluation?
- Which exact document or field let you start? Can you identify the version and date?
- What could you assess before that arrived, and what remained blocked?
For the person approving the commitment:
- What decision could you authorize, and what did you need from the other people first?
- Which cost, condition or unresolved requirement changed the approval?
- What would have made you defer or decline this purchase?
For branch staff expected to use the software:
- Walk me through a delivery dispute using your current process.
- What would count as a usable delivery record in that task?
- After the software was bought, what happened on the first occasion you tried to retrieve one?
If someone learned a detail from another person, record that source relationship. A sponsor's recollection of an IT objection can identify the next interview; it doesn't replace the reviewer's account. When a role hasn't been interviewed, keep the gap visible rather than asking a simulated role to supply its historical testimony.
A copyable B2B customer journey mapping worksheet
Use one entry per role, event and claim. Link entries with the shared account, evaluation and event identifiers. Copy the card below into your document or use the fields as spreadsheet columns. Separate conflicting claims into linked entries so neither disappears when you update the map.
Field | Your entry |
|---|---|
Account / evaluation | [Account ID] / [evaluation ID; purchase situation; scope; reconstruction cutoff] |
Event / dates | [Event ID; event date or range] / [supporting record or interview date] |
Role and responsibility | [What this person used, assessed, recommended or could approve] |
Decision or task | [What they needed to decide or do at this point] |
Account or action | [Their words, or a precise description of the recorded action] |
Evidence | [Source ID; type; document version or interview date; relevant access limit] |
Status | [Known / reported / unknown / conflicting; apply to the specific claim] |
Handoff | [From whom → to whom; item sent; next task; what confirms it can begin] |
Unresolved difference | [Linked entry; each account's claim; detail that changes the next action] |
Next check / owner | [Evidence needed; who can obtain or assess it; agreed check date] |
Proposed intervention | [Change; person responsible; condition it addresses] |
Outcome / follow-up | [Observable result; eligible evaluations; observation window; unknowns retained] |
Keep the source materials in the appropriate research repository. The map needs a reference that an authorized colleague can follow, not copies of confidential attachments in every shared presentation.
When comparing accounts, preserve this event-level detail before summarizing a pattern. A distributor's first software purchase and another customer's routine renewal may involve different work. Several people agreeing within DIST-07 strengthen your understanding of that evaluation; they don't establish how common the handoff problem is across the market.
A proposed review pack can be compared before rollout
The map can also expose a question about a future change. Suppose the supplier has a complete, accessible technical pack but wants to explain its contents and next steps more clearly. It could compare two introductions to the same pack: a general overview and a role-specific explanation of what operations must supply and what IT will assess. Keep the underlying requirements and information the same so the comparison addresses the explanation.
At Sapien, we build synthetic populations grounded in purchase, behavioral and research data. Customer data and previous research can add context. We can run qualitative interviews and comparison tests with the same simulated audience and examine how audience groups respond.
For this B2B task, first agree whether the available evidence supports the particular roles and buying situation. A comparison can explore modeled interpretations and questions about the proposed pack. Our B2B concept-testing guide shows how to keep role reactions tied to the next commitment and the conditions attached to it.
Keep generated responses on a proposed-change sheet. They don't establish which files the distributor received, reconstruct private buying events or substitute for human fieldwork. Check comprehension with real reviewers and check the live handoff against its records.
Book a Sapien demo if you want to explore a comparison of review-pack explanations. We can agree the audience evidence and the decision it could support before defining the study.
The useful result is a review that can start
The supplier can test a practical handoff change while the historical disagreement remains open. Its solutions consultant owns a versioned review brief that lists the inputs agreed with the buyer's reviewer, links to the relevant files and names the review owner. The reviewer acknowledges either that the review can start or which input is still missing. Sales operations keeps that acknowledgment with the evaluation record.
For a proposed live pilot, define eligible new evaluations before launch and follow each for ten business days after the first pack is sent. Measure the share of those evaluations reaching a recorded technical approval or decline within that window, with the reviewed scope or unresolved condition attached. Keep every role in an evaluation under the same handoff approach, and retain pending or unknown outcomes in the full evaluation base. A decline can be a useful resolved decision; the aim isn't to pressure reviewers into approval.
Also inspect requests for missing inputs and exceptions discovered after approval. A quicker decision accompanied by more overlooked requirements would undermine the change. If you need to attribute improvement to the brief, arrange a suitable concurrent comparison; a before-and-after result can also reflect staffing, account mix or other changes.
Finally, continue the distributor's map beyond its purchase order. Did branch staff retrieve usable evidence for a real disputed delivery? That requires task and usage evidence. The promise in the sales material can't complete the row.
The map has done its job when someone can see which decision is waiting, inspect the support for that account and carry out the next check. A visible unknown with an owner is more useful than a finished-looking journey that conceals the missing handoff.