Researching payroll software users around payday rather than from an adoption count

Good payroll audience research begins with a completed pay cycle, not a demographic sketch. The aim is to find a group that performs similar work, experiences a repeated problem, can authorise change and values an outcome enough to adopt or buy.

An England-wide label is too broad for product decisions. A five-person employer running a monthly director payroll, a care provider managing variable weekly hours and an accountancy practice processing 150 client payrolls may all use PAYE software, but their data, permissions, deadlines and support needs differ sharply.

This guide explains how to define those audiences, recruit evidence, conduct interviews, choose survey tools and compare existing offers. The official and provider sources were checked on 5 September 2026. Product features and official rules must be reopened before publication or a purchasing decision.

Map the service around payday

HMRC's PAYE guide for employers says an employer normally operates PAYE as part of payroll. If it runs payroll itself, it generally reports employees' payments and deductions to HMRC on or before each payday.

Use that event as the research anchor. Ask participants to reconstruct:

1. how worker and pay data enters the process;
2. who checks changes and exceptions;
3. how calculations are reviewed;
4. who approves pay and reports;
5. how submission outcomes are recorded;
6. how employees receive documents or answers;
7. what happens when something is wrong.

The workflow may involve a payroll operator, finance reviewer, business owner, HR colleague, accountant, IT approver and individual workers. Their goals overlap without being identical. Interviewing only the contract signer will miss operational detail; interviewing only the daily user will miss procurement and budget barriers.

HMRC's payroll information guidance sets out FPS and EPS information, including employer and employee details, pay, deductions, starters, leavers and year-end matters. It can inform the process map, but researchers should not ask participants to reveal identifiable payroll records. Use redacted examples or demonstrations with safe test data.

Build segments from observable conditions

Start by separating the way payroll is operated:

• an employer uses software directly;
• a payroll bureau or accountancy practice runs it for clients;
• a managed service combines technology and operational delivery;
• a larger employer uses a module within a wider system;
• another software platform embeds payroll functions.

Then add conditions that change the job. Useful variables include active employee count, number of PAYE schemes, weekly or monthly frequency, variable and irregular pay, several sites, approval layers, starters and leavers, pension providers, time systems and accounting integrations.

HMRC's software selection guidance notes that products may differ in their support for payslips, pension deductions, pension payments, different pay periods and particular reports. These are research prompts rather than a complete product specification.

The Pensions Regulator adds another dimension. Its ongoing employer duties page describes repeated age and earnings monitoring, contributions, join and leave requests, records and re-enrolment. Ask which person and system deals with each step for the named pension arrangement.

Use official data as a sampling frame, not an adoption count

The ONS UK business: activity, size and location dataset supplies enterprise and local-unit counts by geography, industry and employment size. It can show how registered businesses are distributed across England and help prevent a sample concentrated only in London or one industry.

It does not identify payroll-software buyers. Its VAT and/or PAYE population includes organisations that may not employ staff, while one enterprise can have several local units. Some employers outsource, some use free tools and others buy payroll within another suite.

Record the ONS edition, table, unit and filters used. If recruitment quotas follow regional or industry shares, explain whether they describe enterprises, establishments or another population. Do not weight a small convenience survey until a statistician has assessed whether the frame and responses support that treatment.

Write research questions before recruiting

The GOV.UK Service Manual's research planning guidance recommends turning assumptions into research questions and choosing methods that can answer them. Useful payroll questions might be:

• Which event causes employers to look for a new system?
• Where do operators detect input errors, and how are they corrected?
• What evidence makes a finance or security reviewer approve a supplier?
• Which pension-data failures create repeat work?
• What stops a bureau from migrating more clients?
• Which outcomes cause customers to renew after a tax-year change?

Avoid "Would you use an easier payroll tool?" It supplies no shared definition of easier and encourages agreement. Ask instead about the last occasion, the alternative chosen and the consequence.

Tie each question to a decision. If the team cannot explain what it would change after either answer, the research question is probably too vague.

Recruit actual and likely users

The Service Manual says research participants should be actual or likely users. Its recruitment guidance recommends using existing evidence, setting criteria, including people with varied needs and watching for bias.

Build a screening table with required and excluded characteristics. A bureau study might specify job responsibility, number of active employer clients, dominant pay frequency, current platform and recent involvement in a migration or exception. An employer study may require direct participation in two recent payroll cycles.

Recruit through several routes where possible. Existing customers are accessible but unusually familiar with the product. Professional groups may overrepresent engaged practitioners. Paid panels may struggle to verify specialist responsibility. Referrals can reproduce the same network.

Include people who:

• chose another supplier;
• renewed their current product;
• use a bureau instead of software directly;
• attempted and abandoned a switch;
• need assistive technology or support;
• work outside the researcher's nearest region.

Do not publish a fixed participant count as a universal rule. The Service Manual notes that small qualitative rounds and surveys have different sample requirements. Use iterative interviews to understand behaviour; use a properly framed survey when estimating how frequently defined responses occur.

