Audience research
Part of Proposal software audience research without the guesswork
Before you build proposal software buyer personas, read this
Teams build proposal software buyer personas from job titles, then wonder why messaging misses. A task-based rubric fixes the inputs before persona work starts.
What to take away
- Most teams start with job titles, the wrong input when several people influence one software purchase.
- Build each persona from the tasks a buyer completes, the evidence they need and the objections they raise.
- Score every draft against a rubric before it reaches sales or marketing.
- Recruit participants from live deals, then review the set every two quarters.
Start from the buying task
A persona built only from a job title tells you little about how a proposal gets approved. In England, a finance lead, an operations manager and a legal reviewer can sit inside one purchase.
Write down the task each person must finish. One needs a cost breakdown they can defend to a board. Another wants to know the software will not break an existing process.
Task first, title second. That order keeps a persona useful when the same job title behaves differently at two companies. A persona that describes only seniority gives a writer nothing to put in a paragraph. The proposal software audience research guide for England covers how to recruit people who can describe those tasks.
Map the buying group
List every role that touches the decision, then note what each one does with the document. Some read the whole proposal. Others skim the pricing and security pages.
Buying group roles and power
- List every role touching the decision
- Note what each does with the document
- Record position in approval chain
- Note what each role can block
- Split same-title people by seat
- Signer vs influencer as separate entries
Record where each role sits in the approval chain and what they can block. A persona that cannot veto anything is a reader, not a buyer.
Two people with the same job title can sit in different seats. One signs. One influences. Keep them as separate entries until the evidence says otherwise.
That mapping shapes who you recruit for research.
Gather evidence from real deals
Use deals you have already run. Pull the email threads, the redlines and the questions that came back after the first send. Those artefacts show what buyers actually challenged, in their own words.
Mine evidence from past deals
- Pull email threads from closed deals
- Collect redlines and edits
- Gather questions after first send
- Sort artefacts by deal stage
- Review lost and stalled deals
- Interview colleagues, then buyers
Sort the artefacts by stage, from first enquiry through evaluation to negotiation, because each stage produces different language.
Lost deals matter too, because a stalled proposal often reveals an objection the persona never names. Interview colleagues who handled the deal, then the buyer where you can.
Salesforce's guide for startups recommends building a sales stack around the buyer's existing process rather than replacing it wholesale.
Separate evidence from assumption
Mark each persona statement as observed or assumed. Observed means a quote, a document or a recorded objection sits behind it. Assumed means someone in the business believes it.
An assumption is allowed to stay in the draft, but it should never be quoted back to a customer as though a buyer said it.
The proposal software customer interviews in England piece explains how to ask questions that produce usable quotes rather than polite agreement. Keep assumed items visible and flagged.
Consumer-facing claims need the same care. The Digital Markets, Competition and Consumers Act 2024 tightened rules on unfair commercial practices, so persona-led messaging about pricing or urgency needs a check before it goes out.
Score every persona
Run each draft through the same rubric. Score out of five per row and drop anything below 18 overall.
| Criterion | What a 5 looks like |
|---|---|
| Task clarity | The buyer's job to be done is stated in one sentence |
| Evidence base | At least two observed sources support the claims |
| Buying authority | The persona's approval role and veto power are named |
| Objection coverage | The three most common pushbacks are listed with answers |
| Trigger events | You can name what makes them start looking now |
| Channel fit | You know where this person reads and who they trust |
Score each draft on its own before the group compares notes, otherwise the first strong opinion anchors every other score.
A shared rubric stops the loudest voice in the room winning.
Keep personas discoverable
A persona that lives in a slide deck nobody opens has no effect. Put the scored versions where sales and marketing already work.
Give each persona a version date and a named owner, so anyone can tell whether the file still reflects current deals.
Check that search engines can reach those pages. Google's overview of its crawlers explains how indexing works, which matters if your personas sit behind a login.
Review the set every two quarters. Buying groups shift when a company hires a procurement lead or adopts a new approval tool.
Common questions
How many personas should a proposal software vendor keep?
Three to five is usually enough. Beyond that, sales stop remembering which one applies.
Can one persona cover several job titles?
Yes, if the task and the objections are the same. Group by what the buyer must prove, not by the label on their business card.
What is the fastest way to test a persona?
Use it to rewrite one live proposal and track whether the buyer asks fewer clarifying questions.
Do personas need updating after a pricing change?
Yes. Pricing changes alter who can approve a purchase and what evidence they demand, so rescore affected personas before the next campaign.
