Pricing Strategy Stress Test Prompt

Stress-test the pricing strategy described below and produce a decision-ready assessment. Treat this as analysis and planning, not authorization to change prices, publish offers, contact customers, or run experiments.

Business inputs
- Business and offering: [Business and offering]
- Current or proposed pricing and packaging: [Current pricing and packaging]
- Customer segments and supporting evidence: [Customer segments and evidence]
- Unit economics and financial targets: [Unit economics and financial targets]
- Competitors, substitutes, and other market alternatives: [Market alternatives]
- Commercial, legal, operational, and approval constraints: [Constraints and approval boundaries]
- Pricing decision, objective, and time horizon: [Decision objective and horizon]
- Available experiment channels, sample sizes, and success thresholds: [Experiment capacity and success thresholds]

Input and evidence rules
1. Blocking inputs are the offering, target segments, pricing under review, decision objective, material constraints, and enough economic information to determine whether a recommendation is financially plausible. If any are missing or materially contradictory, ask up to five focused clarification questions before making a final recommendation.
2. Useful but non-blocking inputs include win-loss notes, customer interviews, surveys, conjoint or Van Westendorp results, transaction data, churn and expansion cohorts, discount history, sales objections, competitor pages, and prior pricing tests. Continue with bounded qualitative analysis if these are unavailable, but mark the affected conclusions as unverified.
3. Maintain an evidence ledger. Classify each important statement as a supplied fact, observed result, cited external evidence, assumption, hypothesis, conflict, or unknown. Do not convert anecdotes into measured willingness to pay or correlation into price causation.
4. Use only information supplied in the conversation or sources ChatGPT can actually access in the current session. If browsing is available and used, cite the source, publication date, and access date. Otherwise, state that external validation was not performed. Never invent competitor prices, customer reactions, research findings, test results, approvals, or financial data.
5. When inputs conflict, show the conflict and explain how it affects the decision. Use ranges or scenarios rather than false precision. State the currency, billing period, tax treatment, and whether figures are gross or net whenever they matter.

Analysis workflow
1. Define the decision boundary. Restate the exact pricing decision, affected products and segments, decision horizon, success measures, approval owner, reversible steps, and consequences of being wrong. Separate the baseline, proposed change, and any alternative strategies.
2. Reconstruct the current pricing system. Map list prices, billing cadence, price metric, package tiers, feature or usage fences, add-ons, minimum commitments, overages, trials, discounts, exceptions, renewal terms, and sales compensation effects. Identify ambiguity, discount leakage, inconsistent entitlements, and operational dependencies.
3. Segment demand. For each relevant segment, assess the job to be done, value drivers, purchase trigger, buyer and user roles, budget source, switching costs, usage pattern, service burden, price sensitivity, likely objections, and available evidence of willingness to pay. Do not recommend protected-class discrimination, covert personalized pricing, deceptive scarcity, or exploitative targeting.
4. Test the price metric and packaging logic. Determine whether the metric tracks customer value, is predictable, can be measured and billed, resists gaming, and does not punish healthy adoption. Examine tier differentiation, feature fences, good-better-best progression, upgrade paths, cannibalization, add-on complexity, and whether a lower tier anchors or erodes the target package.
5. Model economics using formulas that fit the business model. At minimum, test baseline, recommended, upside, and downside scenarios. Where data permits, calculate or estimate revenue per customer, gross margin, contribution margin, cost to serve, acquisition payback, retention or churn sensitivity, expansion, discount impact, mix shift, and break-even volume change. Show formulas, units, segment weights, assumptions, and rounding. Do not present a forecast as measured performance.
6. Build a revenue and margin bridge from the baseline to each scenario. Separate the effects of price, volume, segment mix, package migration, discounts, churn, expansion, taxes, payment fees, and incremental service or implementation costs. Flag double counting and metrics that cannot be reconciled from supplied data.
7. Compare market alternatives carefully. Assess competitors, substitutes, internal workarounds, and doing nothing on a comparable basis, including included usage, contract length, service level, implementation cost, and switching cost. Treat public list prices as directional when negotiated terms or packaging differ. Avoid recommendations based on coordination with competitors or non-public competitively sensitive information.
8. Stress-test adoption and execution. Examine likely customer objections, grandfathering choices, renewal timing, migration paths, channel conflict, sales incentives, quoting and billing readiness, entitlement changes, customer support load, tax or consumer-protection implications, and communication risks. Identify who may be harmed or unexpectedly excluded.
9. Compare viable options. Include retaining the baseline when appropriate. Score each option against strategic fit, customer value alignment, economic resilience, evidence strength, operational complexity, reversibility, legal or reputational exposure, and time to learn. Explain weights and show where reasonable changes in assumptions reverse the ranking.
10. Recommend a bounded decision. State the preferred option, segment scope, price and packaging logic, economic conditions required for it to work, confidence level, major dissenting evidence, no-go conditions, and what would change the recommendation. If evidence is insufficient, recommend research or a limited test rather than a broad rollout.
11. Design experiments without claiming to run them. Prefer reversible, ethically appropriate tests such as concept interviews, sales quote tests with approved controls, landing-page tests that do not mislead, or staged pilots. For each experiment define the hypothesis, eligible population, control or comparator, primary metric, guardrail metrics, minimum detectable effect or practical decision threshold, duration or stopping rule, instrumentation, bias risks, approval owner, rollback trigger, and decision rule. Note when statistical power cannot be estimated.
12. Prepare the approval handoff. Distinguish proposed, approved, scheduled, executed, measured, verified, blocked, and unavailable states. ChatGPT may analyze supplied material, perform transparent calculations, and draft recommendations. It must not claim to update billing systems, publish prices, approve a strategy, notify customers, execute tests, or measure results unless those actions actually occurred and evidence is provided.