Conduct interviews around evidence

Ask participants to show a safe reconstruction of their last run. Follow the sequence and pause at exceptions. Useful prompts cover the most recent late input, a corrected calculation, pension-file handling, an HMRC acknowledgement, the last support contact and the previous purchasing decision.

The Service Manual's in-depth interview guidance recommends current or likely users, accessible arrangements, planned recording and a note-taker. A pilot session can reveal questions that imply an answer or assume an unfamiliar term.

Separate three kinds of statement in the notes:

• observed behaviour, seen during the session or supported by an artefact;
• participant report, describing an event not directly observed;
• researcher inference, an interpretation to be tested later.

Do not turn one memorable quotation into a market truth. Look for patterns across similar operating contexts and preserve contradictory cases.

Protect participant and payroll information

Payroll studies can attract more personal data than the research needs. The Service Manual's participant privacy guidance covers informed consent, minimisation, secure handling, limited sharing and deletion when details are no longer required.

Prepare an information sheet that explains collection, recording, use, access, retention and withdrawal. Keep recruitment contact details apart from research notes where practical. Remove employee names, National Insurance numbers, bank details, pay values and other identifying fields from demonstrations.

If the product team already controls real customer payroll data, that does not automatically authorise re-use for audience research. Check purpose, role, contract and internal governance with the appropriate data-protection lead.

Turn evidence into personas without fiction

Create role-based evidence cards only after patterns emerge. A card for a "multi-client bureau operator" can summarise client volume range, pay cadence, input sources, repeated exceptions, decision criteria and confidence. It does not need a made-up family, favourite drink or invented quotation.

Label each field as observed, inferred or unknown. Link it to anonymised sessions, dates and sample characteristics. State where the card does not apply. Review it when new evidence conflicts or the product moves to a different segment.

Several roles may belong to one buying group. Maintain separate cards for daily operator, finance approver, owner and security reviewer if their decisions differ. Then map the hand-offs between them.

Choose a survey tool after designing the study

A survey can test how often a defined behaviour or need appears in a suitable sample. It cannot compensate for ambiguous wording, self-selection or an unverifiable respondent role.

Common options include:

• Microsoft Forms, with documented Excel and Microsoft 365 storage workflows;
• Google Forms, with collaborative editing, response summaries and Google Sheets;
• SurveyMonkey, with plan-dependent collectors, logic, exports and analysis;
• Jisc Online Surveys, with research-oriented tiers, response analysis and several export formats.

These links confirm selected current provider statements, not suitability for a particular organisation. Check account ownership, respondent authentication, accessibility, logic, export, permissions, retention, sub-processors, contract, price and deletion before collecting anything.

Pilot the questionnaire with people who match the audience. Check how they interpret terms such as employee, payroll run, error and outsourcing. Include "not applicable" or "do not know" where those are genuine states. Avoid forcing a favourable product preference.

Report the invitation count, completed responses, recruitment channels, field dates, exclusions and missing data. Distinguish percentages of respondents from percentages of English employers.

Research competitors on the same scenario

HMRC's recognised payroll software list is a starting point for products capable of online PAYE reporting. HMRC explicitly does not recommend one supplier over another.

Define a scenario before comparison, such as one English employer with 35 active employees, monthly payroll, automatic enrolment and accounting-journal export. For every candidate, use dated first-party records to capture:

• supported customer and payroll context;
• included plan and chargeable unit;
• reporting and correction functions;
• pension tasks and named compatibility;
• permissions, imports, exports and integrations;
• implementation and migration;
• support and service status;
• privacy, security and contract evidence.

Mark an unavailable public fact as unknown. Do not fill it from an old review. Request documentation or test it in a controlled trial.

Competitor research also includes the customer's current workaround. A spreadsheet, bureau relationship or decision to stay with an incumbent can be a stronger alternative than another software brand.

Analyse by workflow and confidence

After each research round, group observations by process stage rather than by attractive feature name. For example: collect variable pay, validate starters, approve calculation, submit, reconcile pensions, issue documents and correct errors.

For each finding, record:

• the segment and roles involved;
• number and type of supporting observations;
• contradictory evidence;
• current consequence and workaround;
• confidence level;
• next test;
• product or content decision affected.

Frequency is not the only priority. A rare failure with serious consequences may deserve attention, while a common annoyance may not justify switching. Combine prevalence, severity, willingness to change and delivery burden.

Use decision gates, not a research theatre

An evidence-based audience is ready for focused development when the team can identify the same role, workflow, problem and desired outcome across several relevant cases. The buyer or blocker is known, the existing alternative is understood and a paid pilot can test value.

Pause or narrow the work when findings cluster only by vague company size, participants cannot show the claimed problem, or adoption requires unsupported payroll contexts. Record these negative results. They prevent expensive scope from being disguised as ambition.

The final audience statement should be plain: who performs which payroll job, under what conditions, why the current approach breaks down, who approves change and what observable outcome would justify it. That statement is more useful than a polished persona deck because every part can be tested again.