How to map the B2B customer journey across Salesforce clouds

The executive slide says the customer is in decision. The opportunity is open, so the slide is technically reading a field. Delivery started three weeks ago. A work order is assigned. Support has an open case about the install. Finance has raised an invoice in another system that nobody on the slide can open. The country manager asks why implementation is late. The page says the customer has not been won yet. Dispatch searches for a box labelled delivery and finds a word.

A map tells an operator which record exists, who owns it, and which field means the stage is done. A slide that runs from awareness to consideration, to decision, to advocacy, and never names an object, cannot be clicked, reported, or handed to the next team. Take it off the wall until it can. The hours spent arguing about "where the customer is" are the cost of a poster that looks finished.

#Name the object, or take the stage off

Lead, contact, opportunity, case, contract, invoice. Those are the nouns a business-to-business org can assign to a person on a Monday. Awareness is not an object. If you mean a campaign response, or a new lead, say so, and name the field that marks it done. Consideration is not an object. If you mean an open opportunity with a next step dated inside the month, say so. Decision is not an object. If you mean a closed-won opportunity, or a contract a named person has approved, say so. Advocacy is not an object. If you mean a contact on a reference programme, or a closed opportunity with a renewal beside it, say so. A stage you cannot point at in the org is a word on a slide, and no queue can own a word.

The test is dull and sufficient. Pick one product line. Open one deal you won and one you lost. In the order the records were created, write the object name, the owner, and the field that marks that stage done. If a stage in the slide has no row in that list, it is not on the journey yet. Where the work lives only in a spreadsheet, either bring it onto an object someone can open, or remove it from the map and write the spreadsheet name in the margin so you do not pretend. People cannot work a stage they cannot open, and they will not update a stage that does not exist when they are busy.

Do this for the lost deal as well as the won one. Lost deals show the stages you skip and the objects you create anyway: a lead that never converted, an opportunity that died with no next step, a case opened before anyone admits the sale failed. If the map only describes the happy sequence, operators will meet every real week as an exception. Exceptions become shadow sheets. The map is for the week you actually have.

#The handoff is a field

When a lead becomes a contact and an opportunity, name the automation that does it and the fields that must be filled or the conversion waits. "The team will know" is how records convert half-empty and the next owner sends them back. Write the blocking fields down: the account they belong to, the product, the person who will work the opportunity. A conversion that succeeds with those blank has not handed work on. It has created a record the next team cannot use, which they will discover on a call with the customer.

When delivery starts while the sale is still open, the map shows both records on one account. Hiding the case, or the work order, because the opportunity has not closed makes the executive page lie about where the customer is. The lie is not philosophical. It sends implementation questions to the seller, and sales questions to the dispatcher, and both of them keep a private note because the shared page is wrong. The account is the thing they share. The stages are the records.

Two writers on the same stage is how status fields fork. Decide, per stage, which cloud or system creates and updates the record, and which others may only read it. Sales can read the case. Service can read the opportunity. Neither overwrites the other's status because their own process moved. A flow that sets the opportunity to "implementing" when a case opens, and another flow that sets it back when the case closes, is two writers. Pick one field that means the sale, and a different field that means the delivery. Read both. Do not make them fight.

The qualified moment, if it appears on this map, is one field with one owner. That argument is settled in how marketing and sales share one definition of the stage. If this map says qualified and that field says something else, the journey and the forecast will disagree in every meeting that uses both.

#Invoice is a system and a key

If the invoice is raised in another system, the map still names it. The system. The identifier. The opportunity, order, or contract it joins to. A box labelled invoice, with no system and no key, is the same poster in a different font. Sales will talk about the price on the quote. Finance will talk about the price on the invoice. Without the key, those are two memories, and the renewal will start from whichever PDF someone finds first.

Write the join in the direction a person can click, or in the direction an integration can resolve. Opportunity number stored on the invoice. Invoice number stored on the order. Contract number stored on both. One of those, written down, is enough to start. "We will reconcile monthly" is not a key. Monthly reconciliation is the bill for not having one, paid in hours, and it will be paid whether or not you put it in the business case.

Say who is allowed to change the price after the join exists. If the quote can move after the invoice is raised, the map needs a field for that event and a person who accepts it. A status on the opportunity that nobody in finance reads is not that field. The rule belongs with the contract record as well, which is a later stage on this same map, not a separate poster owned by legal.

#Service is a stage with its own records

Salesforce describes the product this way: "Agentforce Field Service and Operations (formerly known as Field Service) gives you a powerful, highly customizable, mobile-friendly field service hub in Salesforce." If the journey includes an install, a visit, or a break-fix, the map shows the case, the work order, or both, whichever you actually use. A box labelled delivery is not a record a dispatcher can open. The technician cannot update a box. They can update a work order on the device before they leave, and that update is the stage moving.

The customer can be in implementation and in support on the same day. Those are two stages. Forcing them into one status, so the dashboard has a single colour, hides the break-fix behind the project or the project behind the break-fix. Report both. The account is what they share. If you need a single executive sentence, write it from the two records: delivery in progress, and a support case open since Tuesday. That sentence can be true. "In delivery" as the only status cannot, once the case exists.

Name the owner of the work order separately from the owner of the opportunity. The seller does not dispatch. The dispatcher does not close the sale. A map that puts one name on both will be ignored by the person whose name was left off, and the record they actually use will drift out of the diagram within a month.

#Unify after the objects exist

Data 360 is described as a place to "Ingest, harmonize, unify, and analyze streaming and batch data with Data 360." Bringing sources together is useful after each stage has a home. Unifying a journey that was never mapped to objects unifies the confusion, and then an agent or a dashboard will repeat it with confidence. A harmonised "customer stage" calculated from three conflicting statuses is a faster version of the executive slide. It still has no record a person can open and correct.

If a stage is missing from the org, do not invent it in the data platform to make the picture complete. Either create the object, with an owner and a done-field, or leave the stage off. A calculated stage that no operator maintains will be wrong the first week a real job skips a step, and nothing in the pipeline will mark it wrong. The operator will notice. The slide will not.

#Draw it in a week, then stop adding boxes

One product. One won deal. One lost deal. The objects in order, the owner of each, the field that means done, and the system that writes it. That is the map. It fits on a page because you refused the stages that have no record. Where you are tempted to add a box, write the spreadsheet name in the margin and leave the box off. Review the map when a new cloud arrives. The new cloud gets a named object on an existing stage, or it gets a new stage with an owner and a done-field. It does not get a fresh awareness-to-advocacy poster of its own.

Cheap, while the poster is still a poster: deleting a box, naming an object, naming an owner. Nobody has built a dashboard on the words yet.

Expensive, once reports and agents quote the slide: changing what a stage means after people have been measured on it. A "decision" that quietly changes from closed-won to contract-signed will move a quarter of history if you recalculate, and will split the room if you do not. Write the definition before the first dashboard reads it. The same discipline as the field itself: one sentence, then the build.

Three ways the poster survives. The workshop adds a stage so every team feels represented, and the stage has no object by the end of the day. A new cloud arrives with its own journey diagram, and nobody checks it against the records you already named. Data 360 is asked to supply the missing stages, and the calculated field becomes the official lie. Each one is avoidable in the week you draw the map. After that week, stop adding boxes. The next job is to make the records match the page you were willing to keep.