A method for business software buyer personas that record authority, not personality

Useful buyer personas are compact records of behaviour and authority found in research. They are not imaginary names attached to stock photographs. For business software, a role-based profile is usually more reliable because the user, administrator, approver and budget holder can want different outcomes.

This article provides a method only. It does not report completed interviews or claim that the example fields describe a real English market segment.

What to take away

Build buyer profiles only after research, and label pre-observation profiles as hypotheses.
Describe authority, decisions and evidence needs rather than personality traits or demographics.
Organisation size does not determine the buying process; capture the observed approval path.
Preserve disagreement between people with the same job title if it could break the product.
Protect participants by minimising data and publishing only detail needed for the product decision.

Build profiles after research

The GOV.UK Service Manual says teams can create personas or profiles as they learn about users. That order matters. A profile written before observation is a hypothesis and should be labelled as one.

Evidence-first persona workflow

Observe recent work sessions
Note task, trigger, tools, hand-offs
Record decision rights and consequences
Keep source code with each note
Group only when decisions change

Start with evidence from recent work. For each participant, note the task, trigger, tools used, hand-offs, decision rights and consequence of delay or error. Keep the source code or session reference with the note. Group records only when the similarities change a product or commercial decision.

Describe authority, not personality

A concise profile can contain:

role in the workflow and decisions the person can make;
frequency and urgency of the task;
current records and systems;
people who supply or approve information;
evidence needed before a trial, purchase or renewal;
access and support requirements;
observed failure points and workarounds;
conditions that would rule the product out.

Traits such as being busy, innovative or resistant to change are too vague unless they come from evidence and lead to a specific design choice. Demographics belong only when they affect the task, access or research question. Decorative details make a profile memorable at the cost of accuracy.

Keep business structure in view

The UK Business Data Survey 2026 covers organisations handling digitised data and reports differences in data practices by business size. Its findings are UK-wide and apply to the study's defined population. They can help a team ask whether data responsibility or integration capacity differs across segments, but they cannot supply a ready-made persona.

Organisation size alone does not determine the buying process. A ten-person regulated service may require external security review, while a larger owner-managed business may decide centrally. Capture the observed approval path rather than guessing it from employee numbers.

Preserve disagreement

Two people with the same job title may use different processes because of location, client rules or management practice. Do not average away a difference that could break the product. Create variants only when there is enough evidence to explain the split.

The Service Manual's analysis guidance recommends comparing observations promptly and keeping interpretation distinct. A practical profile can show supporting sessions, contrary cases and confidence. This makes it possible for another editor to check why a statement appears.

Protect the people behind the profile

Combining role, town, sector and a distinctive incident can identify someone even when their name is removed. GOV.UK's research privacy guidance recommends minimising participant data, controlling access and anonymising shared extracts.

Publish only the detail needed for the product decision. Store consent and research records under an approved retention plan, and obtain qualified data-protection advice for the actual study.

Review each persona after another research round or a material change in the workflow. Retire a profile when its supporting evidence no longer matches the audience rather than rewriting history to fit a new proposition.

Before you act

Gather evidence from recent work before writing any profile.
Record task, trigger, tools, hand-offs, decision rights and consequences.
Group records only when similarities change a product or commercial decision.
Include supporting sessions, contrary cases and confidence in each profile.
Minimise participant data and control access to research records.
Review each persona after another research round or workflow change.

Common questions

When should a team create buyer personas?

After research, according to the GOV.UK Service Manual, which says teams can create personas or profiles as they learn about users. A profile written before observation is a hypothesis and should be labelled as one. Start with evidence from recent work and keep source references with each note.

What should a concise buyer profile contain?

It can contain the role in the workflow and decisions the person can make. It can also list task frequency, current systems, approvers, evidence needed before purchase, access requirements, failure points and conditions that rule the product out.

How can teams protect the people behind a profile?

Combining role, town, sector and a distinctive incident can identify someone even without a name. GOV.UK privacy guidance recommends minimising participant data, controlling access and anonymising shared extracts. Publish only detail needed for the product decision, store consent under an approved retention plan and obtain qualified data-protection advice.