Last updated September 2026
Why one fixed panel has to serve every tool
Every LLM visibility tool can point to a screenshot where it caught a citation a rival missed. That screenshot is not proof the tool is better. It is proof the two tools ran different prompts, on a different day, against a different model version.
Change three variables at once and you cannot tell which one moved the number. A vendor demo picks its best prompt. A rushed comparison runs on whatever day the writer had free. Neither tells you how a tool performs on a normal Tuesday against a normal question.
The Prompt Panel Method exists to strip that noise out before a single grade gets assigned. It is the process behind every graded page on this site, and we are naming it here so other teams testing these tools can borrow it, cite it, or hold us to it.
The core idea is not complicated. Hold the prompts constant. Hold the day constant. Hold the model version constant. Only then does a difference in what two tools report actually mean something about the tools, instead of about the conditions each one happened to run under.
The four-stage framework
| Stage | Locks down | Output |
|---|---|---|
| 1. Panel Design | The exact 120 prompts and their intent mix | A dated, versioned prompt set |
| 2. Identical Run | The tool, the engine, and the calendar day | Raw answers from every tool, same conditions |
| 3. Model-Version Lock | Which build of each engine actually answered | A version tag attached to every run |
| 4. Delta Scoring | The gap between reported and verified accuracy | A letter grade per criterion |
Read it left to right and the shape is simple. Build the test once. Run it identically everywhere. Freeze what changed underneath it. Score the difference. Skip any one stage and the comparison drifts back into “trust the vendor’s screenshot.”
Each stage exists to close one specific loophole. Panel Design closes the loophole where a tester picks prompts a favorite tool already handles well. Identical Run closes the loophole where two tools get compared on different days. Model-Version Lock closes the loophole where a tool takes credit for an engine update it had nothing to do with. Delta Scoring closes the loophole where a tool’s own dashboard number goes unchecked. Remove any one stage and that specific loophole reopens.
The method, step by step
Stage 1: Panel Design
Step 1. Set the prompt count and intent mix before any tool sees them. We split the 120 prompts into three even bands of 40: discovery prompts (“best tools for X”), comparison prompts (“X vs Y”), and decision prompts (“is X worth it,” “X pricing”). A tool that only performs well on broad discovery prompts should not pass a grade on discovery alone.
Step 2. Source real language, then freeze the list. Prompts come from actual search and chat behavior, not a guess at what someone might type. Once the 120 are set, they go into a dated, versioned document. Nobody edits the panel mid-run, and nobody swaps out a prompt because a tool handled it badly.
Stage 2: Identical Run
Step 3. Load the same 120 prompts into every tool, unedited. No tool gets a rephrased or friendlier version of a prompt. What one platform sees, every platform sees, word for word.
Step 4. Run every tool on the same calendar day, across the same engine set. We test against the five engines this lab covers: ChatGPT, Perplexity, Google AI Overviews, Gemini, and Microsoft Copilot. AI answers can shift within hours, so a run spread across a week compares different moments in time, not different tools.
Stage 3: Model-Version Lock
Step 5. Record the exact model version behind every answer. An engine’s public name stays the same while the model behind it changes. ChatGPT, Gemini, and Copilot all ship updates without renaming the product. We log the version and timestamp tied to each run, not just the engine’s brand name.
Step 6. Freeze that version record with the run. A rerun weeks later carries its own version tag. If a tool’s grade moves, the version log shows whether the tool changed or the model underneath it did. Without this step, a grade swing is unreadable, and a tool could take credit for an improvement it never made.
Stage 4: Delta Scoring
Step 7. Score the gap between what a tool reports and what a manual check confirms. For a sample of prompts in every run, we check the actual AI answer by hand: was the cited source real, was the brand mention actually present, did the tool miss a citation it should have caught. The score is the delta between the two, not the tool’s raw dashboard number.
Step 8. Roll the deltas into a letter grade. Each delta feeds a criterion grade, A through F, the same scale explained on the measurement protocol. Criterion grades combine into one overall grade per tool, weighted the way the benchmark page states.
Where each delta feeds a grade
Delta Scoring does not produce one number. It feeds seven separate criteria, so a tool cannot hide a weak spot behind a strong one:
- Engine & Model Coverage: does the tool track the engines it claims, at the model version we recorded.
- Prompt Volume Range: how far a real plan’s prompt cap stretches against the 120-prompt panel.
- Data Collection Transparency: whether the vendor documents how it actually pulls its data.
- Citation & Source Attribution: how often a reported citation matches what a manual check finds.
- Execution & All-In-One Scope: what happens once a gap is flagged, inside the same account or not.
- Ease of Setup: how long it takes to get from signup to a first useful report.
- Value for Money: what the entry price actually buys against the other six criteria.
What a fixed panel catches that a spot-check misses
A single test prompt can flatter almost any tool. Run 120 prompts across three intent bands and the real pattern holds or it does not. A tool that tracks discovery prompts well but loses ground on comparison and decision prompts shows that gap here, not just in a headline number a vendor chose to publish.
Model-Version Lock catches a separate failure. A grade can look like it moved because a tool improved, when the real cause is that the model underneath it changed weeks earlier. Without a version record tied to the run, the two are impossible to tell apart, and a tool could get credit it did not earn.
A fixed panel also makes a result repeatable. Anyone can take the same 120 prompts, the same engine set, and the same version records, and check our work. A one-off comparison built from a handful of hand-picked prompts gives nobody a way to check anything. It just gives you a number to trust or not.
How often the panel reruns
The panel reruns on a fixed schedule, and again the moment a vendor makes a material change: new pricing, a new engine added to its coverage, or a plan restructure. The updated date on a graded page marks the date its last run finished, not the date the page happened to get edited.
When a grade moves between runs, the reason gets logged, not buried. That log lives on the benchmark page itself, next to the criteria and the weights behind the overall score.
A rerun does not start from a blank sheet either. The same 120-prompt panel goes back through the same steps: Panel Design stays fixed unless the intent categories themselves have shifted, Identical Run happens on one new calendar day, Model-Version Lock records whatever engine build answers that day, and Delta Scoring produces a fresh set of grades to compare against the last logged run.
Put the method to work
Building a 120-prompt panel yourself takes real effort. Pull real search language, split it into discovery, comparison, and decision bands, and freeze the list before you open a single tool.
If you want the finished result instead of building your own panel, the graded comparison across every tool this lab covers, including Profound, Temso, Peec AI, Otterly.AI, and Scrunch, is live on the full LLM visibility tool ranking.