Prompt-set patterns and design rules

Buyer-stage prompt patterns for SaaS, DTC and ecommerce, B2B services and local services, published with the design rules that decide whether a set built from them produces an honest measurement or a flattering one.

Read the prompt-set design rules · Size the runs your set will need

The patterns are starting points to adapt, not finished instruments; a set you have not checked against your own buyers will measure someone else's category.

In short

This page gives buyer-stage prompt patterns you can turn into a set of buyer-realistic questions to run against AI assistants and measure whether your category's brands get named. The patterns are organised by buying pattern and mapped to buyer stages from open category questions through constrained questions to direct comparisons. The page publishes the design rules alongside them: buyer language rather than marketing language, several phrasings per intent, regional variants where they matter, no prompts that name the subject brand, and a freeze before measurement so that edits do not silently break your trend comparison.

Who this is for

In-house SEO leads who need a defensible starting set rather than sixty prompts invented in an afternoon
Agency and consultant strategists standardising measurement across several clients in different categories
Analytics people who have to justify why a set of questions is a fair instrument
Founders running a first check who want to know whether the questions resemble how their buyers actually ask
Anyone auditing a prompt set someone else built, including a vendor's

When to use this

You are about to measure for the first time and have no set yet
You have a set but your results look implausibly good and you suspect the questions are the reason
You are moving from a one-off check to a tracked programme and need to freeze something
You need to explain to a client or an executive why the questions were chosen

Why the prompt set decides the result

In classic search the query comes from the user and you measure against it. In AI visibility measurement you write the questions yourself, which means you are choosing the exam as well as sitting it. That makes the prompt set the single largest lever on the number, larger than the model roster and larger than the sample size.

This is why so many AI-visibility scores are cheerful. Not through fraud, usually, but through the natural drift of writing prompts that describe your product the way you describe it. Ask about a category using your own positioning vocabulary and you will find yourself in the answers.

The defence is to publish the set. A figure with its prompt set attached can be argued with. A figure without one cannot be checked by anyone, including you in six months when you have forgotten what you asked.

The design rules that make a set honest

These rules apply to any set you build from the patterns below. They are deliberately restrictive, because most of the ways a prompt set goes wrong are ways it goes wrong in your favour.

Buyer-realistic language. Write the question the way someone with the problem would type it, including the imprecise and slightly wrong ways, not the way your category page describes itself.
No brand-baiting. Prompts must not name the brand being measured. Naming it pulls the model into discussing it and inflates every metric downstream.
Several phrasings per intent. One wording measures that wording. Three or four phrasings of the same underlying question measure the intent.
Buyer-stage coverage. Open category questions, constrained questions, and comparison questions behave differently and should be reported separately, not averaged into one figure.
Regional and language variants where the category actually differs by market, and only where it does. Variants you do not need multiply your run count for nothing.
Documented ambiguity. Where a category term means two things, note it in the set rather than letting the ambiguity quietly show up as variance.
Version and freeze before measuring. A set gets an identifier and a date, and it does not change while a measurement window is open.
No prompts written to produce a desired answer. If you would be uncomfortable publishing the set next to the result, do not run it.

The test for any prompt: would a buyer who had never heard of you plausibly type this?

Example prompt patterns by buyer stage

These are generic patterns rather than a finished set, and they are written with placeholders on purpose. Fill the brackets with your own category vocabulary and constraints, and the shape carries across categories.

Notice that none of them name a brand being measured, and that comparison-stage prompts name competitors only where a buyer genuinely would. The point of a comparison prompt is to see who the assistant volunteers alongside a named alternative, not to prompt it into discussing you.

Open category: "What are the best [category] for a [buyer type]?" and "Who are the main providers of [category]?"
Constrained: "Best [category] for [constraint], for example a small team, a tight budget, or a specific regulatory requirement."
Problem-led: "I need to [job to be done] but [obstacle]. What should I use?" — the shape most buyers actually type.
Use-case-led: "What do most [industry] companies use for [job]?" and "What is a good [category] if I already use [adjacent common tool]?"
Comparison: "[Competitor A] vs [Competitor B] for [use case] — what else should I look at?"
Alternatives: "What are alternatives to [widely known category leader] for [constraint]?"
Local pattern: "Best [service] in [city or area] for [constraint]?" plus the variants a local buyer would actually use, such as "near me" phrasing.
Evaluation: "How do I choose a [category]? What should I compare?" — often the most citation-rich prompt in a set.

The four buying-pattern families

The patterns are organised by how buying works in the category, not by industry vertical, because the buying pattern is what determines the prompt shapes.

SaaS and software sets lean on constrained and integration-led questions, because software buyers usually arrive with an existing stack and a specific limit. DTC and ecommerce sets lean on attribute and occasion questions, because the constraint is often a use case, a material, a price band or a recipient rather than a feature. B2B services sets carry more evaluation-stage prompts, because the buyer is often trying to work out how to choose before they try to work out whom to choose. Local services sets need the heaviest regional variation, and are the family where the same prompt behaves most differently between two nearby markets.

