How to research email marketing software buyer personas

Email marketing software buyer personas should be evidence summaries, not fictional characters. A useful persona records a real decision role, the work observed, variations in context and the studies supporting each statement. It does not need a made-up name, stock photograph, quotation or market percentage.

What to take away

A persona is not the whole audience

The business account, purchasing decision-maker, campaign operator and email recipient are distinct populations. One person can occupy several roles in a small firm, while a larger organisation may split them across marketing, procurement, IT, privacy and finance. A persona should describe one role in a defined setting.

GOV.UK's guide to planning user research says profiles or personas can capture what a team has learned. Its guidance on learning user needs says those needs should come from research rather than assumptions. These are government service-design practices, not findings about email buyers.

Research the ESP buying journey

Start with the decision you need to understand: selecting, renewing or migrating an email service provider (ESP), or changing a broader marketing automation platform. Mailchimp, Klaviyo, HubSpot and Brevo are examples of vendors a buyer may evaluate; treat them as research scope, not as a recommendation or comparison.

Look for evidence across the buying journey. Internal sources can include sales-call notes, CRM opportunity outcomes, support tickets, onboarding feedback, churn or exit surveys, and product or ESP analytics. These can show what buyers report, where they get stuck and which features are used; they do not, by themselves, explain why a decision was made.

Use buyer reviews and comparison pages on G2, Capterra and Gartner Peer Insights to identify language, concerns and follow-up questions. Treat reviews as prompts for interviews, not as representative evidence of how common a concern is.

For deliverability research, include the postmaster or deliverability lead where the organisation has one. Ask about sender reputation, inbox-placement testing and the evidence the team uses when choosing or changing an ESP. Google Postmaster Tools is one named source a participant may use; record what the participant actually relies on rather than assuming every organisation uses it.

Common research triggers to screen for include a planned migration or renewal, difficulty with existing campaign workflows, and deliverability concerns. Record the trigger as reported by the participant and distinguish it from your interpretation.

Recruit for roles and buying context

Use purposive recruitment: seek people with direct experience of an ESP purchase, renewal or migration, and include the distinct roles involved. A screening conversation can establish the participant's responsibility, involvement in the decision, the type of organisation and whether they operate campaigns, manage deliverability or approve the supplier. In a larger organisation, include procurement, IT, privacy or finance when those teams take part in the decision.

Recruit through permissioned customer-research lists, relevant sales contacts, opt-in research panels or professional communities. Make participation voluntary and follow your organisation's privacy process when using customer or prospect records. There is no universal sample size for every study: set a target that reflects the roles and variation you need to understand, record who was recruited and who took part, and be clear about gaps. Do not present a small qualitative sample as statistically representative.

Use Jobs to Be Done to explore the progress a buyer is seeking, and Nielsen Norman Group (NN/g) persona guidance to keep role summaries grounded in research. These are ways to organise and interpret evidence, not substitutes for collecting it.

Use a short interview protocol

Ask each participant about a specific decision or recent experience, then follow up for examples and artefacts:

Ask permission before collecting or recording material, and note the participant's role and the evidence supporting each finding.

Use a source-backed role card

A compact record is easier to audit than a polished biography:

For a UK-wide study, record a participant's UK nation or location only when it affects recruitment or buying context; do not treat an England-only rule as the default.

For example, if a deliverability lead says an ESP migration depends on inbox-placement testing, record the role, decision stage and supporting evidence. Keep it as that participant's reported requirement unless other evidence supports a broader claim.

Build cards after analysis

Code each research item by purchase trigger, role, task, decision authority, approval criteria, systems and deliverability concerns. Keep reported evidence separate from your interpretation, and look for differences between buyers, campaign operators and deliverability leads before grouping cases. Use the GOV.UK method for analysing research sessions to help the team extract observations and challenge individual interpretations.

Create a card only when several related observations help a specific product decision. Keep links to the underlying evidence, fieldwork dates and researcher. If an assertion depends on one participant, label it as a case rather than a shared characteristic.

Do not merge an operator and buyer merely because both use the same platform. The operator can explain list preparation, campaign workflows and approvals. The decision-maker can explain budget authority, supplier checks and contract timing. A deliverability lead or postmaster can explain sender reputation and inbox-placement evidence; recipient experience belongs in another record entirely.

Protect the people behind the summary

Persona detail can make a participant identifiable even after names are removed. GOV.UK's research-data privacy guidance advises collecting the minimum participant information, restricting access and deleting details when no longer needed for the research purpose.

Set access, retention and redaction rules before creating cards. Review combinations of sector, job title, location and organisation size that could expose a person. Participation consent and the UK GDPR lawful basis are separate questions, so a named data-protection reviewer must approve the real process.

Validate rather than decorate

Validate the draft with eligible buyers, operators or other decision-makers from the roles the card describes. Ask what fits, what does not and what is missing; record the recruitment route and response denominator. Revise or split the persona when important workflows or purchase responsibilities diverge.

The next action is to replace every unsupported adjective in an existing persona with an evidence ID or an open question. Retire any card whose source study, population, geography or date cannot be recovered.

Before you act

Common questions

Why should a persona not be a fictional character with a name and photograph?

A persona should describe an evidence-backed role, such as an ESP buyer, campaign operator or deliverability lead, rather than a fictional character. A made-up name, stock photograph or invented market percentage cannot show who approves a purchase, what campaign work needs support or how a team assesses sender reputation. Keep each claim traceable to research.

How should a team decide when to create a persona card?

Code evidence by purchase trigger, task, decision authority, approval criteria, systems and deliverability concerns, then look for contradictions between roles. Jobs to Be Done can help organise what progress a buyer seeks, while NN/g persona guidance can help keep the resulting summary evidence-based. Create a card only when related observations help a specific product decision, and label single-participant assertions as cases.

What privacy rules apply before creating persona cards?

The ICO is the UK's data-protection authority. Consult its guidance, document an appropriate UK GDPR lawful basis before processing personal data, and explain data use and recording to participants. Consent to participate is not automatically the lawful basis for processing; if consent is chosen as that basis, it must be freely given, specific, informed and unambiguous, and as easy to withdraw as to give. Set access, retention and redaction rules, and involve your privacy lead.