Payroll buyer personas anchored to recurring duties, not invented names

A persona is a compact research tool, not a fictional biography. For payroll software, it should capture a recognisable decision context, responsibilities, workflow and evidence. A made-up name, stock photograph and confident quotation can make unsupported assumptions look real.

Separate roles before describing people

One purchase can involve several perspectives:

Role	Decision it influences	Evidence to collect
Payroll operator	Whether the workflow is usable	Run observation, errors and workarounds
Finance approver	Whether control and cost are acceptable	Approval process and budget record
Adviser or bureau lead	Whether many clients can be served	Client volumes, exceptions and permissions
IT or security reviewer	Whether data and access are controlled	Supplier questions and rejected risks
Business owner	Whether change is worth disruption	Trigger, alternative and signing criteria
Employee	Whether outputs are understandable and accessible	Support contacts and document-use testing

Do not merge these into a single "small-business owner" if different people perform the work.

Anchor the persona to recurring duties

HMRC says businesses running payroll themselves generally report employee payments and deductions on or before payday. The PAYE employer guide provides the factual backdrop, but it does not reveal how a particular organisation divides the work.

The Pensions Regulator's ongoing-duties guidance shows that age and earnings monitoring, contributions, requests and records continue after setup. Observe which role handles each task and where responsibility is uncertain.

Use a persona evidence card

Give each persona a functional label such as "monthly employer payroll operator" or "multi-client bureau manager". Record:

• supported segment and explicit exclusions;
• employer, employee and PAYE-scheme ranges observed;
• payroll frequencies and sources of variable data;
• current tools and hand-offs;
• repeated problems and their consequences;
• purchase trigger and alternatives considered;
• approval, security and migration requirements;
• evidence dates, participant count and confidence level.

Keep direct quotations only when they were recorded with permission. Otherwise paraphrase and attach the underlying research reference.

Recruit beyond enthusiastic customers

The GOV.UK Service Manual advises that participants should be actual or likely users and that research should include a variety of people, including those who need support. Its participant recruitment guidance also recommends using existing data and guarding against recruitment bias.

Include non-buyers, recent leavers, users of competing approaches and people with access needs. An existing-customer-only persona can hide switching barriers and reasons for rejection.

Keep personas provisional

Mark every field as observed, inferred or unknown. Review the card after tax-year change, a new segment, a product shift or conflicting interviews. Retire a persona when behaviour no longer clusters.

The finished artefact should help decide what to build, how to explain it and whom not to target. If a colourful detail cannot change one of those decisions, remove it.

Link every persona to a buying stage

Add the event that brings the role into a decision. An operator might raise recurring corrections, while a finance lead becomes involved at budget approval and an IT reviewer appears during supplier assessment. Record what evidence moves each role forward and what sends the purchase back.

Then test the card against a real proposition. Give participants a neutral description, ask them to explain the likely next action and observe a safe prototype task. Note where their language, sequence or responsibility differs from the card.

Avoid using personas to predict an individual. They summarise patterns within a researched context and should not be used to infer competence, risk or preferences from age, region or job title. Keep the anonymised research trail available to the team, but share only the minimum personal information needed for the stated purpose.