Gabor Granger

Build a demand curve from survey responses, calculate a revenue-optimizing price, and verify it before calling it an answer. This example has been tested and validated with Claude.

When to use this

You have a short list of candidate prices and want to know how each one performs. Gabor-Granger answers “which of these specific numbers should we charge”- not “what would people pay for something like this in general.” It’s a single-product read that doesn’t model competitor pricing, and it works best when respondents already understand what they’re paying for.

Note on survey design:

This prompt handles both fixed-sequence surveys (every respondent sees every price) and branching surveys (respondents are routed up or down based on their answer). Steps 1–2 normalize either shape of data into the same clean table; everything from step 3 on is identical either way.

For the full walkthrough,  including a side-by-side comparison of two plain-prompt attempts that each produced different wrong prices, the demand curve output, and notes on how Gabor-Granger compares to Van Westendorp, see the full Gabor-Granger guide.

Prompt

Replace the bracketed placeholders with your own column names, price list, and threshold.

I have a Gabor-Granger pricing survey dataset. I want to build a
demand curve, calculate a revenue index at each price point, and
identify the revenue-optimizing price with confidence intervals.

What this prompt does:
- Turns purchase-intent answers into a cumulative demand curve and
  revenue index at each tested price
- Checks whether the top price is statistically distinguishable from
  its closest rival before calling it a winner

What it returns:
- A verified table: price, n, % willing to pay, 95% CI, flagged/not,
  revenue index, 95% CI on the index
- A demand curve and revenue index chart with error bars
- A plain-language summary distinguishing what the data supports from
  what's simply the highest point estimate

Please:
1. If a pre-coded outcome column exists, verify it against the raw
   answer columns before using it and show the check. For branching
   surveys, reconstruct cumulative willingness-to-pay from the raw
   columns rather than trusting the coded field alone.
2. For fixed-sequence surveys: check monotonicity (a respondent who
   says yes to a higher price and no to a lower one). Report the
   fraction of inconsistent respondents, then run steps 3-8 twice —
   excluding and including them — and report whether the conclusion
   changes. For branching surveys, skip this step.
3. For each tested price, calculate the percentage of respondents
   willing to pay at least that price using cumulative logic: a
   respondent whose price ceiling is $249 is also counted as willing
   at $99. Use code, not estimation.
4. Flag any price point backed by fewer than [N, e.g., 30] respondents
   as too few to trust. A zero base counts as too few, not just small
   nonzero counts.
5. Add a 95% confidence interval around each percentage that clears
   the minimum sample threshold.
6. Calculate a revenue index (price × full-precision % willing) at
   each price, carrying the confidence interval through. Round only
   at display time, not during calculation.
7. Identify the price with the highest revenue index. Check whether
   its confidence interval overlaps the next-highest price's interval.
   If it does, report a leading candidate, not a settled answer.
8. Recompute every number independently using a genuinely different
   method or code path. Flag any mismatch rather than silently
   correcting it.
9. Present the verified numbers as a table: price, n, % willing,
   95% CI, flagged/not, revenue index, 95% CI on the index.
10. Plot the demand curve and revenue index with error bars, built
    only from the table in step 9.
11. Summarize in 2-3 sentences. Distinguish what the data actually
    supports from what is simply the highest point estimate.

Setup

Code execution must be enabled for step 4’s verification to run. It’s on by default for Team and Enterprise accounts. Free, Pro, and Max users: enable it under Settings > Capabilities.

If your survey data lives in Sprig, skip the export, the Sprig MCP connects live surveys and responses directly into Claude so the analysis runs on current data.

How it works

1. Verify the coded outcome field

   If a pre-coded price column exists, the prompt checks it against the raw answer columns before using it. Branching surveys reconstruct cumulative willingness-to-pay from raw columns rather than trusting a derived field.

2. Monotonicity check (fixed-sequence surveys only)

   Fixed-sequence surveys can produce a contradiction branching ones can’t: a respondent who says yes to a higher price and no to a lower one. The prompt reports how many do this, then runs the analysis both ways- with and without those respondents- and tells you whether the conclusion changes.

3. Cumulative demand curve

   Calculates % willing to pay at least each price using cumulative logic. A respondent whose ceiling is $249 is counted as willing at $99, $149, and $199 too. Skipping this step is what caused two wrong prices ($149 and $249) in plain-prompt testing on identical data.

4. Flag thin price points

   Any price backed by fewer than your threshold (e.g., 30 respondents) is flagged. Zero counts as too few, not just small nonzero counts.

5. Confidence intervals

   Every percentage and revenue index (price × % willing) gets a 95% confidence interval. Rounding happens only at display time to avoid compounding errors.

6. Confidence intervals (Continued)

   Every percentage and revenue index (price × % willing) gets a 95% confidence interval. Rounding happens only at display time to avoid compounding errors.

7. Statistical tie check

   Identifies the highest revenue index, then checks whether its confidence interval overlaps the next-highest price’s. If it does, both are reported as viable, not a single winner. In testing on a 300-response synthetic dataset, $99 was the leading candidate with $149 flagged as statistically tied.

8. Independent verification

   Every number is recomputed using a genuinely different method before it’s reported.

9. Output

   A verified table and a demand curve + revenue index chart with error bars, both built from the same verified numbers.

10. Output (Continued)

    A verified table and a demand curve + revenue index chart with error bars, both built from the same verified numbers.

11. Plain-language summary

    2–3 sentences that separate what the data supports from what’s simply the highest point estimate.

Verify your own results

• Demand should decline monotonically. A curve that rises between two price points is a signal something went wrong in the cumulative calculation- check before acting on any individual number.
• State each column’s population. Confirm whether a yes-rate was calculated against the full sample or a branching-created subset. A wrong denominator is a real error, not a rounding issue.
• Check whether the top two prices are actually separate. Overlapping confidence intervals mean the data can’t pick between them. Don’t force a single winner from a statistical tie.