When you build a set, record which family it belongs to, its version and date, the buyer stages covered, the known ambiguities in its category vocabulary, and what it deliberately excludes.

Adapting a set to your own category

Start by throwing prompts away. Most starter patterns include questions that do not apply to you, and keeping them adds cost and dilutes the signal. Cut before you add.

Then check the category noun. This is where most adaptations fail: if buyers name a different category than the one you use internally, the whole set measures a market you are not in. Test two or three candidate category terms in a small exploratory run before committing to one.

Then add your genuine constraints, the ones that appear in real sales conversations, and only those. Invented constraints that happen to describe your differentiators are brand-baiting wearing a disguise. Finally, have someone who does not work on the product read the set and say whether a buyer would type these. It is a five-minute check that catches most of the self-flattery.

Versioning: why edits break your trend line

A prompt set is an instrument. Changing the instrument mid-programme means every comparison across the change is measuring two things at once, and there is no statistical repair for it afterwards.

So a set gets a version identifier and a date before its first measured run, and stays frozen for the window. When you do need to change it, and eventually you will, the honest move is to publish a new version, show the break in the series, and where it matters run both versions side by side for one cycle so you can see how much of any shift was the instrument.

Record the set version everywhere the results appear. A results file, a dashboard, a slide and an internal wiki page all need it, because the version is the only thing that makes a number from last quarter interpretable this quarter. A figure without its set version, model versions, run dates, sample size and variance attached is not a measurement you can defend, which is why a figure should carry all five and link back to the method it followed.

Record the set version alongside every result. Future you will not remember what changed.

What a prompt set cannot fix

A good set makes a measurement honest. It does not make it powerful, and it does not make it explanatory.

If your sample size is too small, a perfect set still produces figures that wobble for no reason. Size the runs separately. If the model changed under you mid-window, the set cannot tell you that either, which is why model versions are recorded per call rather than per study.

And no prompt set will tell you why a brand is named or not named. Detecting a gap and diagnosing it are different jobs, and the diagnosis usually lives in entity clarity, retrievability, and which third-party sources the answers were built from.

Frequently asked questions

How many prompts should a set contain?

Fewer than most people start with. Every prompt multiplies against your model roster and your run count, so a bloated set forces you to under-sample each question, which is the worse trade. Cover your buyer stages and your genuine constraints, kill anything a real buyer would not type, then size the runs. A tight set run properly beats a large set run three times each.

Can I include prompts that name my own brand?

Keep them out of your headline figures. A prompt that names your brand invites the assistant to discuss it, so mention rate and framing both inflate and stop describing whether buyers would encounter you unprompted. There is a legitimate separate use for brand-named prompts, which is checking what a model says about you factually, but that is a brand-accuracy exercise and belongs in a different report.

Should I use the same set for every assistant?

Yes, and this matters more than it sounds. Comparing assistants only means something if they were asked identical questions in the same window. Different sets per model produce numbers that cannot be placed side by side, which is one of the quieter ways cross-model comparisons mislead. Vary the model, hold the set constant, and record which version was used for each.

How often should I revise a set?

As rarely as the category allows. Every revision costs you comparability with everything measured before it. Revise when buyer language has genuinely shifted, when a category term has become ambiguous, or when you find a prompt that was flattering you. Do not revise because results were disappointing. When you do revise, publish the new version, show the break, and where the stakes are high run both versions for one cycle.

Do regional variants really change the answers?

Often enough that ignoring them is a real risk in some categories and a waste of budget in others. Local services and regulated categories tend to vary a lot; globally uniform software categories tend to vary less. The test is cheap: run a small exploratory batch with two regional phrasings before you commit variants to the frozen set, and add them only if the answers actually diverge.

Is a set built from these patterns good enough to publish results from?

It is good enough to start with and not good enough to leave unexamined. The patterns are generic and built to be adapted, so a first set will contain prompts irrelevant to your category and miss constraints specific to it. Cut, adapt, have someone outside the product team sanity-check it, then version and freeze. Publish the adapted set alongside your results so anyone reading them can judge the instrument.

What does versioning look like in practice if I'm working in a spreadsheet?

A version identifier and a date at the top of the prompt tab, a copy of the frozen set saved separately when the window opens, and a column in the results tab recording which set version produced each row alongside the model version and run date. It is unglamorous and takes minutes. Without it, a results file six months old is uninterpretable, which is the most common way measurement programmes quietly die.

Freeze a set, then size the runs

A published set and a recorded version make every later comparison defensible. Build a set from the patterns, freeze it, and work out how many runs it needs before you spend anything.

Size your runs · Read the methodology · See the measurement hub