B2B buying process: the six buying jobs, who is involved and how to m...

The B2B buying process is the set of steps a company goes through to choose and buy a product or service from another company. Someone decides a problem is worth solving, a group looks at options, agrees on what it needs, picks a supplier, checks that choice and gets everyone to sign off. Procurement, legal and security reviews then turn the choice into a contract. For a seller, three things matter most: several people are involved, they rarely move in a straight line, and much of the work happens when no salesperson is present.

Gartner describes the decision as six "buying jobs" that a buying group has to complete, often looping back to earlier ones rather than moving in order. Gartner: B2B buying journey The contract steps that follow, from requests for proposal to supplier setup, are covered in our procurement process guide. This page covers the decision itself and how to learn how your own customers make it.

The six buying jobs

Gartner sums up each job with the buyer's own question:

Problem identification: "We need to do something."
Solution exploration: "What's out there to solve our problem?"
Requirements building: "What exactly do we need the purchase to do?"
Supplier selection: "Does this do what we want it to do?"
Validation: "We think we know the right answer, but we need to be sure."
Consensus creation: "We need to get everyone on board."

Gartner says buyers revisit these jobs as they go, and that buying group members may have different goals and needs as they do their own research. A buyer may be checking references (validation) when a new stakeholder joins and reopens the requirements. Map where each deal is by job, not by how many meetings it has had.

Buying job	What the seller can do	What to ask in research
Problem identification	Describe the problem in the buyer's words	"What happened that made this a priority?"
Solution exploration	Make clear public information easy to find	"What else did you consider, including doing nothing or building it yourselves?"
Requirements building	Help the buyer define needs, not list features	"Who wrote the requirements, and where did they come from?"
Supplier selection	Demonstrate on the buyer's own workflow	"How did vendors get on and off the list?"
Validation	Offer references and pilots that match the buyer	"What did you need to see before you were sure?"
Consensus creation	Give the champion material they can forward	"Who could have stopped this, and what did they need?"

Who is in the buying group

The people who complete these jobs usually include someone who will use the product, someone who owns the workflow, an internal champion, someone who approves the spending, and reviewers such as IT, security, finance, legal and procurement. One person can hold several roles. In a small company the founder may hold all of them. How to interview B2B users, buyers and champions covers how to tell who does what without guessing from job titles, and our buyer persona guide covers turning those roles into profiles.

A worked example: selling a scheduling tool to hospitals

Suppose a startup sells software that schedules the staff who move patients between departments inside a hospital. The company, the hospitals and the findings below are hypothetical. The founders assumed that the patient transport manager was the buyer and that a sale would take three months. After they interviewed people at five hospitals that had bought similar tools, their map looked different:

Problem identification. At four of the five hospitals, the trigger was nursing leadership complaining about patients waiting for transport after discharge, not the transport manager.
Solution exploration. The transport manager asked peers at other hospitals what they used. IT asked early whether any option connected to the electronic health record.
Requirements building. IT and security wrote most of the requirements, starting from their standard vendor security questionnaire.
Supplier selection. Two or three vendors demonstrated to a small group, which scored them.
Validation. Buyers called references at hospitals of similar size, and the security review ran in parallel.
Consensus creation. A committee that reviews new purchases, and finance, had to approve, and the contract went through supply chain.

The revised picture: the transport manager is the champion, a vice president of operations approves, and the security review is the longest step. The founders changed their forecast from three months to six to nine, started the security questionnaire in the first meeting and wrote a one-page summary the transport manager could send to nursing leadership.

How to learn a buyer's real process

Each company has its own version, and the details that decide a deal, such as who approves spending above a threshold or how long security review takes, are seldom published. Interviews with people who took part are the fastest way to learn them.

Ask about a recent purchase, not the general process. "Walk me through the last time you bought something like this" gets facts. "How do you usually buy software?" gets the official version.
Talk to more than one role at the same company. The champion, the approver and the security reviewer remember different parts of the same deal.
Cover several companies. Five buying stories of the same kind show you the common pattern and the exceptions. Count companies, not people.
Include buyers who chose someone else or nothing. Win-loss analysis and interviews with customers who chose another product cover how.
Record dates and documents. Note when each job started and ended, and which documents were involved, such as a requirements list, a security questionnaire or a business case.

Questions that work in most B2B markets:

Take me back to the moment this became a priority. What happened?
Who was in the first conversation about it, and who joined later?
What did you look at before talking to any vendor?
Who wrote the requirements? Did you start from a template?
How many vendors did you consider, and how did you narrow the list?
What did you need to check before you were confident, and who did the checking?
Who could have said no at the end, and what did they ask for?
How long did security, legal and procurement take, and what slowed them down?
If you bought again tomorrow, what would you do differently?

Sales discovery questions adapts some of these for live deals.

Turn the map into a sales process

Once you have five or more buying stories, write down for each buying job what the buyer must have done before the deal can move on, and use that in forecasting. For the hospital example, a rule might be: do not forecast a close date until the security review has started. Then list the material each role needs at each job, and the job where deals most often loop back. That is where a missing document or an absent stakeholder usually costs the most time.

Your next step

Take your last three won deals and two lost ones. For each, write the six buying jobs, who did each one and roughly when. Mark the blanks; those are the questions for your interviews.

If you need to reach people at companies you sell to but have no contacts there, Instant Expert can find people who match a description you write, such as "IT security reviewers at mid-size hospitals." You review who it finds, it sends your invitations, and you pay only for calls that get booked. The directory pages for experts in selling to hospitals and enterprise SaaS procurement experts are one place to start.