> For the complete documentation index, see [llms.txt](https://docs.zigpoll.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.zigpoll.com/guides/how-to-find-optimal-pricing.md).

# How to Find Optimal Pricing for Your Product

Most pricing decisions are made by looking at competitors and adding a margin. That tells you what the market charges, not what *your* customers are willing to pay. A pricing survey closes that gap by asking real buyers directly, then reading the answers against the two prices that matter: the one that maximizes revenue, and the one that starts costing you customers.

This guide covers two proven methods. Start with **Van Westendorp** if you don't have a price yet. Use **Gabor-Granger** if you have a price and want to know whether you can raise it.

***

## Method 1: Van Westendorp (finding a price range from scratch)

Van Westendorp asks four questions about the same product. Together they map the range customers consider reasonable.

### Building the survey

Create a survey and add four questions. Use a **Slider** question for each one, setting the minimum, maximum, and increment to sensible bounds for your category (for example, $0–$200 in $5 increments). A **Short Answer** question also works if you'd rather let people type a number freely.

Ask them in this order:

1. **Too cheap** — "At what price would this be so low that you'd question the quality?"
2. **Cheap / a bargain** — "At what price would this feel like a great deal?"
3. **Expensive** — "At what price would this start to feel expensive, but you'd still consider it?"
4. **Too expensive** — "At what price would this be so high that you'd never consider it?"

Add an image of the product on each question so respondents are pricing the real thing. Keep the product description identical across all four questions.

{% hint style="warning" %}
Order matters. Ask the two cheap questions first. Leading with "too expensive" anchors respondents high and skews every answer that follows.
{% endhint %}

### Reading the results

Export your responses from the **Table** tab, or send them to a spreadsheet with the [Google Sheets integration](/integrations/google-sheets.md). For each price point, calculate the cumulative percentage of respondents, then find where the curves cross:

| Intersection                      | What it means                                                                                                                   |
| --------------------------------- | ------------------------------------------------------------------------------------------------------------------------------- |
| **"Too cheap" x "Too expensive"** | **Optimal Price Point** — the fewest people reject you on price in either direction                                             |
| **"Cheap" x "Expensive"**         | **Indifference Price Point** — equal numbers see it as a bargain and as pricey; usually close to what the market leader charges |
| **"Too cheap" x "Cheap"**         | Lower bound — below this, quality perception collapses                                                                          |
| **"Too expensive" x "Expensive"** | Upper bound — above this, you're pricing yourself out                                                                           |

The two bounds give you a **range of acceptable prices**. Anywhere inside it is defensible. Where you land in that range is a positioning decision: the low end buys volume, the high end buys margin and signals premium.

***

## Method 2: Gabor-Granger (testing a specific price)

If you already sell at $49 and want to know whether $59 is safe, show each respondent one price and measure purchase intent.

1. Add a **Range** question: "How likely are you to buy this at **$59**?" on a 1–10 scale.
2. Create a second and third version of the survey at different price points ($49, $69).
3. Run all versions at once as an [A/B test](/tutorials/a-b-testing-surveys.md) so each visitor sees exactly one price.

Compare the share of respondents answering 8 or higher at each price. Multiply that share by the price to get a rough revenue index — the winner is often *not* the cheapest option.

{% hint style="info" %}
This is the more reliable of the two methods, because a single concrete price is a much easier question to answer honestly than "what would you pay?"
{% endhint %}

***

## Where to run a pricing survey

* **Post-purchase** — Your best respondents. They just paid, so their answers are anchored in a real transaction. Zigpoll automatically correlates order values with each response, so you can compare stated willingness-to-pay against what people actually spent.
* **On-site, targeted to product pages** — Reaches shoppers who are considering the product but haven't committed.
* **Email to past customers** — Ideal for testing a price increase on an existing product. See [Email Zigpoll Surveys](/email-zigpoll-surveys.md).
* **Before you have any traffic** — Use [Synthetic Research](/synthetic-research.md) to pressure-test your question wording and get directional signal from a target demographic before you spend real traffic on it.

***

## Turning answers into a decision

Once you have a meaningful sample (aim for 100+ responses per price point):

* **Cross-reference with order value.** If high-spend customers cluster at the top of your acceptable range, you're underpriced. Ask Z-GPT Chat in the **Insights** tab to compare price answers against order values.
* **Add a follow-up.** Use [Question Logic](/questions/question-logic.md) to branch: when someone picks a low price, ask an open-ended "What would make this worth more to you?" The answers usually name a missing feature, not a discount.
* **Segment before you commit.** A single blended price hides the fact that different groups value you differently. See [How to Build Your Ideal Customer Profile](/guides/how-to-build-your-ideal-customer-profile.md).

{% hint style="warning" %}
Stated willingness-to-pay always runs higher than real behavior — people are generous with hypothetical money. Treat survey pricing as a strong hypothesis and confirm it with a live test before you reprice your catalog.
{% endhint %}

***

## Related

{% content-ref url="/pages/enRwROsoKeKFUh7XMOOp" %}
[How to Validate a New Product Idea](/guides/how-to-validate-a-new-product-idea.md)
{% endcontent-ref %}

{% content-ref url="/pages/70rirBfJvG59hsGptkAE" %}
[How to Find Out Why Visitors Aren't Buying](/guides/how-to-find-out-why-visitors-arent-buying.md)
{% endcontent-ref %}


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.zigpoll.com/guides/how-to-find-optimal-pricing.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
