Audience research
Part of Small business CRM audience research in England
CRM buyer personas as versioned hypotheses with expiry rules
Build evidence-led CRM buyer personas for England as versioned hypotheses, with traceable cases, contradictions, missing groups and expiry rules.
Small business CRM buyer personas should summarise evidence for a decision. They should not invent a named owner, a stock photograph, a budget or a neat motivation. Before fieldwork, use an empty persona card that labels every proposed attribute as a hypothesis.
A persona hypothesis can guide which CRM features to test, which roles to involve in a trial and when a buying assumption should expire. It helps a principal compare vendors without treating marketing claims as research. It keeps migration, reporting, support and data protection needs tied to observed work rather than a generic sketch.
What to take away
- A CRM buyer persona should summarise evidence for a decision, not invent an owner or budget.
- Keep the business principal, process owner, daily operators and specialist reviewers separate.
- Leave persona fields blank until research supplies verified material, and record contradictions.
- Give every card a version number, an owner, a review date and expiry conditions.
Keep four roles apart
CRM decisions can involve a business principal, process owner, daily operators and specialist reviewers. A founder may hold several roles, or an employing firm may distribute them. The persona must state the role it represents and the decision it informs.
A persona cannot stand in for the customers whose records enter the system. Define the eligible organisation too: how many employees, which sectors and which parts of the country. If research excludes non-employers, certain sectors or firms outside England, record that next to the persona. Otherwise a reader may mistake a narrow choice for the national population.
Use an evidence card, not a character sketch
Create the card with the fields below and leave each one blank until research supplies material. A field that stays blank is a finding in its own right, because it shows exactly where the evidence is missing and which role to recruit next.
Blank CRM Persona Evidence Card
- Role and authorityverified responsibility
- Relationship taskrecent workflow event
- Constraintobserved step or statement
- Decision triggerdated contract or incident
- Evidence baseparticipant codes and artefacts
- Contradictioncases not showing pattern
- Missing groupeligible people absent
- Version and expiryfield dates and trigger
| Card field | What it records | Rule |
|---|---|---|
| Version | Number and date of the last change | Raise it when any field changes |
| Role and decision | Who is represented, which decision it informs | One role per card |
| Eligible organisation | Employee boundary, sector, region | State exclusions |
| Evidence | Prompt, statement, observation, inference | Link each to a coded source |
| Contradictions | Cases that disagree | Keep both visible |
| Missing groups | Roles or firms not yet reached | Name them |
| Owner and review date | Who maintains the card | Set before use |
| Expiry condition | What retires the card | Written down |
Do not write "wants an easy CRM" unless the record says who used which process, what "easy" meant and whether the problem was observed. A willingness-to-pay statement is not a verified budget, so keep it apart from the costs and budget work. An intention to buy is not a purchase.
Teams should treat opinions as assumptions that research has to prove. Apply the same discipline to a persona: every attribute starts as an assumption and moves onto the card only when a session supports it.
Keep conflicting cases visible, including those from customer interviews. If one operator relies on a shared inbox while another rejects shared access, show both conditions and the unresolved reason. Do not average the disagreement into a fictional preference. The research owner can schedule later observation or recruit the missing role to test which explanation fits.
Preserve the route from session to inference
For every persona attribute, separate the interview prompt, the statement, the observation and the inference, and link each to a coded source. Notes on a session should record exactly what the team saw or heard, not what they think it means (see how to analyse a research session).
Session to Inference Trace
- Interview prompt
- Participant statement
- Direct observation
- Analyst inference
- Coded source link
A theme among recruited cases remains a qualitative finding. It is not a prevalence estimate for England. Show the eligible-case denominator and recruitment route. Include non-users and people satisfied with manual methods when the question covers possible buyers, or the persona will reflect only current software users. Test the first signals against bounded demand signals.
Example card for a CRM trial
The example is illustrative. Every value is a hypothesis to test, not a finding, and none comes from real research. It shows how a card for a small firm choosing between a shared inbox and a CRM pipeline might read at its first version.
| Field | Example entry (hypothesis) |
|---|---|
| Version | First draft, no research yet |
| Role and decision | Process owner: keep the shared inbox or trial a CRM |
| CRM features to test | Contact records, pipeline stages, permissions, export |
| Eligible organisation | Firms with a small headcount, England only |
| Legal gate | Lawful basis chosen and documented before trial data |
| Missing groups | Daily operators, specialist reviewers |
| Expiry condition | Retire if the firm adopts a CRM or the decision changes |
Customer records in a CRM are personal data. Before you start handling personal information, choose one of seven lawful bases and document the choice. Put that check on the card as a gate, covering each of the seven options, before any trial data is loaded.
Retire weak personas
Set an owner and a review date, and add both to the quality checklist. Revise the card when a new sector, role or access need contradicts it, and raise the version number each time.
Retire the card if source sessions fall outside the current decision, if evidence cannot be traced, or if the label encourages stereotypes about age or disability. A persona exists only after participant research. Until then the card stays blank, no named character is invented, and the next step is an approved recruitment protocol and a privacy review.
Before you act
- Define the eligible organisation and employee boundary before recruitment.
- State the role the persona represents and the decision it informs.
- Leave the evidence card blank until research supplies material.
- Link every attribute to a coded source and separate inference.
- Set an owner, a review date and retirement conditions.
Common questions
What should a small business CRM buyer persona contain?
It should summarise evidence for a decision and label every proposed attribute as a hypothesis before any fieldwork starts. It must state the role it represents and the decision it informs, and it carries a version number so changes stay traceable.
How should conflicting cases be handled in a persona?
Keep conflicting cases visible rather than averaging them into a fictional preference. If one operator relies on a shared inbox while another rejects shared access, show both conditions and the unresolved reason on the card, with the sources.
When should a persona be retired?
Retire it if source sessions fall outside the current product decision, if evidence cannot be traced, or if the label encourages stereotypes about age, disability or technical confidence. Write each expiry condition on the card before first use.
