Van Westendorp Analysis with AI: Verifying an Acceptable Price Range

Introduction

Claude can run a Van Westendorp analysis on a market research export. In our October 2026 tests, Opus 5.5 matched the answer key within 50 cents on all four price points, even from a plain prompt. A prompt requiring stated conventions, counted exclusions and a recompute gave the same numbers in three chats, listed thin segments and found the revenue peak.

Last updated October 2026.

What We Tested

A Van Westendorp study hands you four columns of price answers and one tempting conclusion. The risk is the unstated choices around the arithmetic: which curves to cross, what to do with respondents who contradict themselves, and how far to trust a segment of 18 people.

We tested Claude the way a product manager would use it. We built a synthetic export with known answers, ran a plain request twice and an engineered prompt three times, and scored every run against the answer key.

An AI agent drove the browser on our account and entered each prompt as exact text. The first plain run was a pilot on unchanged data and counts as plain run 1. One engineered attempt picked up stray text from the chat box and was discarded unscored.

We ran every test in claude.ai on October 15, 2026, on a Claude Team plan, in fresh chats with memory off. The model picker showed Opus 5.5 at its Medium setting. The account’s default model that day was Haiku 5.5, which we didn’t test, so read every result here as an Opus 5.5 result.

All prices in this guide are per seat per month, in US dollars, and all are invented for this test.

What Is Van Westendorp Analysis and How Does It Work?

Van Westendorp analysis finds an acceptable price range from four open-ended price questions about one described product. Each respondent names the price at which the product would be so cheap they’d doubt its quality, a bargain, starting to get expensive, and too expensive to consider. Peter van Westendorp proposed the method at the 1976 ESOMAR Congress. We cite it by venue only, because we couldn’t retrieve the original paper.

You turn the answers into four cumulative curves across every price, then read the points where they cross:

Point of marginal cheapness (PMC): the low end of the acceptable range.
Optimal price point (OPP): where "too cheap" meets "too expensive", the price the fewest respondents reject.
Indifference price point (IDP): where "expensive" meets "bargain", the price that splits opinion evenly.
Point of marginal expensiveness (PME): the top of the range.

This guide covers analysis only. It assumes the four questions were asked as open numeric entry about one described product.

When Should You Use Van Westendorp Instead of Gabor-Granger?

Use Van Westendorp when you don’t yet know the range. It asks respondents to name prices, so it shows where price perception breaks before you’ve picked candidates. Use Gabor-Granger when you already have a shortlist and want to compare purchase intent at each price.

Use conjoint when price trades against features or tiers. Van Westendorp prices one product with no alternative in view.

That’s also the method’s main critique. Sawtooth Software, a vendor of research software, says the suggested analysis doesn’t follow from economic theory and treats price perceptions in isolation, often without defining the competitive landscape (retrieved October 15, 2026). Treat the result as a range to test, not a price to ship.

With or Without the Newton-Miller-Smith Extension?

The Newton-Miller-Smith extension adds two purchase-likelihood questions, asked at each respondent’s own "bargain" and "starting to get expensive" prices. We cite the 1993 paper by venue only, the AMA Advanced Research Techniques Forum, because we couldn’t retrieve it.

Converting those answers to probabilities, then multiplying price by average probability, gives a revenue index. Its peak is a calibrated estimate, not a demand forecast.

The 70, 50, 30, 10 and 0 percent weights in the R package pricesensitivitymeter come from a Sawtooth Excel template, not from Newton, Miller and Smith. On our data, those weights and a second set (50, 30, 15, 5, 0) put the peak at the same price.

Run the base method first. Add the extension only if you asked the two intent questions.

What Data Does This Example Use?

We built a synthetic dataset for a fictional B2B add-on called Taskboard Insights. It has 397 rows in the column layout of a Sprig CSV export, with a literal SKIPPED marker where a respondent saw a question and didn’t answer it. No real respondents are involved.

Each row carries four price answers (Q1 to Q4), two purchase-likelihood answers (Q5 and Q6), and plan and region columns. A script with a fixed seed generates the file, and a separate script computes every answer before any prompt runs.

Six traps sit in the data:

