Understand Who Makes the Buying Decision

Task

Define SaaS buyer, champion, user, and admin personas.

Summary

Identify who buys, recommends, uses, administers, approves, and influences the decision.

Define the People Who Buy, Back, Use, and Run Your SaaS

Task ID: S4-02

A SaaS company rarely sells to one person. The person who approves the expense may not be the person who pushes the purchase forward, uses the product, or administers it. This article shows how to define those roles with evidence, map the buying committee, measure coverage, and avoid personas that look polished but do not improve decisions.

The hidden reason a promising SaaS sale fails

A prospect starts a trial after seeing a demonstration. The department head likes the business case. Several employees find the product useful. The opportunity appears healthy.

Then the sale stops.

Finance has not approved the spending. Information technology has questions about identity management and data access. The employee who arranged the trial is enthusiastic but cannot persuade the executive team. The eventual users understand the features but not how the product will fit into their work. Nobody has confirmed who will configure the account after purchase.

The seller may describe this as a pricing objection, a product gap, or a slow procurement process. The deeper problem is often that the company has treated “the customer” as one person.

Business purchases are organizational decisions. The classic organizational-buying model developed by Frederick Webster and Yoram Wind treats the purchase as a process shaped by the organization, the buying group, the individuals involved, and the surrounding environment—not simply by the preferences of one buyer. Later research examining buying groups found that their composition and communication patterns vary with the organization and the purchase situation.

The operating principle is therefore simple:

Define people by the work they perform in the purchase, adoption, and operation of the product—not merely by their job titles or demographics.

For an early subscription business, the minimum useful map usually distinguishes four functions:

• the buyer, who can authorize or control the commercial commitment;
• the champion, who advances the decision inside the customer;
• the user, who must obtain value from the product;
• the administrator, who configures, governs, integrates, or supports it.

These are roles, not necessarily four separate people. One person may perform several roles in a small company. Several people may share one role in a large enterprise. HubSpot’s account-based marketing documentation, for example, allows a contact to hold more than one buying role and allows several contacts to share the same role.

The distinction matters at this stage of a SaaS company’s development because recurring revenue depends on more than closing a contract. The company must also get the account configured, help users reach value, handle support, retain the customer, and earn renewal. A persona model that explains only who signs the order is incomplete.

The four roles and the decisions they make

A useful persona is not a fictional biography. It is a concise, evidence-backed account of what a recognizable group of people is trying to accomplish, what authority they have, what worries them, what information they need, and how their behavior affects the sale or customer relationship.

Personas can help teams absorb and communicate research. Pruitt and Grudin described them as a way to convey qualitative and quantitative information while focusing product teams on real patterns of use. However, Chapman and Milham warned that invented or weakly validated personas can be difficult to verify and may encourage internal argument rather than evidence-based decisions. The practical conclusion is not to abandon personas. It is to make every important persona statement traceable to research, observed behavior, or operating data.

The buyer should not automatically be equated with the most senior person in the account. A chief executive may sponsor a purchase without controlling the detailed evaluation. A department leader may own the budget but need finance or procurement approval. In a small self-service sale, the buyer may also be the user and administrator. The map should record who actually performs the function.

The champion is more than a positive contact. Enthusiasm is evidence of preference, not influence. A credible champion has access, motivation, and the ability to move other people. The person should be willing to explain internal decision rules, introduce important stakeholders, help assemble evidence, and continue selling the idea when the vendor is not present.

The user persona should describe work rather than personality. Relevant questions include what task the person performs, how the task is done today, how success is measured, where time or quality is lost, what must change to use the product, and what first useful result would demonstrate value. Research interviews are particularly useful for learning about people’s circumstances, existing behavior, needs, and the problems they experience.

The administrator deserves a distinct persona whenever the product requires account configuration, user provisioning, access control, data governance, integrations, security review, or internal support. This person may have elevated permissions that ordinary users do not. NIST defines least privilege as limiting access to the minimum required for assigned work and recommends restricting privileged accounts to authorized people or roles. That makes the administrator’s concerns materially different from those of an ordinary user.

