Buyer Journey Maps Start With a Buyer Question
A prospective customer reads your explanation of a problem, returns a week later to compare options, and then asks a question that seems to belong at the beginning: “Are we solving the right problem?” If you treat the return visit as a failure to move through a funnel, your next message may be a sales pitch. If you treat it as a buying decision still in progress, you can answer the question that is holding the person back.
The buyer journey is the path a person or group takes from recognizing a need to making a purchase decision. HubSpot presents a useful first sketch: awareness, consideration, and decision. It also distinguishes that pre-purchase path from the customer journey after purchase, which can include onboarding and use. Those labels are helpful for orienting a team, but they cannot tell you what any particular buyer still needs to decide. HubSpot’s explanation of the buyer’s journey makes the three stages explicit.
For a working buyer journey, I would start with the decision the buyer is trying to make, then ask what would make that decision possible. That shifts attention from what your company wants to send next to what the buyer needs to understand, compare, or explain to someone else. The result should guide a page, a sales conversation, a product demonstration, or an internal handoff. A colorful diagram has little value if it cannot change one of those choices.
Begin with the buyer’s unresolved question
Imagine an operations manager looking for software because a recurring handoff is being missed. This is an illustration, not a reported company case. The manager may first search for ways to describe the handoff problem. Later, the manager may compare software with a process change. A demonstration could then raise a new concern: perhaps the current workflow cannot supply the information the proposed software requires. The manager has seen a product, but the original problem is still unsettled.
This is why a journey should describe a buyer’s work rather than assume that exposure to your material equals progress. Reading a product page shows that a page was read. It does not show that the buyer has agreed on a requirement, accepted the cost of change, or secured approval. A buyer can be highly active and still unable to buy. Conversely, a buyer who has not contacted sales may have settled several questions independently. Treat observed actions as clues to a decision, not as the decision itself.
The first useful question is therefore specific: what is the buyer trying to settle right now? “Learn about our product” is your objective. “Decide whether missed handoffs call for a new tool” is the manager’s. The second version tells you what would help: a clear account of the problem, options that do not assume a purchase, and the conditions under which each option makes sense. It also tells you why a feature tour may be premature. I would write down the buyer’s question in the buyer’s own terms before choosing content or outreach.
A buyer journey can begin before the buyer knows a product category and can continue through the point of choosing a supplier. The boundary matters. If the main question is whether a new customer can adopt a purchased service successfully, you are moving into the customer journey. HubSpot draws that distinction between pre-purchase decisions and post-purchase experience. In practice, the boundary should not become a wall: a buyer assessing a supplier may reasonably ask about implementation before signing. Answer the implementation question because it affects the purchase; manage actual onboarding as a separate experience. HubSpot’s distinction between buyer and customer journeys supports that scope.
Use the three stages as a sketch, then name the buying work
Awareness, consideration, and decision are a compact way to see the broad movement. In awareness, the buyer identifies a problem or need. In consideration, the buyer examines possible approaches. In decision, the buyer evaluates options for a purchase. HubSpot’s stage descriptions set out those meanings. If you are planning a small set of introductory pages, this structure is often enough to notice a glaring absence, such as having only product comparisons and no explanation of the problem.
It becomes less useful when the label is treated as a diagnosis of one person’s readiness. “Consideration” could mean comparing two methods of solving the problem, defining requirements for one method, or checking whether an apparent solution will work at all. The next useful answer changes with each of those questions. A stage label gives the area of the map; the question tells you where to act. I would keep the three stages for a high-level view and add the specific decision the buyer is working on beside each interaction.
For organizational purchases, Gartner names six buying jobs: problem identification, solution exploration, requirements building, supplier selection, validation, and consensus creation. Gartner also describes B2B buying as nonlinear, with buyers revisiting jobs rather than completing them in a fixed order. Gartner’s account of B2B buying jobs is a better lens when several people must agree on what to buy. The jobs are not six mandatory meetings or a universal calendar. They are distinct questions that can reopen one another.
Problem identification asks whether an issue is important enough to address. Solution exploration asks what approaches could address it. These are different decisions. A manager may recognize that handoffs fail yet remain unsure whether training, clearer ownership, or new software is the appropriate response. If your first answer is a supplier comparison, you have skipped the choice of approach. I would offer an explanation of the possible causes and trade-offs before asking that buyer to compare vendors. The cost is that some readers may decide they do not need your product. That is a better result than encouraging a purchase built on a mistaken problem definition.
Requirements building asks what a solution must actually do in the buyer’s setting. Supplier selection asks which provider best meets those requirements. If the operations manager needs approvals to be traceable, a demonstration should show how a trace would work in the illustrated workflow. A generic list of capabilities cannot answer that requirement. Likewise, a comparison that crowns a provider without stating the buyer’s requirements hides the basis for the recommendation. Gartner separates requirements building from supplier selection in its six-job model, a distinction worth preserving in your own material. Gartner’s B2B buying framework identifies both jobs.
Validation asks whether the preferred answer will hold up to scrutiny. Consensus creation asks whether the people whose agreement matters can support it. Those questions may arise early, late, or repeatedly. An individual can decide that a service seems suitable, then discover that another person needs a different kind of explanation. In a buying group, the person who attends a demonstration may have to carry the reasoning to colleagues who did not attend. The useful artifact may be a concise explanation of the problem, requirements, proposed choice, and open risks, rather than a recording of the demonstration. Gartner describes multiple stakeholders doing buying work through different channels and returning to earlier questions. Gartner’s discussion of buying groups supports this distinction.
The two frameworks therefore serve different purposes. The three stages make a broad plan legible. The six jobs help reveal the work concealed inside that plan, especially when an organization is buying. I would not force every consumer purchase into six boxes, nor assume every B2B buyer follows six boxes in order. Choose the simpler view when it is sufficient to make a decision about what to explain next. Add the job-level view when “consideration” or “decision” has become too vague to guide an actual response.
Map one actor and one purchase situation at a time
A useful map needs a defined person, a situation, and a goal. The guidance from Digital Public Services Wales describes a journey map in terms of an actor, scenario and expectations, phases, actions, thoughts and emotions, and opportunities to improve the experience. It also says the phases vary by scenario and asks mapmakers to consider what happens before and after the central interaction. Digital Public Services Wales’s journey-map guidance supplies a sound structure. For a buyer journey, I would add the purchase question each action is meant to answer.
Start by naming an actor narrowly enough that their actions make sense. “Our customer” is too broad for an organizational purchase. The operations manager in the illustration might experience the missed handoffs, while a finance reviewer might care about cost and contractual commitment. Both can affect the same purchase, but they do not have the same journey. Make one map for the operations manager’s attempt to find a workable approach. If the finance reviewer’s concerns materially shape the decision, make that viewpoint visible too. Combining their thoughts into one fictional person creates a smooth picture at the price of accuracy.
Next, state the scenario without smuggling in your preferred answer. “An operations manager chooses our workflow software” assumes the outcome. “An operations manager must reduce missed handoffs without adding a burdensome process” leaves room for the buyer’s actual choice. The scenario should include what set the search in motion, the decision at stake, and the limit that makes the decision difficult. These are questions to fill from actual conversations or observations when you have them. Until then, mark the scenario as an illustration rather than presenting it as a discovered pattern.
Then trace what the actor does and what each action is for. A search query might be an attempt to name the issue; a comparison page might help distinguish approaches; a call with a supplier might test a requirement. The same action can serve different purposes. Someone reading pricing may be deciding whether an approach is affordable, preparing a budget request, or checking the final offer. The map should record the question the person was trying to answer, as far as it is known, rather than assign meaning from the page type alone. Digital Public Services Wales puts actions and thoughts within phases; retaining both prevents the map from becoming a click sequence. Its mapping guidance makes that relationship explicit.
Include obstacles that change the decision. For the illustrative manager, a supplier might explain the software clearly but leave unanswered who would maintain the underlying workflow. The obstacle is not a missing call to action; it is an unresolved operating responsibility. The next useful step is to make the responsibility visible and discuss what the buyer would have to supply. If that burden is too high, the recommendation may change. A map is most valuable when it lets a team say, “This buyer cannot decide yet because this question is unanswered,” and then do something specific about it.
Emotions belong in the map when they help explain behavior, but do not invent them to complete a template. If a person expresses anxiety about defending a choice to colleagues, record it in that person’s terms. If no one has said how they feel, focus on the observable question and leave the emotion open. This is a practical discipline: an imagined “frustration” can send a team toward smoother copy when the real issue is a requirement no supplier has answered. The map should preserve uncertainty where it exists, not cover it with a polished curve.
Match the answer to the decision, not the channel
Once you know the buyer’s question, choose the form that answers it with the least unnecessary work. A person trying to identify a problem needs a plain explanation of symptoms, possible causes, and when action is warranted. A person exploring solutions needs a comparison of approaches, including the option to make no purchase. A person defining requirements needs concrete criteria that can be used in their own setting. A person choosing a supplier needs a fair account of fit, limits, and cost. The content format follows the decision; the stage name alone does not dictate a blog post, email, or call.
The software illustration shows why. An early page might explain how handoffs can fail and how to distinguish a process ownership problem from a tool limitation. A later page could compare clearer procedures, changes to existing tools, and dedicated software on the dimensions the manager cares about. A requirements worksheet could then ask who initiates a handoff, who accepts it, what record must remain, and what happens when nobody responds. Those are illustrative questions, not a universal checklist. Their value is that a buyer could use the answers to reject an unsuitable option before spending time in a demonstration.
For supplier selection, make comparison criteria visible. If you present only the features your product has, the buyer still has to translate them into the requirement they have. Show what the feature enables, what must be configured, and what is outside its scope. When a limitation matters, say so. A clear limit can help a buyer decide whether the limitation is acceptable; a hidden limit reappears in validation, procurement, or implementation. My preference is to make a short, candid answer available at the point of comparison and reserve a conversation for the buyer’s particular conditions.
For validation, let the buyer test the claim that matters. In the illustration, a demonstration using the buyer’s handoff steps would answer more than a tour of every menu. If the requirement concerns who receives an exception, show that path, including what happens when the usual owner is absent. If the provider cannot show it without knowing the buyer’s system, describe the information needed and the boundary of the demonstration. A useful answer need not eliminate every uncertainty. It should let the buyer see which uncertainty remains and what would settle it.
Consensus requires material that can travel. A buying group member may need to explain the choice to a finance colleague, technical reviewer, or operating team. Gartner’s account of cross-functional buying groups and their separate digital activity makes this a real design consideration for B2B sellers. Gartner’s B2B buying guidance discusses stakeholders working across channels. I would give the primary contact a shareable summary that states the problem, the options considered, the decision criteria, the reason for the preferred option, and the remaining obligations. The summary should stand alone; colleagues should not have to reconstruct its logic from a sales call.
This does not mean every buyer wants a sales conversation. Gartner’s current guidance describes the need to combine useful digital material with human help, and notes that buyer preference for digital interaction varies with familiarity in its technology-buyer discussion. Gartner’s analysis of digital and human interactions supports giving buyers ways to proceed independently while keeping help accessible. I would let someone read, compare, and inspect practical details without booking a call. A call becomes useful when a condition specific to that buyer changes the answer or when a group needs to work through a disagreement.
Keep the sales process separate from buyer progress
A sales pipeline describes the seller’s work: contact made, meeting held, proposal sent, contract signed. A buyer journey describes the buyer’s work: problem agreed, options understood, requirements settled, choice checked, support obtained. Those records can move at different speeds. A proposal can be sent while the buying group is still debating the problem. A buyer can settle requirements before ever speaking to a seller. Confusing the two encourages a team to celebrate activity that has not made the purchase easier.
I would use seller milestones to manage workload and buyer questions to decide the next move. After a meeting, ask what the buyer can now decide that they could not decide before. If the answer is “nothing yet,” identify the open question rather than automatically scheduling a demonstration. In a B2B setting, ask which buying jobs have been settled, which have reopened, and who in the group has enough information to support the proposed choice. Gartner’s nonlinear account explains why a chronological sales stage cannot, by itself, represent this work. Gartner’s description of revisited buying jobs provides the underlying model.
Be careful with signals. A page view may suggest interest, and a request for pricing may suggest a cost question. Neither tells you whether a buyer is ready to choose. Ask a direct, respectful question when you can: “What are you trying to decide with this information?” The answer can change the response. If the person is preparing an internal budget discussion, give them the cost structure and assumptions. If they are testing whether the product fits a fixed budget, discuss the relevant scope and limits. If they are merely screening options, let them compare without creating a false sense of urgency.
This approach costs more care than sending one sequence to everyone who touches the same page. It requires sales and marketing teams to maintain clear explanations of the problem, available approaches, requirements, and limits. It also means accepting that some interactions reveal a poor fit. I would still choose it when the purchase has multiple conditions or participants, because an answer tied to the buyer’s actual decision can resolve a real obstacle. For a simple, familiar purchase, a concise path to the information and transaction may be enough; extra mapping can create work without improving the buyer’s choice.
Review the map where buyers get stuck or return
A first map is a working account, not a permanent description of all buyers. Begin with a defined purchase situation and gather the questions people actually ask in searches, conversations, and follow-up messages available to your team. Record the point at which the question arose and what answer was offered. If you have no direct account of the buyer’s purpose, label your interpretation as a hypothesis. This is especially important when you infer intent from a visit to a page that could serve several jobs.
Look for repeated returns to the same decision. A buyer who asks about fit after receiving a proposal may be revisiting requirements. A group that repeatedly requests a short explanation for colleagues may have a consensus problem. A person who moves from comparisons back to basic definitions may be reconsidering the problem itself. Gartner’s description of buyers looping among jobs makes those returns unsurprising in B2B purchases. Gartner’s nonlinear buying model describes the pattern. Your own records are needed to learn whether it occurs in your particular scenario and why.
When you change something, change the answer at the point of friction. If buyers repeatedly ask what implementation requires, make the dependencies clear before the final proposal. If they cannot compare approaches, publish the comparison in terms of the criteria they use. If a primary contact cannot explain the choice internally, create a brief they can circulate. Then check whether the same questions still recur and whether buyers can make the next decision with less backtracking. A higher click count alone cannot tell you whether the new material answered the buying question.
Do not flatten every path into an average. A short individual purchase and a multi-person organizational purchase may share the words “awareness” and “decision” while involving different work. Even within one market, a buyer who already understands a product category starts from a different question than someone encountering it for the first time. The map should be narrow enough to help you make a choice about an actual interaction. If two groups need opposite answers, make two maps or at least two clearly named routes. One universal picture may be easier to display, but it is less useful for deciding what to say.
The buyer journey should improve the next decision
A good buyer journey is a practical account of what someone must settle before purchasing, what they do to settle it, and where they cannot proceed. The three-stage model helps you see the broad path. The buying-jobs model reveals the decisions that can recur within it. A journey map adds the person, situation, actions, thoughts, and obstacles that make the model useful for one purchase. None of these frameworks can substitute for knowing what your buyer is actually trying to decide.
Start with one current buying situation. Name the actor and the unresolved question, then trace the information or conversation that would let that actor answer it. If a second person must approve the choice, make their question visible too. The best next step may be a clearer explanation, a comparison, a demonstration of one requirement, or a brief the buyer can share. Choose the smallest intervention that helps the buyer make a sound decision, and let the resulting questions revise your map.