Partials and retakes: 16 rows have no completion time and 5 earlier rows belong to repeat visitors, leaving 376.
Skipped prices: 15 respondents skipped one price question (Q1 3, Q2 3, Q3 5, Q4 4), leaving 361.
Protest answers: 7 "too expensive" answers (0, 500, 999, 1000, 5000 and 9999 twice) fail a rule of zero or above 10 times the median, leaving 354.
Contradictions: 40 respondents break the rule that prices must rise from Q1 to Q4. Of those, 28 are out of order and 12 contain a tie. The strict base is 314; allowing ties gives 326.
Thin and zero cells: Enterprise has 18 respondents, below a threshold of 30. Enterprise by LATAM is empty, and four other plan-by-region cells hold 8, 10, 22 and 25.
Heaping: 54.5 percent of answers on the strict base are multiples of 5, so the curves move in steps.

The answer key, on the strict base with Convention A (explained below), is PMC 10.24, OPP 15.25, IDP 19.81 and PME 29.84.

Where Sprig fits: you can field the four questions as numeric-entry questions in a Sprig web study, or reach non-customers through panels.

Sprig publishes a Van Westendorp survey template, and its page doesn’t describe a built-in analysis. The analysis here runs in Claude, not in a Sprig agent. Check Sprig’s documentation for where numeric validation is supported before you field on mobile.

What Does a Plain Prompt Get Wrong?

We wrote the plain prompt first, as a product manager would type it, and froze it before writing the engineered one:

I've attached the export from our Q4 pricing survey for Taskboard Insights
(taskboard_price_study_q4_2026.csv). Run a Van Westendorp analysis and tell me
what price range and price point we should go with. Flag anything I should be
careful about.

We ran it twice, each in a fresh chat. Its successes come first.

What the Plain Prompt Got Right

Both runs returned the four price points to the dollar: 10, 15, 20 and 30, against an answer key of 10.24, 15.25, 19.81 and 29.84. Both found the partials and repeat visitors, excluded the 15 skipped answers, removed the protest answers and dropped respondents whose answers were out of order.

Both ended at a base of 326, which is what you get if ties are allowed, though by different paths: run 1 removed 6 protest answers and 29 order rows, and run 2 removed 7 and 28. Run 1 also kept each repeat visitor’s first submission, not the latest.

Both flagged round-number clustering, an Enterprise base too small to read, and the gap between stated prices and purchases. Run 1 reported that skipping the cleaning moves the optimal price from 15 to 19, close to the key’s 15.25 and 19.25. Run 2 called the optimal price point fragile and spotted that the five repeat visitors all returned exactly three days later.

Both took 5 to 9 minutes and left only a chart in the chat.

What the Plain Prompt Left to Claude

Six gaps showed up across the two runs:

No stated tie rule: neither run said how it treated ties. Both ended at 326 rather than the strict 314.
One range, mostly unnamed: run 1 gave one set of points without naming a convention. Run 2 mentioned the other method but didn’t label either.
No cell list: neither run listed the thin cells or the empty Enterprise by LATAM cell. Run 2 also reported Enterprise price points from 18 respondents, as "a lead to explore".
A wrong revenue peak: the revenue index peaks at 21.0. Run 1 reported 20 and run 2 about 19.5.
Two different recommendations: run 1 recommended 20 and run 2 recommended 19, from the same file.
No recompute or workbook: neither run checked itself a second way or saved a file, and run 2 gave an interval only for the optimal price point.

What Prompt Should You Use?

The prompt below states the file, the columns, the cleaning rules in order and both curve conventions. It adds a seeded bootstrap, a base threshold that counts zero, the extension and a second-method recompute. Copy it, replace the bracketed defaults with your own, and keep the structure.

Before you run it, confirm that code execution is on. The setting is named Code execution and file creation. On Free, Pro and Max plans it lives under Settings, then Capabilities.

On Team and Enterprise plans an Owner controls it under Organization settings. Anthropic’s article says it’s on by default but also tells Free, Pro and Max users to turn it on (retrieved October 15, 2026), so check the toggle.

Our Team account showed no personal toggle, and code ran in every run. Look for a line such as "Ran 9 commands" above the answer.

What this prompt does: runs a Van Westendorp price sensitivity analysis on a
survey export under two stated curve conventions, with every exclusion counted.
What it returns: a cleaning log, the four price points under both conventions
with 95% bootstrap intervals, a segment base table with thin and zero cells
flagged, an optional purchase-likelihood revenue curve, a side-by-side recompute
check, and a workbook named [OUTPUT FILE, default: van_westendorp_summary.xlsx].