Slack provides a concrete illustration. Its product documentation distinguishes ordinary members from workspace administrators, workspace owners, organization administrators, and primary owners. Those roles can manage different settings, people, workspaces, and permissions; some administrative roles do not have access to billing. The lesson is not to copy Slack’s role system. It is that, as a product grows in organizational importance, “the admin” may divide into several operational and governance personas.

A persona map is not the same as a buying committee map

A persona map describes recurring role patterns across a target segment. Buying committee notes describe the specific people involved in a particular purchase.

The distinction prevents two common errors.

First, a persona should not contain facts that apply to only one named prospect. “Reports to the chief operating officer” may be a recurring pattern worth recording. “Has a difficult relationship with the current chief financial officer” belongs in account notes.

Second, buying roles are contextual. The same employee might be the buyer for a departmental analytics tool, the champion for an enterprise data platform, and a user of a separate collaboration product. Role assignments should therefore be associated with the relevant purchase or subscription decision rather than treated as permanent personal characteristics.

A practical persona map can separate functional responsibilities, motivations, decision criteria, solution requirements, and behavioral preferences. Each role record should answer the following questions in ordinary language:

Buying committee notes add the account-specific layer. For each active opportunity, record the named person, role or roles, decision authority, level of engagement, relationship strength, stated criteria, known objections, evidence still needed, and next action. Also record uncertainty. “Buyer unconfirmed” is more useful than assigning the role to the most senior contact merely to complete the field.

The relationship between the two artifacts should work as follows:

flowchart LR
    A[Sales, product, support, and usage evidence] --> B[Draft role hypotheses]
    B --> C[Interview buyers, champions, users, and admins]
    C --> D[Evidence-backed persona map]
    D --> E[Account-specific buying committee notes]
    E --> F[Sales, onboarding, product, and renewal decisions]
    F --> A

The diagram describes a continuing loop: operating evidence creates hypotheses; direct research tests them; recurring patterns become personas; individual opportunities receive committee maps; and the results of sales and customer work update the evidence.

How to build the map from evidence

Start by defining the decision that the research must support. “Understand our customers” is too broad. A stronger objective is: “Identify who approves, advances, uses, and administers the product in our primary customer segment, and determine what each role requires to support purchase, activation, and renewal.”

Next, choose the scope. Record the product, plan, customer segment, use case, company size, geography, and sales motion covered by the map. Do not combine substantially different markets because the job titles happen to look similar. A founder buying a self-service tool for a five-person firm and a technology leader sponsoring the same category in a regulated enterprise may share a need but face completely different approval and administration work.

Collect existing evidence before interviewing. Useful material includes:

• sales call notes and recordings;
• trial and demonstration participation;
• customer relationship management records;
• product analytics by account role;
• onboarding plans and implementation delays;
• support requests;
• security questionnaires;
• billing and renewal correspondence;
• win-loss findings;
• cancellation reasons;
• customer-success notes;
• interviews with customer-facing employees.

Internal knowledge is a source of hypotheses, not proof. Sales may know who attends a demonstration. Product may know who submits feature requests. Support may know who manages access. Finance may know who receives invoices. Each team sees a different part of the system.

Turn disagreements into research questions. If sales believes that operations leaders are the buyers while finance believes they are only champions, do not resolve the issue by seniority or consensus. Ask which person controlled the budget in recent purchases, who approved the final commitment, whose criteria changed the outcome, and who could have stopped the transaction.

Recruit people who have recent, relevant experience. Research guidance from the UK Government Service Manual recommends using actual or likely users, defining clear recruitment criteria, and including the different groups who need the service. It also warns that recruitment methods can introduce bias.

For this task, a balanced sample should normally include customers and lost or inactive prospects where access is possible. Current customers can explain what happened and what value followed. Lost prospects reveal missing requirements and assumptions that successful sales may conceal. Include different company sizes or use cases only when those differences are part of the scope.

Interview people about a real event rather than asking them to design an ideal sales process. A useful opening is: “Think about the last time your organization considered or bought a product like this. What happened first?” Continue chronologically.

For each participant, explore:

