Persona Design — How to Design Test Personas for an AI Visibility Audit
Most B2B teams already have personas. They're in the deck the marketing team uses, on the wall in the product design room, baked into the ICP document that gets updated every 18 months. The instinct when starting an AI visibility audit is to pull those out and start from them.
That instinct produces personas that are useful for messaging decisions and useless for AI testing.
Marketing personas describe who a buyer is. AI visibility personas describe what a buyer would actually ask an AI assistant before they know your category exists — and what visibility challenge your brand faces with each of them. These are different artifacts with different structures and different purposes. The fields that matter for testing are not the same fields that matter for positioning.
This post covers how to build the right kind: how to consolidate audience segments from Step 1 into a working persona set, what each persona needs to contain, and how to decide which segments are worth testing at all. It continues the Freshdesk example from the previous post.
Start From Your Audience Segments
Persona design for an AI visibility audit doesn't begin with a blank page. It begins with the audience segments your brand identification step surfaced.
Step 1 will typically produce 10–15 distinct audience segments — buyer and user types implied by your content, each with a preliminary sense of role, goals, pain points, and likely question types. That's your starting material. The work here is not to generate a new list. It's to consolidate those segments into something a test can actually use.
You're aiming for 3–5 personas. Enough to represent real diversity in buyer behavior. Not so many that each gets only shallow test coverage in the test phase.
This consolidation isn't just administrative tidying. Many segments, when tested separately, produce nearly identical AI behavior. A "customer service leader" and an "omnichannel support buyer" might both ask the same underlying question: what's the best platform for unified support? If their questions produce the same AI responses, there's no diagnostic value in keeping them apart.
Why it matters: Starting from scratch invites a common failure — building buyer profiles around who you want to reach rather than who your content already speaks to. Segments grounded in your brand pages keep personas connected to reality. They also give you an early read on which buyers your content addresses clearly and which ones it's been quietly ignoring.
Consolidate Segments Into Personas
Merge segments when they share three things:
- What they're trying to accomplish (user mission)
- The situation driving their search (decision context)
- The type of question they ask (primary query surface).
When those three align closely enough that testing separately wouldn't produce meaningfully different AI responses, they belong in the same persona.
A few patterns come up consistently across B2B categories:
Leadership segments tend to cluster. Customer service leaders, CX leaders, omnichannel buyers, and legacy-replacement evaluators are often researching the same job-to-be-done from slightly different angles. Their questions look similar. Their AI responses look similar. They usually belong in one vendor-selection persona — with the distinct framing of each source segment preserved as goals, pain points, or example questions rather than discarded.
Operational segments tend to cluster. Admins, support ops managers, and collaboration-focused roles typically share a setup-and-configuration mission. Their questions are implementation-oriented — routing rules, SLAs, channel setup, workflow automation. They usually belong in one implementation persona.
Research-adjacent segments tend to cluster. AI automation evaluators, self-service owners, and benchmark researchers often travel the same evaluation journey: exploring capabilities, then seeking evidence to justify adoption. One educational persona captures the range.
Not every segment clusters cleanly. A segment with a genuinely distinct query surface — one that produces questions meaningfully different in type, and AI responses meaningfully different in character — warrants its own persona even if it came from a single source segment.
Some segments get skipped entirely. A segment based on weak source evidence — implied by a passing reference in your content rather than a consistent thread — or one whose questions would produce generic AI responses regardless of how they're framed, adds overhead without adding signal. Skip it and note why.
Why it matters: The consolidation step sets the scope of everything downstream. Good decisions here produce a persona set where each persona creates distinct AI behavior. Poor decisions produce either too many personas with redundant coverage, or too few with meaningful buyer types missing.
Build Personas That Can Actually Run Tests
Once you've defined your persona set, the work is building out each persona fully. This is where AI visibility personas diverge most sharply from marketing personas — not just in structure, but in what the fields are actually for.
User mission. A single sentence: what is this person trying to accomplish when they turn to an AI assistant? Not their job title, not their company size — the actual job-to-be-done, stated with real precision. "Find a platform that unifies support channels and avoids the complexity of legacy software" is a user mission. "Evaluate customer service software" is not. Precision here shapes every question you'll write in Step 4.
Decision context. The situation creating pressure to act right now. What's broken, slipping, or creating urgency. Context is what makes the mission active rather than hypothetical — the difference between a buyer type and a buyer in a moment.
Primary query surface. The dominant type of question this persona asks. The most common surfaces in B2B categories: vendor selection (which platform should we buy), implementation (how do we set this up), educational (how does this capability work and do we need it), diagnostic (what's causing our performance problem), and usage or workflow (does this tool actually help day-to-day). Each surface produces materially different AI behavior — different sources cited, different brands named, different depth and framing of answer. Getting the primary surface right tells you what to expect when you run tests.
Secondary query surfaces. The other question types this persona also uses. A vendor-selection persona also asks comparison and brand-aware questions. An implementation persona also asks tactical and diagnostic questions. Secondary surfaces define which additional question types belong in this persona's test coverage.
Expected visibility challenge. What AI is likely to get wrong for this persona — and this field has no equivalent in a marketing persona. A leadership-level platform buyer tends to trigger recommendation responses that default to well-known category names, skipping brands that don't have strong category association. An AI automation evaluator tends to get broad capability advice that references prominent AI companies without surfacing platform-specific features. A diagnostic persona may get best-practices content that never names a specific tool at all. Predicting the challenge before you run tests tells you what a meaningful finding looks like when results come back. It also prevents you from reading a predictable AI behavior as a brand-specific gap.
Goals, pain points, constraints, and decision criteria. The core of the persona's evaluation frame. Goals are what a good outcome looks like — not "improve customer service" but "improve first-contact resolution across channels without adding headcount." Pain points are what they're carrying into the search. Constraints are what they can't or won't consider. Decision criteria are what they're weighing between options. These four fields feed directly into question writing in Step 4, but only if they're specific enough to generate questions that sound like something a real person would ask.
Behavioral triggers. The specific conditions that sent this person to an AI assistant in the first place. Queues are becoming unmanageable. Response metrics are slipping. Leadership wants a plan before Q3. Triggers ground the persona in a real situation rather than a general buyer profile, and they're often the most useful prompt for writing first questions in a test scenario.
Natural language phrases. How this person describes their problem before they know your category exists — not marketing vocabulary, not category language. The way someone actually types into a chat interface: "How do I automate ticket routing?" rather than "What are the best AI-powered ticket automation platforms?" Write 3–5 phrases per intent type per persona. Natural language varies more than marketing language does, and a slight rephrasing can produce meaningfully different AI responses. These phrases are the raw material for question development in Step 4.
Vocabulary they use and avoid. The specific terms each persona reaches for naturally — and the terms that would signal a question was written from a vendor's perspective rather than a buyer's. A support operations manager uses "routing rules," "SLAs," "queue management." They don't use executive transformation language or consumer-style shopping terms. Build this map for every persona. It's the constraint system for question writing — what's in scope, what isn't, and how you catch drift when questions start sounding like your own marketing copy.
Example questions and follow-up style. A small set of representative questions in the persona's actual voice, and a description of how they tend to deepen a conversation. Follow-up style is worth documenting because it shapes how you design test conversations in Step 5. A vendor-selection persona starts broad and narrows into fit and scalability. An analytics persona starts with a metrics problem and presses for specific reporting capabilities and whether the tool can surface issues early.
Why it matters: The fields you skip are the fields that compromise the test. Without an expected visibility challenge, you won't know what to look for when results come back. Without precise goals and behavioral triggers, your questions drift toward generic framing. Without vocabulary maps, questions slide into your marketing language rather than your buyer's. Specificity in the persona spec is what produces specificity in the findings.
Assess Priority and Visibility Test Value
Not every persona in your set needs equal test coverage. Before running anything, decide where to concentrate your effort — and on what grounds.
Buying authority is the starting point. Buyers and evaluators are core. The person who signs the contract and the person who shapes the shortlist should both be in the set and get the most test coverage.
But buying authority alone is an incomplete selection criterion for AI visibility testing. The more important question is visibility test value: does testing from this persona's frame produce AI behavior that's meaningfully different from what other personas surface? Different sources cited. Different brands named. Different framing of the answer.
Visibility test value can be high even when purchase authority is low. End users don't make purchasing decisions. But if their questions — about workspace quality, AI assistance, context retention across channels — produce AI responses that buyer personas never trigger, that's a distinct visibility surface worth testing. If your brand messaging emphasizes frontline productivity and agent experience, an end-user persona tells you whether that messaging translates into AI-generated answers at all.
The reverse is also true. A segment with real purchase authority can have low visibility test value if its questions tend to produce generic AI responses regardless of framing — broad management advice, general productivity guidance, best-practices content that doesn't name specific brands. Running those tests generates noise more than signal.
Combine both criteria when assigning priority:
High buying authority and high visibility test value: these personas form the core of the test. Concentrate coverage here first.
Lower buying authority but a distinct visibility test value: include when the query surface doesn't appear in your buyer or administrator personas. The signal is different in kind, not just in degree.
High buying authority but low visibility test value: include selectively, and focus their question set on the scenarios most likely to produce named-brand responses rather than category-level generics.
Why it matters: Applying visibility test value alongside buying authority prevents the persona set from defaulting to obvious choices. The buyer persona almost always makes the list. What else belongs — and why — determines whether the audit surfaces real gaps or just confirms what you already knew.
What Persona Design Looks Like in Practice
The Freshdesk brand profile from Step 1 identified 14 audience segments. Persona design consolidated those into 5 — 3 high priority, 2 medium — through merges, standalone retention, and deliberate skips.
Four leadership and platform-buyer segments merged into one vendor-selection persona. Three operational and admin segments merged into one implementation persona. Three AI automation and research segments merged into one educational persona. One analytics segment was kept standalone because its diagnostic query surface — tracking metrics, identifying bottlenecks, assessing reporting depth — produces AI responses that look nothing like vendor-selection or implementation questions.
The fifth persona is a support agent. Not a buyer. Included because the query surface — workspace usability, AI assistance for daily case handling, context retention across channels — is distinct from everything the other four personas surface. Freshdesk's messaging leans heavily on agent experience and frontline productivity. Testing from this persona tells you whether that positioning registers in AI-generated answers.
Two segments were skipped: a narrowly-scoped API and chat platform segment with weak source evidence, and a Freshworks suite explorer segment whose questions were primarily about navigating the product family — too narrow to produce visibility findings worth acting on.
PERSONA 1: Customer Service Leader Comparing Omnichannel Support Platforms
Priority: High | Visibility test value: High
User mission:
Find a customer service platform that unifies support channels, improves
service outcomes, and avoids the complexity of legacy systems.
Decision context:
The organization is struggling with disconnected support channels, limited
visibility, inconsistent service, or pressure to scale without adding
operational burden.
Primary query surface: Vendor selection
Secondary surfaces: Comparison, educational, brand-aware
Expected visibility challenge:
Recommendation answers may default to familiar category names and generic
platform summaries, especially when questions are broad and
leadership-oriented.
Goals:
— Unify conversations, ticketing, and reporting in one platform
— Improve resolution rates, first-contact resolution, and service consistency
— Scale support operations efficiently across channels
— Replace hard-to-manage legacy software
— Adopt AI in a way that improves productivity without adding complexity
Pain points:
— Fragmented tools and disconnected channels
— Poor visibility into customer interactions and service performance
— Legacy platforms that feel bloated, slow to implement, or hard to use
— Pressure to improve outcomes without adding headcount
Vocabulary they use: omnichannel support, customer service platform,
unified workspace, CSAT, first-contact resolution, AI-powered support,
legacy replacement, service analytics
Vocabulary they avoid: internal product code names, feature-level admin
terminology, developer-centric API language
Natural language phrases:
— "We need one platform for all support channels"
— "I want to replace a clunky support stack"
— "Which tools improve CSAT and resolution rates?"
— "What is easiest to scale without enterprise complexity?"
Example questions:
— "What are the best AI-powered customer service platforms for
omnichannel support?"
— "How can I unify customer conversations, ticketing, and analytics in
one support platform?"
— "Which customer service tools improve CSAT and first-contact resolution?"
— "Is Freshdesk a good replacement for bloated customer service software?"
Follow-up style:
Starts broad, then narrows into platform fit, scalability, AI usefulness,
and whether it's easier to run than older systems.
---
PERSONA 2: Support Operations Manager Setting Up Routing, SLAs, and Automation
Priority: High | Visibility test value: High
User mission:
Set up and run a support platform that automates routing, standardizes
queues, supports handoffs, and is easy to administer across channels.
Decision context:
The team is configuring a new support system or trying to reduce operational
overhead from manual routing, inconsistent workflows, and hard-to-manage
queue logic.
Primary query surface: Implementation
Secondary surfaces: Tactical, diagnostic, brand-aware
Expected visibility challenge:
AI assistants may respond with generic workflow advice or broad help desk
lists instead of naming specific platforms unless the question explicitly
references routing, SLA, and channel controls.
Goals:
— Configure channel-specific routing and SLA rules
— Reduce manual admin work and queue chaos
— Launch new channels and automations quickly
— Connect business apps without a long implementation cycle
— Preserve context during internal handoffs and cross-team resolution
Pain points:
— Manual routing and prioritization
— Hard-to-maintain workflows and business rules
— Integration friction and slow implementation
— Lost context during cross-team handoffs
Vocabulary they use: routing rules, SLAs, queue management, business
hours, workflow automation, channel setup, integrations, handoffs,
admin controls
Vocabulary they avoid: executive ROI framing, broad brand slogans,
consumer-style shopping language
Natural language phrases:
— "How do I automate ticket routing?"
— "We need channel-specific rules"
— "I want to streamline queues without adding complexity"
— "How fast can we launch new channels and workflows?"
Example questions:
— "What support software is best for automating routing and SLA management?"
— "Which customer service platforms make channel setup and workflows easy?"
— "How do I set up channel-specific SLAs and routing in Freshdesk?"
— "What support platforms handle cross-team case collaboration without
losing context?"
Follow-up style:
Begins with setup or operations problems, then moves into configuration
depth, integration fit, and whether the platform stays maintainable
over time.
For the complete list, see Freshdesk AI Visibility Test Personas
What You Have at the End of This Step
A completed persona design step gives you two things the next steps depend on:
A defined persona set — 3–5 consolidated personas, each with a user mission, decision context, primary and secondary query surfaces, expected visibility challenge, goals, pain points, vocabulary maps, and example questions in genuine buyer language. These are your test subjects. Every question in Step 4 is written from one of these frames.
A visibility challenge map — For each persona, a prediction of where AI is likely to underperform: where it may default to well-known category names, produce generic advice, or omit your brand from answers where it belongs. This map is what makes the analysis step meaningful when results come back — it tells you what counts as a real gap versus what was predictable from the start.
Next in this series: Step 3 — Intent Mapping: how to define the full space of questions worth testing before you write a single one — and why the frame a buyer brings to a question changes the AI response as much as the question itself.
If you'd rather see what your brand's persona set looks like before working through this yourself, request a diagnostic run.
By Gaurav