Test 5 pricing models on simulated customers.
A seat, a transaction, a subscription or a share of the result: the way you charge can change who buys, who uses the service and what both sides try to optimize. Give the same offering five different pricing structures and watch evidence-based simulated customers work through the consequences.
Try it now
Copy the prompt into your AI tool of choice, then answer its questions as they come.
Paste it into any AI chat to start. For most people, this is all you need.
Everything on this page in one paste: the prompt plus the full plan, every step and what to check. Use it for longer moves, to plan ahead, to share with a colleague, or if your AI can't open links.
How it goes
What the AI will do
- Build five different ways of charging for the same offering and calculate what each would mean for realistic customer bills and your costs.
- Use customer profiles you accept to run separate simulations, compare buying objections and usage incentives, then prepare a real-customer test.
What to have ready
- The offering and any current pricing; rough ideas or an existing proposal are enough to begin.
- Available customer research, invoices, usage, cost and sales records. The AI looks for useful evidence before asking you to assemble it.
Where you come in
- Correct and accept the simulated customer profiles and the five pricing structures before the encounters run.
- Resolve important unknown terms, review the comparison and choose which pricing hypotheses to test with real people.
What you'll get
Five worked pricing structures, comparable customer bills and unit economics, a source-linked account of simulated reactions, and a practical real-customer test brief.
You're done when
You have reviewed five genuinely different pricing structures, worked bills and contribution economics for comparable use cases, and simulations using customer profiles you accepted. The result identifies pricing hypotheses and how to test them with real customers.
These are general instructions, not a description of this user's particular AI system, tools, access, or circumstances. Adapt the method to the user's goal and the capabilities you can actually use, while preserving the activity's essential sequence, review points, and intended result. ### Start with the activity and the user's context Read the complete activity and guide the user through it. Use the activity prompt yourself; the user does not need to paste it again. Keep the responsibilities of the user, the AI, and any colleague clear. Begin with what the user has already supplied. Establish the intended result and resolve missing context through focused questions when needed. Work within the activity's stated scope, permissions, required confirmations, and stopping points, including any deliberate order for introducing information. Make progress with the available information and reasonable, clearly identified assumptions where the activity allows them. ### Check the capabilities needed for this work Inspect relevant available tools, connectors, and data. Use small, relevant, non-destructive checks to establish whether necessary access or a capability actually works. Naming a product does not establish access to it. Let this activity determine what needs checking; do not impose a universal preliminary questionnaire or a full system audit. When useful access is missing: - Explain what you cannot reach and how that material would help. - Investigate practical setup, connection, export, or other access alternatives before asking the user to gather material or troubleshoot. - If progress depends on access, request only the specific user action or permission needed to enable it or provide the material another way. Continue useful independent work while awaiting the response. - Offer to walk the user through an export or upload. Welcome files, links, copied text, rough notes, or an interview as supported by your system and the activity, and use the best available route. If the missing access is optional, continue with what is available. ### Ask focused questions and respect the answers Ask questions only when necessary to complete the work well or satisfy the activity's required review points. Build on answers already supplied. Ask one question at a time, or a small group of closely related questions. Wait on work that depends on the answer, and continue useful work that does not. Explain unfamiliar language with examples where helpful. Confirm answers or decisions you supply on the user's behalf before treating them as the user's final answers or decisions. This does not require separate approval of every sourced finding; follow the activity's specific review requirements. ### Keep evidence and independent contributions distinct Distinguish evidence, inference, and missing information. Check your work against the source material. Use independent agents when your system actually supports delegation and independent investigation or review would improve the work: - Give each agent a bounded brief and the context appropriate to its role. - Keep discovery independent until synthesis where the activity requires it. Preserve any requirement for the user or colleagues to contribute before seeing other explanations. - Follow the activity's stated fallback and any required confirmation when independent agents or fresh contexts are unavailable. Preserve reviewer isolation where required; describe shared-context or sequential passes accurately. ### Produce, check, and revise the result Do the substantive investigation and production. Carry the activity through to the most complete, usable result within its scope, rather than ending with a plan or handing the main work back to the user. When missing information does not prevent useful work, proceed with clearly identified assumptions where the activity permits them. Check the result against the activity's completion criteria. At each substantive delivery, state what is complete and any material unfinished work, assumptions, helpful missing information, and remaining uncertainty. Explain how these affect what the user can use, and help the user revise the result. Preserve the activity's stopping point. Do not turn a rehearsal, investigation, or test-design activity into execution that the user has not authorized. Help me compare five pricing structures for one offering using worked bills, unit economics and simulated customers. Use the full evidence-based customer-simulation method below. The result is a set of pricing hypotheses for real testing, not measured demand or a claim that real people accepted a price. ### 1. Understand the offer and find customer evidence Read the offering, current price list and supplied questions. Establish what is being sold, who uses it, who pays, the business objective and the actual alternative customers have. Inspect and try access to invoices, contracts, discount approvals, usage records, delivery and support costs, renewal and lost-deal notes, customer interviews, account email and chat, relevant WhatsApp exchanges, sales-call transcripts and product documents. Search names and terms from the offer to find existing personas and segments, purchasing objections, billing surprises and how customers actually use or ration the service. Use account roles, meeting invitations and interview records to distinguish user, buyer, budget holder and procurement influence. Check dates and the evidence behind existing personas. Separate observed transactions and use, reported preferences, our team's assumptions and missing information. If sources are unavailable, inspect connection or export options and help me provide permitted examples. Develop a proposed cast from what is available, using relevant primary public research when it answers an actual gap. If the basis is my experience or a hypothesis, label it. Ask focused questions one at a time rather than inventing missing usage or cost figures. ### 2. Agree the cast Propose a manageable set of customers covering materially different buying conditions. For each, show their role and situation; the job they need done; current alternative; expected scale and variability of use; budget process; important constraints, vocabulary and reasons to decline; and the sources or accepted assumptions supporting those traits. Include relevant counterexamples and unknowns. Choose differences because they affect this purchase, not to fill demographic categories. Invite me to edit profiles, add customers or remove people who do not belong. Ask the clarification that would most improve realism. Incorporate my changes and keep my proposed traits distinguishable from recorded evidence. Wait for my acceptance of the resulting cast before running reactions. ### 3. Build five structures and a common test Propose five meaningfully different charging mechanisms suited to the offer. Possible starting points are a flat subscription, per-seat charging, usage-based charging, a base fee plus included usage and overages, or outcome-based charging where an outcome can be defined and measured. These are examples, not a requirement to force an unsuitable mechanism onto the business. Five price points for one subscription do not fulfill the task. For each, specify the charging unit, included service, billing period, commitment, minimums, limits, overages, cancellation and other terms that materially affect the choice. For outcome pricing, make attribution and measurement explicit. Show how the mechanism changes incentives for adoption, sharing access, greater use, reduced use or reporting results. Keep the underlying offer and material service promises constant unless a difference is explicitly needed and labeled as a confound. Build a small calculator or reproducible table. Use comparable low, typical and high-use cases, plus a burst or growth case when relevant. For each accepted customer, apply the same usage assumptions to all five structures. Calculate their bill, effective cost per relevant unit, your delivery and support costs, and contribution under the available cost definition. Identify missing costs and show assumption ranges instead of false precision. Explain which structures change who bears uncertainty. Check formulas, units and thresholds with hand-worked examples. Show me the five models, assumptions and sample bills. Let me correct terms or agree explicit hypothetical inputs; wait on consequential unresolved choices. Freeze the resulting common stimulus: the same offer description, the same customer case, the five clearly described structures and the questions being tested. Do not quietly add benefits to rescue one model or treat illustrative prices as approved commercial terms. ### 4. Run isolated customer encounters Use separate agents or fresh sessions for the accepted customers where supported. Give each its accepted profile, relevant source evidence and uncertainties, the common offer, all five pricing structures and that profile's comparable usage cases. Withhold other customers' reactions, our preferred model and arguments for success. Run a large cast in bounded waves and track coverage. Rotate model presentation order across encounters where practical and record it; treat order checks as checks on this simulation, not statistical validation. Ask each customer to explain the offer and bill in their own words; walk through a concrete buying and use occasion; compare the five structures against their current alternative; identify confusing or missing terms; and describe how each structure might change adoption, usage, internal approval or refusal. Permit “none of these” and unresolved answers. Do not require every customer to complain or pick a winner. Where a calculator or usable pricing prototype exists, have the agent actually attempt a representative bill calculation or comparison using available tools and record what it did, including errors. Distinguish observed AI interaction with that artifact from an imagined customer walkthrough. Request a short reaction in the customer's voice, then the evidence or accepted assumption behind every substantive concern. Identify what cannot be known from the profile. Do not invent willingness-to-pay estimates, sales probabilities or statements by real people. If isolation is unavailable, explain that sequential role passes share context, offer precise handoffs for fresh chats, and agree the fallback before proceeding. Keep profiles and stimulus fixed. Shared-context reactions are not independent customer evidence. ### 5. Reconcile and revise Wait for independent encounters to finish. Compare comprehension, bill predictability, purchasing objections, incentives and contribution economics by profile and structure. Link findings to the exact term, worked case and source basis. Separate a repeated simulated concern from an individual situation; repetition among models does not establish customer prevalence. Investigate contradictions rather than averaging them into a popularity score. Identify which structures appear promising for which customers and what evidence could overturn that judgment. Present the few consequential improvements and their tradeoffs. Let me choose changes to the intended customer, price or commercial promises. Produce revised term sheets and the updated calculator, preserving the originals. Recheck affected bills and relevant customer encounters with fresh sessions where possible, labeling them revision checks. ### 6. Deliver and prepare real testing Deliver all five structures, assumptions and worked bills; the calculator and cost comparison; accepted profiles with evidence; a compact record of simulated encounters; and the chosen revisions. Explain whether a recommendation depends on unknown costs, hypothetical usage or an assumed customer constraint. Prepare a short real-customer test brief: whom to involve, which neutral pricing materials to show, a representative billing or purchase task, questions about current behavior and what would support or contradict each important hypothesis. Include an actual buying or commitment test only as a proposed next step with its terms to be authorized. Do not contact customers, change live prices or present simulated preference as market validation. Invite my corrections and finish with a usable comparison and a specific way to learn from real people. These instructions were written in September 2026 using the frontier models available at the time. You may now have better tools or models, or restrictions that make some tasks harder. Your AI should adapt to the tools and access you actually have and find the best available way to help. Everything here is a starting suggestion for you and your AI, not a proven best practice for every setup. Feel free to rewrite any of it to better meet your needs.
View full AI instructions
Test 5 pricing models on simulated customers.
What the AI will do
- Build five different ways of charging for the same offering and calculate what each would mean for realistic customer bills and your costs.
- Use customer profiles you accept to run separate simulations, compare buying objections and usage incentives, then prepare a real-customer test.
What you can provide
- The offering and any current pricing; rough ideas or an existing proposal are enough to begin.
- Available customer research, invoices, usage, cost and sales records. The AI looks for useful evidence before asking you to assemble it.
Where you'll take part
- Correct and accept the simulated customer profiles and the five pricing structures before the encounters run.
- Resolve important unknown terms, review the comparison and choose which pricing hypotheses to test with real people.
What you'll get
Five worked pricing structures, comparable customer bills and unit economics, a source-linked account of simulated reactions, and a practical real-customer test brief.
Activity context
A seat, a transaction, a subscription or a share of the result: the way you charge can change who buys, who uses the service and what both sides try to optimize. Give the same offering five different pricing structures and watch evidence-based simulated customers work through the consequences.
For the user
Bring the offering and whatever pricing information exists. The AI will find customer evidence, propose a cast for you to correct, and work out five genuinely different charging structures. You will accept the cast and terms before the simulations, then help choose what to take to real customers.
Guidance for the AI
These are general instructions, not a description of this user's particular AI system, tools, access, or circumstances. Adapt the method to the user's goal and the capabilities you can actually use, while preserving the activity's essential sequence, review points, and intended result.
Start with the activity and the user's context
Read the complete activity and guide the user through it. Use the activity prompt yourself; the user does not need to paste it again. Keep the responsibilities of the user, the AI, and any colleague clear.
Begin with what the user has already supplied. Establish the intended result and resolve missing context through focused questions when needed. Work within the activity's stated scope, permissions, required confirmations, and stopping points, including any deliberate order for introducing information. Make progress with the available information and reasonable, clearly identified assumptions where the activity allows them.
Check the capabilities needed for this work
Inspect relevant available tools, connectors, and data. Use small, relevant, non-destructive checks to establish whether necessary access or a capability actually works. Naming a product does not establish access to it. Let this activity determine what needs checking; do not impose a universal preliminary questionnaire or a full system audit.
When useful access is missing:
- Explain what you cannot reach and how that material would help.
- Investigate practical setup, connection, export, or other access alternatives before asking the user to gather material or troubleshoot.
- If progress depends on access, request only the specific user action or permission needed to enable it or provide the material another way. Continue useful independent work while awaiting the response.
- Offer to walk the user through an export or upload. Welcome files, links, copied text, rough notes, or an interview as supported by your system and the activity, and use the best available route. If the missing access is optional, continue with what is available.
Ask focused questions and respect the answers
Ask questions only when necessary to complete the work well or satisfy the activity's required review points. Build on answers already supplied. Ask one question at a time, or a small group of closely related questions. Wait on work that depends on the answer, and continue useful work that does not. Explain unfamiliar language with examples where helpful.
Confirm answers or decisions you supply on the user's behalf before treating them as the user's final answers or decisions. This does not require separate approval of every sourced finding; follow the activity's specific review requirements.
Keep evidence and independent contributions distinct
Distinguish evidence, inference, and missing information. Check your work against the source material.
Use independent agents when your system actually supports delegation and independent investigation or review would improve the work:
- Give each agent a bounded brief and the context appropriate to its role.
- Keep discovery independent until synthesis where the activity requires it. Preserve any requirement for the user or colleagues to contribute before seeing other explanations.
- Follow the activity's stated fallback and any required confirmation when independent agents or fresh contexts are unavailable. Preserve reviewer isolation where required; describe shared-context or sequential passes accurately.
Produce, check, and revise the result
Do the substantive investigation and production. Carry the activity through to the most complete, usable result within its scope, rather than ending with a plan or handing the main work back to the user. When missing information does not prevent useful work, proceed with clearly identified assumptions where the activity permits them.
Check the result against the activity's completion criteria. At each substantive delivery, state what is complete and any material unfinished work, assumptions, helpful missing information, and remaining uncertainty. Explain how these affect what the user can use, and help the user revise the result.
Preserve the activity's stopping point. Do not turn a rehearsal, investigation, or test-design activity into execution that the user has not authorized.
Your AI prompt
Help me compare five pricing structures for one offering using worked bills, unit economics and simulated customers. Use the full evidence-based customer-simulation method below. The result is a set of pricing hypotheses for real testing, not measured demand or a claim that real people accepted a price.
1. Understand the offer and find customer evidence
Read the offering, current price list and supplied questions. Establish what is being sold, who uses it, who pays, the business objective and the actual alternative customers have. Inspect and try access to invoices, contracts, discount approvals, usage records, delivery and support costs, renewal and lost-deal notes, customer interviews, account email and chat, relevant WhatsApp exchanges, sales-call transcripts and product documents. Search names and terms from the offer to find existing personas and segments, purchasing objections, billing surprises and how customers actually use or ration the service. Use account roles, meeting invitations and interview records to distinguish user, buyer, budget holder and procurement influence.
Check dates and the evidence behind existing personas. Separate observed transactions and use, reported preferences, our team's assumptions and missing information. If sources are unavailable, inspect connection or export options and help me provide permitted examples. Develop a proposed cast from what is available, using relevant primary public research when it answers an actual gap. If the basis is my experience or a hypothesis, label it. Ask focused questions one at a time rather than inventing missing usage or cost figures.
2. Agree the cast
Propose a manageable set of customers covering materially different buying conditions. For each, show their role and situation; the job they need done; current alternative; expected scale and variability of use; budget process; important constraints, vocabulary and reasons to decline; and the sources or accepted assumptions supporting those traits. Include relevant counterexamples and unknowns. Choose differences because they affect this purchase, not to fill demographic categories.
Invite me to edit profiles, add customers or remove people who do not belong. Ask the clarification that would most improve realism. Incorporate my changes and keep my proposed traits distinguishable from recorded evidence. Wait for my acceptance of the resulting cast before running reactions.
3. Build five structures and a common test
Propose five meaningfully different charging mechanisms suited to the offer. Possible starting points are a flat subscription, per-seat charging, usage-based charging, a base fee plus included usage and overages, or outcome-based charging where an outcome can be defined and measured. These are examples, not a requirement to force an unsuitable mechanism onto the business. Five price points for one subscription do not fulfill the task.
For each, specify the charging unit, included service, billing period, commitment, minimums, limits, overages, cancellation and other terms that materially affect the choice. For outcome pricing, make attribution and measurement explicit. Show how the mechanism changes incentives for adoption, sharing access, greater use, reduced use or reporting results. Keep the underlying offer and material service promises constant unless a difference is explicitly needed and labeled as a confound.
Build a small calculator or reproducible table. Use comparable low, typical and high-use cases, plus a burst or growth case when relevant. For each accepted customer, apply the same usage assumptions to all five structures. Calculate their bill, effective cost per relevant unit, your delivery and support costs, and contribution under the available cost definition. Identify missing costs and show assumption ranges instead of false precision. Explain which structures change who bears uncertainty. Check formulas, units and thresholds with hand-worked examples.
Show me the five models, assumptions and sample bills. Let me correct terms or agree explicit hypothetical inputs; wait on consequential unresolved choices. Freeze the resulting common stimulus: the same offer description, the same customer case, the five clearly described structures and the questions being tested. Do not quietly add benefits to rescue one model or treat illustrative prices as approved commercial terms.
4. Run isolated customer encounters
Use separate agents or fresh sessions for the accepted customers where supported. Give each its accepted profile, relevant source evidence and uncertainties, the common offer, all five pricing structures and that profile's comparable usage cases. Withhold other customers' reactions, our preferred model and arguments for success. Run a large cast in bounded waves and track coverage. Rotate model presentation order across encounters where practical and record it; treat order checks as checks on this simulation, not statistical validation.
Ask each customer to explain the offer and bill in their own words; walk through a concrete buying and use occasion; compare the five structures against their current alternative; identify confusing or missing terms; and describe how each structure might change adoption, usage, internal approval or refusal. Permit “none of these” and unresolved answers. Do not require every customer to complain or pick a winner.
Where a calculator or usable pricing prototype exists, have the agent actually attempt a representative bill calculation or comparison using available tools and record what it did, including errors. Distinguish observed AI interaction with that artifact from an imagined customer walkthrough. Request a short reaction in the customer's voice, then the evidence or accepted assumption behind every substantive concern. Identify what cannot be known from the profile. Do not invent willingness-to-pay estimates, sales probabilities or statements by real people.
If isolation is unavailable, explain that sequential role passes share context, offer precise handoffs for fresh chats, and agree the fallback before proceeding. Keep profiles and stimulus fixed. Shared-context reactions are not independent customer evidence.
5. Reconcile and revise
Wait for independent encounters to finish. Compare comprehension, bill predictability, purchasing objections, incentives and contribution economics by profile and structure. Link findings to the exact term, worked case and source basis. Separate a repeated simulated concern from an individual situation; repetition among models does not establish customer prevalence. Investigate contradictions rather than averaging them into a popularity score.
Identify which structures appear promising for which customers and what evidence could overturn that judgment. Present the few consequential improvements and their tradeoffs. Let me choose changes to the intended customer, price or commercial promises. Produce revised term sheets and the updated calculator, preserving the originals. Recheck affected bills and relevant customer encounters with fresh sessions where possible, labeling them revision checks.
6. Deliver and prepare real testing
Deliver all five structures, assumptions and worked bills; the calculator and cost comparison; accepted profiles with evidence; a compact record of simulated encounters; and the chosen revisions. Explain whether a recommendation depends on unknown costs, hypothetical usage or an assumed customer constraint.
Prepare a short real-customer test brief: whom to involve, which neutral pricing materials to show, a representative billing or purchase task, questions about current behavior and what would support or contradict each important hypothesis. Include an actual buying or commitment test only as a proposed next step with its terms to be authorized. Do not contact customers, change live prices or present simulated preference as market validation. Invite my corrections and finish with a usable comparison and a specific way to learn from real people.
Done when
You have reviewed five genuinely different pricing structures, worked bills and contribution economics for comparable use cases, and simulations using customer profiles you accepted. The result identifies pricing hypotheses and how to test them with real customers.
These instructions were written in September 2026 using the frontier models available at the time. You may now have better tools or models, or restrictions that make some tasks harder. Your AI should adapt to the tools and access you actually have and find the best available way to help. Everything here is a starting suggestion for you and your AI, not a proven best practice for every setup. Feel free to rewrite any of it to better meet your needs.
These instructions were written in September 2026 using the frontier models available at the time. You may now have better tools or models, or restrictions that make some tasks harder. Your AI should adapt to the tools and access you actually have and find the best available way to help. Everything here is a starting suggestion for you and your AI, not a proven best practice for every setup. Feel free to rewrite any of it to better meet your needs.