• their job, responsibilities, reporting relationships, and measures of success;
• how the problem became important;
• what they did before considering software;
• who first proposed change;
• who investigated alternatives;
• who defined requirements;
• who controlled the budget;
• who could approve or reject the decision;
• who influenced the preferred option;
• what evidence each person needed;
• how security, legal, procurement, or technical concerns entered;
• who configured the product;
• who used it;
• what first result mattered;
• what created hesitation or delay;
• what happened after purchase.

Do not ask only what content people say they prefer. Ask what they actually used: a peer recommendation, search result, comparison, demonstration, trial, security document, reference call, pricing page, implementation plan, or financial model. Recalled behavior is still imperfect evidence, but it is generally more useful than an abstract preference.

Analyse interviews as they occur. After the first few conversations, compare answers, identify weak questions, and adjust recruitment to fill gaps. Government service guidance recommends conducting research in rounds so the team can adapt rather than treating one large batch as fixed.

There is no universal correct interview count. In one methodological study, Hennink, Kaiser, and Marconi found that nine interviews were sufficient to identify the broad range of themes in their dataset, while substantially more were required to understand the meaning and nuance of complex themes. They explicitly cautioned that the result depends on the research purpose, population, data quality, and conceptual complexity.

For persona work, the stopping rule should therefore be evidence-based: continue until the central role definitions are stable, contradictory cases have been examined, major segments have representation, and additional interviews are no longer changing decisions. A homogeneous self-service market may require less research than an enterprise product serving several departments, countries, or regulated industries.

What credible completion looks like

The work is not complete because four attractive slides exist. It is complete when the company can use the personas to make different and better decisions.

The minimum evidence should include a persona map and buying committee notes, supported by an interview record or research repository. The working target of defining the buyer, champion, and user is a useful checkpoint, not a universal benchmark. An administrator must also be defined whenever configuration, governance, integration, security, provisioning, or internal support materially affects purchase or customer success.

A credible persona map should show:

• the scope and segment to which it applies;
• the four roles and any additional roles that repeatedly matter;
• the responsibilities, triggers, desired results, concerns, authority, and evidence needs of each role;
• the purchase, onboarding, use, renewal, and expansion stages in which each role participates;
• evidence references and confidence levels;
• meaningful variations and unresolved questions;
• the date of validation and the owner responsible for updating it.

A credible set of buying committee notes should show, for each material opportunity or account:

• which required roles have been identified;
• whether each assignment is confirmed or assumed;
• who holds approval, influence, operational, and administrative authority;
• which people are engaged;
• where access is missing;
• what objections or requirements remain unresolved;
• whether the internal advocate is taking observable action;
• what must happen next.

Persona coverage should measure more than whether a persona has a name. A basic formula is:

Persona coverage = evidence-backed role-and-segment cells completed ÷ role-and-segment cells required

Suppose the company serves two materially different segments and requires buyer, champion, user, and administrator personas in each. That creates eight role-and-segment cells. If six contain validated evidence and two remain internal assumptions, evidence-backed coverage is 75 percent.

That number is useful only when the completion standard is explicit. A team can inflate coverage by writing generic descriptions. A stronger scoring scale separates evidence levels:

Useful supporting measures include the percentage of qualified opportunities with a confirmed buyer, champion, user, and administrator; the percentage of trials with an identified user outcome; the percentage of implementation-heavy deals with an administrator involved before close; time to first value by role or segment; support issues attributable to configuration or access; and win, loss, churn, or renewal reasons linked to missing stakeholder coverage.

These are diagnostic measures, not industry benchmarks. The appropriate target depends on contract value, sales motion, product complexity, customer risk, implementation effort, and the quality of the underlying data.

Where persona work becomes misleading

The most common failure is the fictional biography. A name, stock photograph, age, hobbies, and invented quotation can make a persona memorable without making it accurate. Include demographic or personal information only when evidence shows that it changes the purchase, use, or administration of the product.

The second failure is title substitution. “Vice president of operations” is a title, not a buying role. In one account, that person may own the budget. In another, the same title may be an influencer while finance makes the final decision. Research on organizational buying has long shown that buying-group structure depends on the purchase and organizational setting.