Safety and authority boundaries
- Require explicit human approval before changing public prices, contracts, billing configuration, entitlements, sales compensation, customer communications, or experiment exposure.
- Do not expose personal data, confidential customer records, credentials, or non-public competitor information. Request aggregated or anonymized data and identify small cohorts that could enable re-identification.
- Flag, rather than resolve, jurisdiction-specific tax, competition, consumer-protection, accessibility, contract, or discrimination questions for qualified legal or finance review.
- Stop and explain the concern if the requested strategy depends on collusion, deceptive presentation, unauthorized data use, unlawful discrimination, or charges customers cannot reasonably understand or control.
- Recommend a staged rollout, monitoring plan, and rollback path when downside exposure is material. Do not recommend rollout if billing accuracy, customer notice, contractual authority, support readiness, or required approvals are unresolved.

Required output
A. Decision brief
- Decision under review, recommendation, confidence, decision horizon, expected mechanism, principal trade-off, and smallest safe next action.
- Current status using only the allowed states: proposed, approved, scheduled, executed, measured, verified, blocked, or unavailable.

B. Evidence and uncertainty ledger
A table with: claim or input; segment and period; value or observation; evidence classification; source; reliability; conflict or limitation; effect on recommendation; validation needed.

C. Pricing architecture map
A table comparing the baseline and each option across: target segment; price metric; billing cadence; package and entitlements; list price; discount or exception rules; usage limits and overages; migration treatment; operational dependency.

D. Segment and willingness-to-pay stress test
A table with: segment; job and value driver; evidence available; willingness-to-pay signal or unknown; price sensitivity; likely objection; switching alternative; service burden; package fit; confidence; implication. Keep qualitative signals distinct from measured estimates.

E. Unit-economics and scenario model
For baseline, recommended, upside, and downside cases, show inputs, formulas, outputs, units, and assumptions. Include the revenue and margin bridge, break-even volume or retention change, and sensitivity ranges. Mark every unavailable metric and do not fabricate a numerical substitute.

F. Option decision matrix
Compare at least the baseline and the strongest feasible alternatives. Show criteria, weights, scores, evidence basis, weighted result, key trade-offs, and sensitivity conditions that would change the ranking.

G. Risk, objection, and failure-mode register
A table with: risk or failure mode; trigger; affected segment; probability; impact; early indicator; mitigation; rollback or recovery action; owner; approval requirement; residual risk. Cover demand, margin, churn, cannibalization, discount leakage, billing, sales execution, customer trust, legal review, and measurement validity where relevant.

H. Experiment and rollout plan
Provide experiment cards containing: hypothesis; audience; comparator; offer treatment; primary metric; guardrail metrics; decision threshold; sample or power status; duration and stopping rule; instrumentation; confounders; approval owner; rollback trigger; and resulting decision. Follow with a staged rollout sequence only if prerequisites are satisfied.

I. Verification and acceptance record
Provide a table with: check; expected observation; actual observation from supplied evidence; evidence reference; status; discrepancy; owner; resolution required. Include these checks:
- Arithmetic and units can be independently recomputed.
- Scenario totals reconcile to the revenue and margin bridge.
- Segment weights and package migration assumptions are explicit.
- Willingness-to-pay claims trace to evidence and method.
- Discount, churn, volume, mix, and cost effects are not double counted.
- Downside cases remain within supplied financial and risk thresholds.
- Billing, entitlement, analytics, support, contract, notice, tax, and approval dependencies have named owners.
- Experiment metrics, guardrails, stopping rules, and rollback triggers are instrumentable.
- Any claimed execution, measurement, verification, or approval has dated evidence.

Use pass only when evidence demonstrates the expected observation. Otherwise use fail, blocked, not run, or unverified. Do not replace missing actual observations with expected outcomes.

J. Open decisions and approval handoff
List unresolved questions, conflicting evidence, required specialist reviews, named approval gates, no-go conditions, and the next evidence-producing action. Clearly state what ChatGPT analyzed versus what a human or operational system must still execute.