B2B buyer persona: who signs, who blocks, who uses
A B2B buyer persona for agencies, dev shops and consultancies: the three roles in buying a service, a filled-in template and a test for your proposal.
If your firm has personas from a workshop, they may look like this: “Mark, 42, marketing director, likes cycling.” A description like that is easy to remember, but it’s hard to point to a proposal it changed. In a service firm a purchase usually goes through several people, and a B2B buyer persona built from a job title and an age doesn’t tell you what each of them will ask.
In this post I’ll show how to describe a persona for each of the three roles in buying a service: who signs, who can block the purchase and who will use the service. You’ll get a template with a filled-in example, three steps for gathering the data, a test for your proposal and an example from our own firm, including what we don’t know yet.
What a B2B buyer persona is in a service firm
A B2B buyer persona describes a person at the client’s company through their role in the purchase, one role or several. Among other things, it covers who the person is, what they’re accountable for, how they judge success, what objections they have and what proof convinces them. An ICP (ideal customer profile) describes the company that buys; a persona describes a person in that company. In a service firm you tie a persona to one service and one ICP.
If you don’t have an ICP yet, start there. I described how in How to create an ICP for a B2B service firm. Here I assume you know which companies you sell to and want to work out who you talk to inside them.
A persona’s age and hobbies won’t tell you why a purchase stalled
Three things about each person in a purchase change a proposal the most: how they’ll judge whether the service worked, what objections they have and what proof will convince them. Age and hobbies don’t tell you that. A job title tells you a bit more, but not enough. Take a marketing director: in one company they sign the contract with the agency themselves, in another they only work with an agency the board chose, and with the same title they ask different questions.
This matters because B2B purchases often stall partway. According to Forrester’s 2024 report, 86% of B2B purchases stall during the buying process (Forrester, 2024). To find out whose question a purchase got stuck on, you need to know who played which role in it.
That’s why I recommend starting with the question of what role a person had in the purchase. You add the job title later, so you can recognize them at the client’s company.
Buying a service involves three roles: who signs, who blocks, who uses
According to Forrester, a typical B2B buying decision now involves 13 people inside the buying company and 9 external influencers, and even more for more complex purchases (Forrester, 2026). In the same press release, Forrester analyst Barbara Winters says that as buying groups grow, B2B marketers need insight specific to each role. The press release doesn’t break these numbers out for small firms. In my view, at a client with a dozen or so employees fewer people take part in a purchase. Whatever their number, everyone at the client’s company who has something to do in the purchase, beyond giving advice, fits into at least one of three roles. That’s why three roles, each with its own questions, are enough for a small service firm. People who only give advice, from the client’s company or from outside, don’t get their own persona: you record their influence in the “How they buy” and “What convinces them” fields.
| Role | Who it is | Who it tends to be | What they ask |
|---|---|---|---|
| Signs | the person who approves the budget and signs the contract | in a small firm usually the owner, in a larger one a department head or the board | will this pay off, and will the vendor deliver |
| Blocks | the person who, beyond budget and contract, has to approve or provide something (system access, legal sign-off, data) before the purchase can go ahead, so they can stop or delay it | the IT department, a lawyer or a partner | what can go wrong and who will answer for it |
| Uses | the person who, after signing, works with the vendor or with the result of the service day to day | the client’s team that works with the vendor | will this add to their work or take work off them |
In my view, the third role carries more weight in services than when buying software. With software, the user judges a tool. With a service, they judge the people they work with for the whole project: whether they reply, whether they understand the client’s business, whether they keep adding tasks to the user’s plate. If the person who signs asks someone’s opinion at renewal time, it will be this person. Sometimes the future user is also the one who persuades the rest of the company to buy.
One person can have several roles. In a five-person firm the owner often signs and uses at the same time. Then you describe one persona with two roles, but you keep the questions of both.
Example: three roles in buying our service
B2BForce sells small service firms the setup of its repository in Claude Code (one of the AI agents) for a team of a few people. The repository itself is free; the setup is paid. The roles below come from our sales documents. We have no documented engagements to draw on, because we don’t have case studies yet. So each of the three roles is an assumption for now.
For us, the person who signs is the owner or the head of operations or marketing: that’s what we wrote in our ICP. In the first call with a prospect we check this directly by asking whether we’re talking to the person who holds the budget. We prepare for the objections “We’ll do it ourselves from the free repo”, “Is this lock-in?” and “Too expensive”.
Three people from the client’s team use the service: the package covers setting it up for them, and they have to find time for sessions within five working days. In the business plan for our new offer we wrote that the buyer’s main resistance is the question: “what if the team doesn’t use it?”. The person who signs asks it, but it’s about the people who use the service. That’s why the new version of the offer includes a 30-day refund guarantee on the setup.
We know the least about the “blocks” role, because without case studies we have no documented purchase in which it showed up. Our documents point to three places where the purchase can stall. The firm needs a GitHub organization account or has to agree to create one. Each person needs a Claude plan that includes Claude Code. And when we describe how we differ from competitors, we ourselves write about the risk to clients’ intellectual property with tools hosted in someone else’s cloud, so the same question can be asked about us. Behind each of these places there may be someone who says “no”: the IT person who creates accounts and assigns plans, or a partner who looks after client contracts.
We’ve written down the most about the person who signs, because that’s who we talk to. The role that can stop the purchase doesn’t appear in our first-call script yet, so we want to check it first. If it’s similar for you, start gathering data with the “blocks” role.
Persona template: eight fields you use in sales
Each field below is useful when writing a proposal, in a sales call or in marketing. If you can’t connect a field to any of these, you don’t need it.
| Field | What to write | What it’s for |
|---|---|---|
| Role in the purchase | signs, blocks or uses (can be more than one) | who to talk to and about what |
| Who they are | job title, who they report to, what team they run | recognizing this person at the client’s company |
| What they’re accountable for | what they’re held responsible for | the language of your proposal |
| What they judge success by | one or two sentences, ideally in their words | goals in the proposal and in review meetings |
| How they buy | fast or after deliberation, tender or referral, what they read first | your call plan and the order of your proposal |
| Objections in their words | 2–4 sentences, including from other people in this role | the questions section of your proposal, preparing for a call |
| What convinces them | type of proof: reference, example, scope, guarantee | choosing proof for the proposal |
| Where to reach them | where they look for information and what they ignore | marketing channels |
Below is the template filled in across all eight fields. The example comes from the sample files in the B2BForce repo and describes a made-up 14-person firm that sells platform migration and release automation to logistics operators. The firm, the person and the numbers are fictional, and the objections are quoted as written in the file.
| Field | Signs: CTO at a logistics operator (fictional example) |
|---|---|
| Role in the purchase | signs and holds the budget up to a threshold; above it the finance director signs too |
| Who they are | runs an engineering team of 8–40, reports to the COO or CEO; came up through engineering and still reads pull requests; 5 to 15 years at the company, so the platform’s history is personal |
| What they’re accountable for | shipping the roadmap the business agreed to, and not being the reason a customer leaves; those two pull against each other every release weekend |
| What they judge success by | their two senior engineers work on the roadmap instead of regression testing; they can take a week off during a release cycle without arranging cover |
| How they buy | reactive, and fast once something has happened; at this size they won’t run a formal RFP, but they will ask for a reference call with someone who had the same problem; they read the scope before the price |
| Objections in their words | “I have budget for people, not for consultants.” “How is this different from the pipeline my team could build in a quiet month?” “What happens when you leave?” |
| What convinces them | a named engagement at a comparable operator, the handover to their team stated concretely, and an honest out-of-scope list; a proposal that promises a defect-rate percentage reads as a vendor who doesn’t understand where the number comes from |
| Where to reach them | industry operations conferences, conversations with other logistics CTOs, long-form writing that names the weekend release problem; not responsive to cold email sequences that open with a generic efficiency claim |
The repo example describes only the CTO. It doesn’t give the finance director’s questions, and the people who work with the vendor there are the engineers who run releases today. Under this method, the finance director’s questions would go into the CTO’s objections, and one of the engineers would get a separate persona.
A proposal for this person has to answer “What happens when you leave?”, for example with the handover description from the “What convinces them” field. Without that answer it will lose with them regardless of price.
How to build personas and test your proposal in four steps
Steps 1–3 fill in the template fields; step 4 tests your proposal against them. Work on one service at a time.
- List the people in your recent purchases. Input: contracts, email threads and notes from the last 3–5 purchases of this service. For each purchase, write down who signed, who had to approve or provide something, and who then worked with your team or with the result of your work. If several people held one role, for example IT and a lawyer in the “blocks” role or several developers in the “uses” role, pick the one who had the most influence on the purchase or the renewal. Output: the “Role in the purchase” and “Who they are” fields.
- Collect each role’s questions and objections. Input: emails with questions from before signing, sales call notes, questions from RFPs and short conversations with two or three clients. A good question for a client: “Who else had to agree, and what did they ask?” Also ask how they looked for a vendor, who advised them and how they heard about you. Add the questions of other people in the same role to the chosen persona’s objections. Output: the “Objections in their words”, “What they’re accountable for”, “How they buy” and “Where to reach them” fields.
- Work out what each role judges success by. Input: conversations after finished projects, renewals and cancellations, emails with praise and complaints. Ask what decided the choice of your firm. Output: the “What they judge success by” and “What convinces them” fields.
- Test your latest proposal. Input: the personas from steps 1–3 and the last proposal you sent. For each persona, check whether the proposal names the goal this person will judge success by, and whether they’ll find an answer to their objections and proof they trust. Output: a list of changes to the proposal.
Steps 1 and 4 rely on documents you already have. Steps 2 and 3 need conversations with clients, and in practice those spread over several weeks, because clients have their own calendars. At the end you’ll have one to three personas for this service. More rarely helps, because you can’t write a proposal for five people at once anyway.
When to adjust the method: very small clients, new services, old personas
At very small clients one person does everything: the owner signs, uses the service and approves system access themselves. Then you have one persona with three roles.
When a service is new and there are no purchases yet, steps 1 and 3 have no input, and step 2 relies only on sales calls. Write your personas down as assumptions from documents, as we did in the example above, and correct them after every sales call. Also keep in mind that a persona nobody updates describes how clients bought when it was written.
Frequently asked questions
How is a buyer persona different from an ICP?
An ICP describes the company that buys the service and the situation in which it starts looking for help. A persona describes a person in that company and their role in the purchase. The ICP comes first, then the personas for that ICP.
How many buyer personas does a service firm need?
I recommend one to three per service, one for each role that a separate person holds at your clients. If the same person signs and uses the service at your clients, two are enough.
How often should you update buyer personas?
After events rather than on a calendar: after a lost deal, after a client renews or cancels, and after the service changes. Each of these events brings new objections or new success criteria to write down.
Personas in the B2BForce repo
The B2BForce repository is a shared folder of files with a change history and ready-made instructions for an AI agent such as Claude Code, Cursor or Codex. We call these instructions skills. The marketing-icp skill creates one ICP and one to three personas for one service.
Each persona has a decision_role field with the role in the purchase (for example economic_buyer, gatekeeper, user_buyer, champion) and fields for the success definition, fears, objections and types of proof. In my view, the repo’s values map onto the roles in this post like this: economic_buyer is “signs”, gatekeeper is “blocks”, user_buyer is “uses”, and champion is usually a user who persuades the rest of the company. In the schema the field takes one value from the list, so for a person with several roles I enter the one that most affects the purchase and describe the others in the body of the persona.
Personas go into workspace/marketing/icp/personas/. Before the agent prepares marketing copy or a sales email sequence, the repo checks whether the service has an ICP and at least one persona, and stops the work without them. The repo is released under the MIT license: github.com/b2bforce/b2bforce. More on the open source page.
Summary
Describe roles in the purchase rather than age and hobbies, because roles are what change a proposal. To start, take the last 3–5 purchases of one service and for each one write down who signed, who could have blocked it and who used the service afterwards. If you don’t know what the person in one of the roles asked, start your client conversations with that role.
Every method on this blog also runs as a skill in the open-source B2BForce repo. About the repo