The third failure is confusing a friendly user with a champion. A user may love the product but lack access to senior leaders, credibility with finance, or willingness to take political risk. Champion status should be supported by behavior: introductions, internal coordination, information sharing, case-building, and progress when the seller is absent.

The fourth is ignoring administration until after the contract. The product may be valuable yet difficult to approve or operate. Questions about single sign-on, permissions, data migration, integration, auditability, account ownership, user removal, and internal support can determine whether the customer activates successfully. Slack’s separation of member, administrator, owner, and primary-owner permissions illustrates why operational authority cannot always be reduced to a generic “user” persona.

The fifth is over-segmentation. A company can create dozens of personas by industry, title, company size, motivation, and product plan. The result becomes impossible to use. Split a persona only when the difference changes a meaningful decision: the problem, authority, criteria, product requirements, onboarding, message, channel, or measure of success.

The sixth is treating role assignments as permanent. A person’s role can change by product, purchase, renewal, or expansion. Record the role in the context of a specific decision and date it.

The seventh is counting interviews instead of testing coverage. A dozen conversations with enthusiastic users do not establish what buyers or administrators require. Sample composition matters as much as sample size. Qualitative saturation can also occur at different times for simple observations and complex motivations.

The final failure is failing to connect the research to operations. A persona deck that does not change qualification, demonstrations, trial design, onboarding, product permissions, documentation, customer-success plans, or renewal reviews is communication material rather than an operating tool.

The four-role model also has limits. In low-cost self-service SaaS, one person may buy, champion, use, and administer the product in minutes. The company should not impose an enterprise process where none exists. At the other extreme, expensive or high-risk software may require separate economic buyers, executive sponsors, procurement staff, legal reviewers, security specialists, data owners, implementation leaders, billing contacts, and departmental administrators. The correct map is the smallest model that explains the real decision and customer work.

The decision that should now be clearer

Before the company depends on its persona work, it should be able to answer four questions for the primary segment without guessing:

Who can authorize the purchase? Who will advance it internally? Who must obtain value from the product? Who must make it work safely and reliably?

The answers should appear consistently in the persona map, opportunity records, trial plans, onboarding work, and customer-success practices. Important claims should be tied to direct research or operating evidence. Unknowns should remain visible rather than being filled with convenient assumptions.

When that standard is met, the company has more than four character sketches. It has a working model of how a subscription is bought, supported, adopted, and kept.

That model should make several decisions easier: whom marketing must reach, whom sales must involve, what a demonstration or trial must prove, what the product must make simple, what administrators require before rollout, and what customer success must confirm before renewal.

Sources

Primary sources

• HubSpot, “Set up account-based marketing in HubSpot,” updated October 2025.
• Slack, “Types of roles in Slack.”
• Slack, “Change a member’s role.”
• Slack, “Understand the Primary Owner role.”
• National Institute of Standards and Technology, “Least Privilege” glossary definition.
• National Institute of Standards and Technology, Protecting Controlled Unclassified Information in Nonfederal Systems and Organizations, Special Publication 800-171 Revision 3.
• UK Government Service Manual, “Finding participants for user research.”
• UK Government Service Manual, “Using in-depth interviews.”
• UK Government Service Manual, “Plan user research for your service.”

Open research

• Webster, Frederick E., Jr., and Yoram Wind, “A General Model for Understanding Organizational Buying Behavior,” Journal of Marketing, 1972.
• Johnston, Wesley J., and Thomas V. Bonoma, “The Buying Center: Structure and Interaction Patterns,” Journal of Marketing, 1981.
• Pruitt, John, and Jonathan Grudin, “Personas: Practice and Theory,” 2003.
• Chapman, Christopher N., and Russell P. Milham, “The Personas’ New Clothes: Methodological and Practical Arguments against a Popular Method,” 2006.
• Hennink, Monique M., Bonnie N. Kaiser, and Vincent C. Marconi, “Code Saturation Versus Meaning Saturation: How Many Interviews Are Enough?” Qualitative Health Research, 2017.