File: [FILE, default: taskboard_price_study_q4_2026.csv]. Prices are per
[BILLING UNIT, default: seat per month], in [CURRENCY, default: US dollars],
written as plain numbers.

Use code to calculate this, not estimation. Load every row before reporting
anything. Do not report any number you did not compute in code.

Columns, matched exactly. Stop and tell me if any is missing:
visitorId, createdAt, completedAt, Q1_Response (too cheap), Q2_Response
(bargain), Q3_Response (starting to get expensive), Q4_Response (too expensive),
Q5_Response and Q6_Response (purchase likelihood at the Q2 and Q3 prices),
Attributes_1 [SEGMENT A, default: plan], Attributes_2 [SEGMENT B, default:
region].

Step 1, clean, in this order, counting each step:
a. Remove rows with a blank completedAt (partials).
b. Where a visitorId appears more than once, keep the row with the latest
   completedAt.
c. Remove respondents with SKIPPED or a blank in any of Q1 to Q4. SKIPPED is not
   a price and not zero. Count removals per question.
d. Remove respondents with any price equal to 0 or above [OUTLIER RULE, default:
   10 times that question's median]. List how many.
e. Keep respondents whose answers satisfy Q1 < Q2 < Q3 < Q4 [TIE RULE, default:
   strict; write "ties allowed" to keep equal adjacent answers]. Count removals.
Report rows in file, rows removed at each step, and rows remaining.

Step 2, curves. On the remaining respondents build four cumulative curves at
every price: too cheap (share answering at or above the price), bargain (share
at or above), expensive (share at or below), too expensive (share at or below).

Step 3, price points. Report all four under both conventions, and name each:
Convention A: PMC where too cheap meets not-bargain (1 minus bargain); PME where
too expensive meets not-expensive (1 minus expensive).
Convention B: PMC where too cheap meets expensive; PME where too expensive meets
bargain.
Both: OPP where too cheap meets too expensive; IDP where expensive meets bargain.
Use the first crossing from the left. Report the primary result under
[PRIMARY CONVENTION, default: A] and show the other beside it. Never present one
convention as the only answer.

Step 4, uncertainty. Run [RESAMPLES, default: 1000] bootstrap resamples of
respondents with seed [SEED, default: 7]. Report the 2.5th and 97.5th
percentiles for each price point under the primary convention.

Step 5, segments. Report the base for each [SEGMENT A] group and for every
[SEGMENT A] by [SEGMENT B] cell, including combinations with no respondents. A
group or cell with fewer than [THRESHOLD, default: 30] respondents is below
threshold, and zero is below threshold. List thin cells (1 to 29) and zero cells
separately, then the total of both. Report no price points for a below-threshold
group.

Step 6, extension [RUN EXTENSION, default: yes]. Convert Q5 and Q6 to purchase
probabilities with [CALIBRATION, default: Definitely would buy 0.70, Probably
would buy 0.50, Might or might not buy 0.30, Probably would not buy 0.10,
Definitely would not buy 0]. State that these values are package defaults, not
verified Newton-Miller-Smith values. Set probability to 0 at each respondent's
too cheap and too expensive prices, interpolate linearly between their four
prices, average across respondents, and report the price where price times
average probability peaks.

Step 7, recompute. Recompute the final row count and all four price points under
Convention A a second way: plain Python loops over the csv module, no pandas,
reusing no variable from steps 1 to 6. Show both results side by side.

If the two methods disagree, or a number cannot be computed, say so and show both
values. Do not silently pick one.

Stop rule: if a required column is missing, a price is not a number, or you find
a data pattern this prompt does not cover, stop and report it before continuing.

Save each step as its own sheet in OUTPUT FILE, and print the cleaning log and
the price-point table in the chat.

Each part answers a gap in the plain runs or a trap in the data:

Preamble and columns: states what comes back and stops the run if a named column is missing. No run triggered the stop.
Use code, not estimation: makes Claude compute every number it reports.
Ordered cleaning with counts: replaces Claude’s own choices with yours. Step e names the tie rule, which neither plain run stated.
Both conventions: reports PMC and PME under each, and says never to present one as the only answer.
Seeded bootstrap: puts an interval on each point, reproducible if you rerun the same seed.
Base threshold: names zero as below the threshold and lists thin and zero cells separately.
Extension with a disclosure: says the calibration is a package default, not a verified Newton-Miller-Smith value.
Recompute and stop rule: repeats the count and the four points in plain csv-module loops, and says to show both values if they disagree.

The prompt checks the arithmetic, but it doesn’t validate Claude’s work against a human check. Sprig’s guide to analyzing survey data with AI covers that.

Four edits adapt it. Replace the column names with your headers, replace SKIPPED with your export’s marker, set the thin-cell threshold your team reports against, and decide the tie rule and primary convention before you look at results. The 10-times-median outlier rule and the threshold of 30 are our judgment, not published standards.

What Did the Engineered Prompt Find?

We ran the engineered prompt three times, each in a fresh chat. All three returned identical numbers to each other on every check the prompt covers. Each took 5 to 7 minutes and created a workbook, which we opened only in the chat preview and didn’t download, so we report only what Claude said about it.

Every engineered price point sits within 0.25 of the key and every bootstrap bound within 0.4, inside our tolerances of 0.5 and 1.0. The engineered points sit off the key by the same small amount in every run, and we didn’t establish why. Agreement across runs shows reproducibility under fixed rules, not proof of accuracy.

All three runs also reported that their second-method recompute matched the main method to four decimal places. That shows the two code paths agree, not that the logic is right, because the same model wrote both.

The Van Westendorp-Specific Mistake: An Unnamed Curve Convention

The mistake that matters most in Van Westendorp isn’t arithmetic. It’s reporting a range without saying which convention produced it.

The R package pricesensitivitymeter documents two. In Convention A, which the package calls original, PMC is where "too cheap" meets "not a bargain" and PME is where "too expensive" meets "not expensive". In Convention B, which it calls narrower, PMC is where "too cheap" meets "expensive" and PME is where "too expensive" meets "bargain". Wikipedia notes that the explanation of the intersecting curves varies.

On the same clean data, the answer key gives a range of 10.24 to 29.84 under A and 14.83 to 21.81 under B. A pricing committee that sees only one of those will believe a very different story.

The engineered runs reported both, labeled, every time. Plain run 1 gave one range without naming it. Plain run 2 mentioned the other method but didn’t name either. The cleaning rules matter as much: without the order and outlier filters, the optimal price moves from 15.25 to 19.25.

When Not to Run This Analysis in a Chat Assistant

Five kinds of work belong in another instrument:

Weighted or quota-adjusted samples: use the R package pricesensitivitymeter, which includes a weighted analysis, or another package with survey weighting. We didn’t test weights in Claude.
A figure a pricing committee must reproduce exactly: use a versioned script, run the same way each time. The claude.ai chat doesn’t expose a seed, so ask Claude to write the script once.
How many people will buy, or revenue at a price: use Gabor-Granger analysis or an in-market price test. The extension is a calibrated estimate.
Price traded against features, tiers or competitors: use conjoint analysis, which prices the trade-off.
Segments under about 30 respondents: field more responses or pool segments. No analysis tool fixes a thin base.

The engineered prompt also doesn’t catch everything. In our runs it didn’t flag the repeat-visitor timing pattern that plain run 2 noticed, or that the out-of-order answers cluster in two patterns. It gave no recommendation, because it wasn’t asked for one. We didn’t test whether Claude would flag a sample that isn’t your buyer or a respondent answering in the wrong billing unit.

Run-to-run variation was observed. The two plain runs disagreed on the recommended price, while the three engineered runs matched under a fixed seed and fixed rules.

Thinking Machines Lab reported on September 10, 2025 that 1,000 completions at temperature zero from an open-weights model (Qwen3-235B) produced 80 distinct outputs. That wasn’t a Claude result, but it’s why we ran each prompt more than once. We didn’t test whether Claude misreads data placed mid-file, or how it responds to leading questions.

For governance, validation protocols and disclosure language, see Sprig’s guide to analyzing survey data with AI. If you need to compare price points across segments, the cross-tab guide covers segment comparisons and thin cells.

Plain Versus Engineered: Which Gets Van Westendorp Right?

On the four price points, both prompts were right. The plain prompt matched the key within 0.25 in both runs. Only the plain runs recommended a price, and plain run 2 alone noticed the repeat-visitor timing. Plain run 2 and engineered run 1 both flagged the optimal price point as fragile.

The engineered prompt was right on everything the plain prompt left to Claude: the tie rule, both conventions, the thin and zero cells, intervals on all four points, the revenue peak and the recompute. Three runs gave the same answer to the cent, and the engineered prompt gave no recommendation because it didn’t ask for one.

Our verdict, trap by trap: use a plain prompt for a first look, and use the engineered prompt for any number you’ll report. Remember five things:

State your convention and tie rule before you look at the results.
Count every exclusion, and make the totals add up.
Report both conventions, with an interval on each point.
Treat the optimal price point as the weakest of the four.
Confirm the recompute, then test the finalists on real buyers where you can.

Five runs on one dataset in one model show spread, not a rate. When Claude’s default model changes, we’ll rerun all five. Once you have a shortlist of prices, test it with Gabor-Granger analysis.

Frequently Asked Questions

Can Claude Run a Van Westendorp Analysis?

Yes. Claude can run a Van Westendorp analysis by writing and running code against every row of an uploaded CSV, as long as code execution is on. In our October 15 tests, all five runs reproduced the four price points within 50 cents of the answer key.

What differed was how much each run stated: only the engineered prompt named both conventions, listed thin cells and recomputed the result a second way.

Which Claude Model and Plan Did You Test?

We tested in claude.ai on October 15, 2026, on a Claude Team plan, with the model picker showing Opus 5.5 at Medium effort. The account’s default that day was Haiku 5.5, which we didn’t test. Memory was off and every run used a fresh chat. Results on other models, plans or dates may differ, and we’ll rerun the test when the default model changes.

How Do You Know the Plain Prompt Wasn’t Set Up to Fail?

We wrote and froze the plain prompt before the engineered one, and it names the file, the method and the question a product manager would ask. It matched the key on all four price points, and this guide reports that first. Digests of all five runs and the answer-key script are kept with our run log.

Which Van Westendorp Convention Should You Use?

Pick one before you see the results, report both, and name the one you used. Convention A gives a wider acceptable range than Convention B, and neither is an error. On our data the ranges were 10.24 to 29.84 and 14.83 to 21.81. The choice is a judgment the prompt makes explicit but can’t make for you.

What Should You Do with Respondents Whose Answers Are Out of Order?

Decide your tie rule before you look, then remove respondents who break it and say which rule you used. With a strict rule, 40 respondents in our file broke the order: 28 out of order and 12 with a tie. The strict base is 314, and allowing ties gives 326. That moves Convention B’s PME from 21.81 to 21.20. Neither plain run stated its rule.

How Many Respondents Do You Need?

We can’t give a sourced minimum. Our file kept 314 respondents after cleaning, and Sawtooth’s article gives no recommended sample size. The threshold of 30 in the prompt is a placeholder for your own judgment, not a published standard. Segments below it get no price points in the engineered prompt.

Does the Extension Tell You How Many People Will Buy?

No. Price times average purchase probability peaked at 21.00 in all three engineered runs, matching the key, but the calibration weights are package defaults, not verified Newton-Miller-Smith values. Neither plain run found the peak (20 and about 19.5). For a demand curve, use Gabor-Granger or a live price test.

Can You Trust the Optimal Price Point?

Treat it as the weakest of the four points. In our data both the "too cheap" and "too expensive" curves sit near 2 percent around it, so a handful of answers can move it. The answer key’s bootstrap interval runs from 15.12 to 17.25, and Claude’s engineered runs gave 15.26 to 17.63, wider than the other three points’ intervals. Plain run 2 and engineered run 1 both flagged this.

Can You Connect Sprig to Claude Instead of Exporting a CSV?

Sprig’s MCP server can connect Claude to your studies, but we didn’t test it for this guide, and the engineered prompt assumes the CSV columns. Sprig’s documentation lists up to 1,000 responses per call and says studies can’t be launched from the AI client (retrieved October 15, 2026), so check the current figure for a large study.

Once responses are in a Claude chat, Anthropic’s terms for your plan apply, not Sprig’s controls. See Sprig’s MCP documentation.

Is This a Claude-Specific Result?

We tested only Claude Opus 5.5, so we make no claim about other assistants or other Claude models.

Can You Use the Dataset from This Guide?

Yes. The synthetic Taskboard Insights dataset is offered with this guide, with an answer key computed by a script that doesn’t use pandas. Running both prompts on it shows how Claude behaves on your plan before you trust it with real data.