50 Claude Prompts That Set Your Pricing and Packaging

You are a packaging strategist who designs software plan structures that sell themselves. <context> My plans grew by accretion. Features landed wherever they were convenient and now nobody, including my own team, can explain who should buy which plan. </context> <inputs> - Full feature list: [PASTE FEATURES, GROUPED IF POSSIBLE] - Segments I serve: [SEGMENT NAMES AND SIZES] - Current plans and prices: [PLANS, PRICES, SHARE OF REVENUE EACH] - Value metric: [SEATS, USAGE UNITS, OTHER] - Features that drive upgrade conversations today: [WHAT PEOPLE ASK FOR] - Margin floor: [PERCENT] </inputs> <task> Design three tiers plus an enterprise path. For each tier give the target buyer in one sentence, the job the tier does, the included features, the value metric limits, the price, and the single reason someone upgrades to the next tier. Assign every feature I listed to exactly one starting tier and justify any feature you move out of a tier where customers have it today. End with the upgrade triggers, meaning the specific moments in the product where a customer runs into the boundary. </task> <constraints> - Each tier needs one obvious reason to exist; if two tiers share a buyer, merge them. - Do not strip a feature customers already rely on without listing it as a migration risk. - Keep price steps at a ratio you state and defend, not arbitrary jumps. </constraints> <format> Return a packaging table as an artifact with tiers as columns and features as rows, then the upgrade trigger list and the migration risks. </format>

You are a packaging analyst who decides which features gate which plans. <context> Every new feature triggers the same argument: does it go in the base plan to help adoption or in the top plan to drive revenue. I want a rule, not another debate. </context> <inputs> - Features to place: [LIST OF FEATURES, INCLUDING UPCOMING ONES] - Who asks for each one: [SEGMENT OR ROLE PER FEATURE, IF KNOWN] - Cost to serve each feature: [HIGH, MEDIUM, LOW OR ACTUAL COST] - Current tier structure: [PLANS AND PRICES] - Strategic goal this year: [ADOPTION, EXPANSION, MOVING UPMARKET] </inputs> <task> Classify each feature on two axes: how much it differentiates a buying decision, and which segment demands it. Then assign each to one of four buckets: table stakes in every plan, differentiator for the mid tier, enterprise or admin gate, and paid add-on. Produce the allocation matrix, the one-line rationale per feature, and a written packaging rule I can apply to the next feature without re-running this exercise. </task> <constraints> - Never gate a feature that is required for a customer to reach first value. - Security and access control features go in the tier that matches who buys them, and say which. - Flag any feature where the cost to serve makes inclusion in a low tier unprofitable. </constraints> <format> Return the allocation matrix as a table artifact, then the packaging rule as five numbered decision criteria. </format>

You are a positioning writer who names software plans and writes the lines that sell them. <context> My plans are called Basic, Pro and Premium, which tells a buyer nothing about which one is meant for them. I want names and descriptions that do the qualifying work. </context> <inputs> - Tiers and what each includes: [TIER CONTENTS] - Target buyer per tier: [ROLE, COMPANY SIZE] - Brand voice: [PLAIN, TECHNICAL, PLAYFUL, FORMAL] - Words rivals already own: [THEIR PLAN NAMES] - Where the names appear: [PRICING PAGE, INVOICES, IN-APP, CONTRACTS] </inputs> <task> Propose three naming systems: one describing the buyer, one describing the scale of use, and one describing the outcome. For each system give the tier names, a one-line description under each name that says who it is for, and the trade-offs of that system. Recommend one, then write the final pricing page block per tier: name, one-line who it is for, the three-word value summary, and the upgrade nudge line pointing at the next tier. </task> <constraints> - No name that a customer would have to translate before understanding it. - Names must survive a future fourth tier being added above or below. - Avoid any name a rival already owns from my list. </constraints> <format> Return the three systems in a comparison table, then the recommended system and the final pricing page copy per tier as an artifact. </format>

You are a packaging engineer who sets the numeric limits inside software plans. <context> My plan limits were guesses. Some customers never come close to them and others hit a wall in week two and churn instead of upgrading. </context> <inputs> - Limit types available: [SEATS, PROJECTS, RECORDS, API CALLS, STORAGE, HISTORY] - Usage distribution by plan: [PERCENTILES OR TYPICAL VALUES IF YOU HAVE THEM] - Current limits: [PLAN, LIMIT VALUES] - Cost driven by each limit: [WHICH LIMITS ACTUALLY COST ME MONEY] - Upgrade path: [NEXT TIER PRICE AND WHAT IT UNLOCKS] </inputs> <task> Set every limit per tier using my usage distribution so that the limit is generous for the tier's intended buyer and binding for the buyer who belongs one tier up. For each limit state the number, the percentile of users it catches, and whether hitting it is a hard block, a soft warning, or billable overage. Design the moment a customer hits the limit: the in-product message, the choice offered, and what happens if they do nothing. Add the limits that should never exist because they cost me nothing and only cause frustration. </task> <constraints> - Every hard block needs a clear self-serve path out within one screen. - Do not limit anything that costs me nothing to provide unless it is a genuine tier differentiator. - State the percentile behind each number so I can move it deliberately later. </constraints> <format> Return the limits table as an artifact with tier, limit, value, percentile and enforcement type, then the limit-reached experience spec. </format>

You are a packaging strategist deciding whether a capability belongs inside a plan or sells separately. <context> I have a capability that some customers love and most never touch. Bundling it into every plan feels wasteful, and selling it separately might mean nobody finds it. </context> <inputs> - The capability and what it does: [FEATURE, OUTCOME] - Share of customers who would use it: [PERCENT OR ESTIMATE] - Cost to serve it: [COST PER ACCOUNT OR PER UNIT] - Willingness to pay signal: [WHAT ANYONE HAS SAID OR PAID FOR SOMETHING SIMILAR] - Current tiers and prices: [PLANS AND PRICES] - Sales motion: [SELF SERVE, SALES ASSISTED, BOTH] </inputs> <task> Decide between four options: include it everywhere, gate it to a higher tier, sell it as a paid add-on, or sell it as a usage-metered extra. Score each against attach rate, revenue per account, discoverability, sales complexity and margin. Recommend one with a price if it is sold separately, model annual revenue under each option using my adoption estimate, and specify how customers discover it in-product under the recommended option. </task> <constraints> - Do not create an add-on that costs more to sell and bill than it earns; state the threshold. - If adoption is above roughly half the base, bias toward bundling and say why. - Include the churn risk of moving an existing free capability behind a paywall. </constraints> <format> Return the scoring table and revenue model as an artifact, then the recommendation with pricing and the in-product discovery plan. </format>

You are an enterprise packaging lead who defines what actually belongs in a Contact Sales tier. <context> My enterprise plan is a Contact Sales button with nothing behind it. Deals stall because neither my team nor the buyer knows what enterprise includes. </context> <inputs> - What larger prospects have asked for: [SSO, SCIM, AUDIT LOGS, SLA, DPA, RESIDENCY, ROLES] - Deals lost for missing capabilities: [WHAT WAS MISSING, DEAL SIZE] - Current top tier and price: [TIER, PRICE] - Target enterprise contract value: [ACV TARGET] - What I can support today: [SECURITY POSTURE, SUPPORT HOURS, LEGAL CAPACITY] </inputs> <task> Define the enterprise tier: the capability list split into ship now, ship next quarter and decline politely, the commercial terms (minimum commitment, contract length, payment terms, uplift for non-standard terms), the support and SLA package with response times I can actually meet, and the pricing approach with a starting floor. Add the qualification questions that decide whether a prospect goes to enterprise or self-serve, and the three questions in a security review that I currently cannot answer. </task> <constraints> - Only include commitments I can meet today with the capacity I listed. - Give a real starting price floor rather than pure Contact Sales. - Rank the missing capabilities by how often they blocked a deal in my inputs. </constraints> <format> Return the enterprise tier definition as a document artifact, including the capability table, commercial terms and qualification questions. </format>

You are a product-led growth designer who sets the line between free and paid. <context> My free plan is either too generous, because nobody upgrades, or too thin, because nobody reaches value. I need the boundary set deliberately. </context> <inputs> - Product and its aha moment: [PRODUCT, THE MOMENT VALUE LANDS] - Free plan today: [WHAT IS INCLUDED AND ANY LIMITS] - Free to paid conversion now: [PERCENT OR UNKNOWN] - Cost to serve a free account: [COST PER MONTH] - Entry paid plan: [PRICE AND WHAT IT ADDS] - Where free users get stuck or leave: [ANY EVIDENCE] </inputs> <task> Redesign the free plan around one principle you state up front: free must reliably deliver the aha moment and must stop just before the point where the product becomes operationally load-bearing for the customer. Specify what free includes forever, the exact limits, what is visible but locked, and the upgrade prompt at each boundary. Then model the effect: expected change in conversion, in free base cost, and in signup volume, with the reasoning for each. </task> <constraints> - Never block the aha moment behind a paywall. - Every locked item must be visible so free users know what upgrading buys. - Include an abuse control for the specific way my free plan could be exploited. </constraints> <format> Return the free plan spec as a document artifact with the limits table, the locked-but-visible list, the upgrade prompts and the modeled impact. </format>

You are a conversion-focused writer who builds pricing pages for software companies. <context> My pricing page lists features and prices and converts badly. Visitors read it, cannot tell which plan is for them, and leave. </context> <inputs> - Tiers, prices and contents: [PLANS, PRICES, KEY FEATURES] - Target buyer per tier: [ROLE, COMPANY SIZE] - The plan I want most people to choose: [PLAN NAME] - Objections I hear about price: [TOP THREE] - Proof available: [LOGOS, NUMBERS, CASE STUDIES, GUARANTEES] - Billing options: [MONTHLY, ANNUAL, DISCOUNT PERCENT] </inputs> <task> Write the full pricing page: the headline and subhead, the monthly and annual toggle with the annual saving stated the way buyers do the math, each plan card with name, price, who it is for, the four features that matter and the call to action, the comparison table grouped by job to be done rather than by engineering area, an objection-handling section answering my three objections, and a six question FAQ. Mark the recommended plan and say how it should be visually emphasized. </task> <constraints> - Feature rows must be written in buyer language, no internal names. - Every claim on the page must map to proof I listed or be cut. - No superlatives and no vague benefits like powerful or seamless. </constraints> <format> Return the complete page copy as a document artifact in the order it appears on screen, with a short layout note before each block. </format>

You are a commercial policy writer who drafts usage terms for software products. <context> Customers occasionally blow past their limits and I improvise every time. I need one written policy that support, sales and finance all apply the same way. </context> <inputs> - Metered items and included allowances: [UNITS AND LIMITS PER PLAN] - Cost to me per extra unit: [COST] - How often accounts exceed limits: [ROUGH FREQUENCY] - Worst overage incident so far: [WHAT HAPPENED] - Billing capability: [CAN I BILL OVERAGE AUTOMATICALLY, YES OR NO] - Support policy today: [WHAT WE DO NOW, EVEN IF INFORMAL] </inputs> <task> Write the overage and fair-use policy: the grace threshold before anything is charged, the overage rate and how it is derived from my cost, the notification sequence at fifty, eighty, one hundred and one hundred twenty percent of allowance, what happens on sustained overage versus a one-off spike, the automatic forgiveness rule for first offenses, and the escalation path to an upgrade conversation. Include the customer-facing wording and the internal decision table support uses. </task> <constraints> - Never charge overage without a prior notification the customer actually received. - Spikes caused by my own outages or retries are never billable. - Keep the customer-facing wording under two hundred words and free of legalese. </constraints> <format> Return two artifacts in one document: the customer-facing policy and the internal decision table with thresholds, actions and owners. </format>

You are a portfolio pricing strategist who packages multiple products into suites. <context> I sell several products separately. Customers who buy two get no benefit from buying from me twice, and my sales team has no reason to push the second product. </context> <inputs> - Products and standalone prices: [PRODUCT NAMES AND PRICES] - Attach rates between them: [WHAT PERCENT OF PRODUCT A BUYERS TAKE B] - Overlapping buyers: [WHICH ROLES BUY WHICH PRODUCT] - Cost to serve each: [COST OR MARGIN PER PRODUCT] - Goal: [INCREASE ATTACH, RAISE ACV, DEFEND AGAINST A POINT SOLUTION] </inputs> <task> Design the bundle: which products go together and why, the bundle price with the discount stated against the sum of standalone prices, the margin at that discount, and the rule for when a customer may still buy standalone. Model three scenarios: current mix, bundle with modest attach lift, and bundle with strong attach lift, showing revenue and margin for each. Then write the one-paragraph pitch the sales team uses and the two conditions under which bundling would cannibalize revenue rather than grow it. </task> <constraints> - The bundle discount must be justified by a real cost or expansion benefit, not by habit. - Do not bundle products bought by different budget owners without saying how the deal gets approved. - Show the cannibalization case honestly, including the break-even attach rate. </constraints> <format> Return the bundle design and the three-scenario model as a table artifact, then the sales pitch paragraph and the break-even attach rate. </format>

You are a pricing researcher who runs price sensitivity studies for software companies. <context> I want to run a Van Westendorp price sensitivity study but I need the survey written correctly, including screening, or the results will be noise. </context> <inputs> - Product and what it replaces: [PRODUCT, THE ALTERNATIVE] - Who I will survey: [SEGMENT, ROLE, HOW I REACH THEM] - Current price if any: [PRICE OR NOT LAUNCHED] - Billing unit respondents should price: [PER USER PER MONTH, PER ACCOUNT, PER UNIT] - Sample size I can realistically get: [NUMBER] - Channels for distribution: [EMAIL LIST, IN-APP, PANEL, COMMUNITY] </inputs> <task> Write the complete survey. Start with a product description of at most eighty words that respondents read before pricing anything, worded neutrally so it does not anchor them. Add three screening questions that remove people who would never buy. Then the four Van Westendorp questions in the standard order with my billing unit written into each. Add two follow-up questions on budget authority and current spend on the alternative. Finish with the fielding plan: sample target, expected response rate, incentive, and the minimum responses needed before the results mean anything. </task> <constraints> - The product description must not mention any price, discount or comparison. - Question wording must use my billing unit consistently in all four questions. - State the segment cuts I should be able to analyze and what sample each cut needs. </constraints> <format> Return the survey as a document artifact ready to paste into a survey tool, then the fielding plan as a short checklist. </format>

You are a pricing analyst who interprets price sensitivity data for commercial decisions. <context> My price sensitivity survey is back. I have a spreadsheet of responses and no confidence in reading the curves without talking myself into the answer I already wanted. </context> <inputs> - Raw responses: [PASTE THE FOUR PRICE ANSWERS PER RESPONDENT, OR SUMMARY STATS] - Sample size and segments: [TOTAL, PLUS ANY SEGMENT TAGS] - Current price: [PRICE OR NOT LAUNCHED] - Cost to serve per account: [COST] - Business goal: [PENETRATION, MARGIN, REVENUE MAXIMIZATION] </inputs> <task> Compute the four intersection points: point of marginal cheapness, point of marginal expensiveness, optimal price point and indifference price point. Report the range of acceptable prices and the range of stress-free prices. Then interpret them against my cost and my goal: recommend a price, say where in the acceptable range it sits and why, and cut the analysis by segment if the tags allow. Flag any data quality problem, including responses where the four answers are not in a logical order. </task> <constraints> - Show the computed intersection values, not just the conclusion. - Exclude illogical response sets and report how many you dropped. - State clearly that this measures stated preference, and name the one thing it cannot tell me. </constraints> <format> Return the four intersection points and ranges in a table artifact, then the price recommendation with reasoning and the data quality notes. </format>

You are a customer research lead who runs pricing interviews without leading the witness. <context> I need to talk to customers about price, but every conversation I have had so far ended with them politely saying it should be cheaper, which taught me nothing. </context> <inputs> - Product and the outcome it delivers: [PRODUCT, OUTCOME] - Who I am interviewing: [ROLE, SEGMENT, CUSTOMER OR PROSPECT] - What I need to learn: [PRICE LEVEL, MODEL, TIER FIT, ALL THREE] - Current price: [PRICE OR NOT SET] - Time per interview: [MINUTES] </inputs> <task> Write a thirty question interview guide structured in five parts: current process and what it costs them today, how they measure the value of solving this, budget and approval reality, reaction to the pricing model separately from the price level, and price reaction using anchoring-safe techniques. Mark which questions are must-ask if the interview runs short. Add the three phrases that will bias the answer and what to say instead, plus a one-page synthesis template for capturing each interview in the same shape. </task> <constraints> - No question that asks how much they would pay as an opening move. - Push every value claim toward a number: hours, headcount, error rate or money. - Keep the whole guide inside the time I stated and mark the timing per section. </constraints> <format> Return the interview guide as a document artifact with sections and timings, then the biased-phrase list and the synthesis template. </format>

You are a quantitative pricing researcher who designs purchase intent ladders. <context> I want a demand curve for my product, not just a comfortable price range. I need to test specific price points and see where intent collapses. </context> <inputs> - Product and billing unit: [PRODUCT, PER USER PER MONTH OR OTHER] - Price points I am considering: [THREE TO SEVEN CANDIDATE PRICES] - Audience and reachable sample: [SEGMENT, NUMBER] - Cost to serve: [COST PER ACCOUNT] - Current price if launched: [PRICE OR NOT LAUNCHED] </inputs> <task> Design the Gabor-Granger test: the randomized starting price logic, the purchase intent scale and the exact wording of the ladder question, the step-up and step-down rules, and the stopping condition. Specify the sample needed per price point for a usable read. Then build the analysis template: intent percentage by price, the implied demand curve, revenue per hundred respondents at each price, and contribution margin at each price using my cost. Say which price maximizes revenue and which maximizes margin, and note when those diverge. </task> <constraints> - Randomize the starting price and explain why that matters for this method. - Treat top-box intent conservatively and state the discount factor you apply to stated intent. - Show revenue and margin per price point, not just intent. </constraints> <format> Return the test design as a document artifact, then the analysis template as a table with one row per price point. </format>

You are a conjoint analysis specialist who designs trade-off studies for product packaging. <context> I need to know which features actually justify a higher tier. Asking customers to rank features gives me a list where everything is important. </context> <inputs> - Features under consideration: [FIVE TO EIGHT FEATURES] - Price levels to test: [THREE TO FIVE PRICES] - Other attributes that matter: [SUPPORT LEVEL, LIMITS, CONTRACT LENGTH] - Audience and sample available: [SEGMENT, NUMBER] - Decision I need to make: [WHAT GOES IN THE MID TIER, WHAT JUSTIFIES A PREMIUM] </inputs> <task> Design a choice-based conjoint study. Define the attributes and levels including price, keeping the design small enough for my sample. Specify the number of choice tasks per respondent, the profiles per task, and whether to include a none option and why. Write the respondent instructions and one worked example choice task. Then explain the analysis plan in plain language: how utilities become willingness to pay per feature, how to read the price coefficient, and how to simulate a tier lineup against the results. </task> <constraints> - Keep attributes and levels within what my sample size can support and say what that limit is. - Every level must be a realistic option, no straw men. - Explain the analysis without statistical jargon a founder cannot act on. </constraints> <format> Return the study design as a document artifact with the attribute and level table, one example choice task, and the analysis plan. </format>

You are a revenue analyst who estimates price sensitivity from historical data instead of surveys. <context> I have never run a formal pricing study but I have years of quotes, discounts and closed deals. I want to extract a sensitivity read from what already happened. </context> <inputs> - Deal data available: [QUOTED PRICE, DISCOUNT, WON OR LOST, SEGMENT, DATE] - Any past price changes: [WHAT CHANGED AND WHEN] - Trial or signup data: [CONVERSION BY PLAN OR PRICE, IF ANY] - Segments to compare: [SEGMENT TAGS AVAILABLE] - Confounders I know about: [PRODUCT CHANGES, MARKETING SHIFTS, SEASONALITY] </inputs> <task> Estimate price sensitivity from my data. Compute win rate by price band and by discount depth, conversion by plan price, and the revenue effect of each past price change adjusted for the confounders I listed. Produce a rough elasticity read per segment and say how confident it is and why. Then recommend the price move the data supports, the size of the move, and the one clean experiment that would confirm it. List the analyses I cannot run yet and the fields I need to start capturing. </task> <constraints> - Separate correlation from causation explicitly wherever discount depth and deal size move together. - State the confidence level of every estimate in plain language. - Do not produce an elasticity number when the data does not support one; say so instead. </constraints> <format> Return the analysis as a table artifact by segment and price band, then the recommended move, the confirming experiment, and the missing data list. </format>

You are a revenue operations analyst who separates real price problems from stated ones. <context> Half my losses are logged as too expensive. I suspect most of them are actually value, timing or fit problems wearing a price costume. </context> <inputs> - Lost deals with stated reasons: [PASTE DEALS, REASON, SIZE, SEGMENT, STAGE LOST] - Discounts offered before losing: [DISCOUNT PERCENT PER DEAL, IF ANY] - Won deals for comparison: [PRICE, DISCOUNT, SEGMENT] - Sales notes or call snippets: [PASTE ANY VERBATIM QUOTES] - Rival named in each loss: [WHO THEY CHOSE, OR NONE] </inputs> <task> Classify every price loss into one of five root causes: genuine budget ceiling, value not established, wrong buyer or timing, packaging mismatch where the right tier did not exist, and rival with a lower anchor. Quantify each bucket in deals and revenue. For the two largest buckets, recommend the fix and say whether it is a pricing change, a packaging change or a sales process change. Finish with the three questions to add to loss logging so the next quarter of data is diagnostic rather than a single checkbox. </task> <constraints> - Use the verbatim quotes as evidence and cite which quote drove each classification. - Say explicitly what share of price losses would not be fixed by lowering the price. - Rank fixes by revenue recovered per unit of effort. </constraints> <format> Return the classification as a table artifact with counts and revenue per bucket, then the two recommended fixes and the loss logging questions. </format>

You are an experimentation lead who designs pricing tests that produce trustworthy results. <context> I want to test a new price on real traffic without upsetting existing customers or drawing a conclusion from noise. </context> <inputs> - Current price and plan: [PRICE, PLAN] - Proposed test price or structure: [WHAT CHANGES] - Traffic and conversion today: [VISITORS PER WEEK, CONVERSION RATE] - Average revenue per new customer: [ARPU OR ACV] - Constraints: [EXISTING CUSTOMERS MUST NOT SEE IT, LEGAL LIMITS, BRAND LIMITS] - How long I can run it: [WEEKS] </inputs> <task> Design the experiment: the hypothesis in a testable sentence, the primary metric (revenue per visitor, not conversion rate) and the guardrail metrics, the allocation and exclusion rules that keep existing customers out, the sample size and runtime needed for a decision at my traffic level, and the stopping rules including when to kill it early. Add the honoring policy for anyone who buys at the test price, and the analysis plan including which segment cuts are legitimate and which would be data dredging. </task> <constraints> - Primary metric must be revenue per visitor so a cheaper price cannot win on volume alone. - If my traffic cannot reach significance in the time available, say so and propose a sequential or geographic alternative. - Every visitor who sees a price must be able to buy at that price. </constraints> <format> Return the experiment design as a document artifact with the sample size math, the stopping rules and the analysis plan. </format>

You are a value engineer who builds ROI models that survive a finance review. <context> Buyers ask what the product is worth to them and I answer with adjectives. I need a model that turns my product into a number on their spreadsheet. </context> <inputs> - Product and the outcome it produces: [PRODUCT, OUTCOME] - Where the value shows up: [TIME SAVED, ERRORS AVOIDED, REVENUE GAINED, COST REMOVED] - Evidence from existing customers: [ANY MEASURED RESULTS] - Typical customer profile: [HEADCOUNT, VOLUME, SALARY LEVELS] - My price: [PRICE AND MODEL] </inputs> <task> Build a value model with explicit inputs, formulas and outputs. For each value driver, define the input the customer supplies, the formula, and the conservative, expected and optimistic assumption. Compute annual value, payback period in months and return on investment against my price. Include a sensitivity view showing which single input moves the answer most. Then write the one-page version a buyer forwards to their finance team, with the assumptions listed openly rather than hidden. </task> <constraints> - Use conservative assumptions in the headline number and show the optimistic case separately. - Every formula must be checkable by hand; no black box multipliers. - If a value driver cannot be measured by the customer, mark it as qualitative and keep it out of the total. </constraints> <format> Return the model as a table artifact with inputs, formulas and three scenarios, then the one-page finance summary. </format>

You are a pricing lead presenting research findings to a leadership team that has to make a decision today. <context> I have survey data, interview notes and deal analysis. I need to turn it into a readout that ends with a decision rather than a discussion. </context> <inputs> - Research completed: [METHODS, SAMPLE SIZES, DATES] - Headline findings: [PASTE KEY NUMBERS AND QUOTES] - The decision on the table: [PRICE CHANGE, NEW TIER, MODEL SWITCH] - Options under consideration: [TWO OR THREE OPTIONS] - Audience and their concerns: [WHO IS IN THE ROOM, WHAT WORRIES EACH] - Revenue context: [CURRENT ARR, GROWTH, RETENTION] </inputs> <task> Write the readout as twelve slides with speaker notes: the decision requested up front, the method and sample with its limitations stated honestly, the three findings that matter with the evidence for each, the options with modeled revenue impact for each, the recommendation with the reasoning chain, the risks and how each is mitigated, the rollout plan with dates and owners, and the metrics that will tell us within ninety days whether it worked. Add an appendix list of the analyses behind each claim. </task> <constraints> - Slide one states the decision requested and the recommendation, no build-up. - Every finding cites the method and sample it came from. - Pre-empt each audience member's stated concern somewhere in the deck and say where. </constraints> <format> Return the deck as a document artifact with a title, bullets and speaker notes per slide, then a one-paragraph pre-read summary. </format>

You are a monetization lead who has run price increases across an installed base. <context> I have not raised prices since launch and the product does much more now. I need to decide whether to raise, by how much, and for whom, before I write a single customer email. </context> <inputs> - Current prices and last change: [PRICES, DATE OF LAST INCREASE] - What has been added since: [FEATURES, CAPACITY, SUPPORT] - Cost changes since: [INFRA, AI SPEND, SUPPORT, PERCENT INCREASE] - Retention and expansion today: [GROSS RETENTION, NET RETENTION] - Customer concentration: [SHARE OF REVENUE IN TOP TEN ACCOUNTS] - Contract mix: [MONTHLY VERSUS ANNUAL SPLIT] </inputs> <task> Recommend whether to raise prices now. Model three scenarios: no change, a moderate increase and an aggressive increase, each showing new revenue, expected churn from the increase, net revenue effect after twelve months, and the break-even churn rate at which the increase stops paying. Recommend the increase size, who it applies to (new customers only, new plus renewals, or everyone), and the timing relative to my renewal calendar. State the three preconditions that must be true before I proceed. </task> <constraints> - Show the break-even churn rate explicitly for each scenario. - Never recommend applying an increase to the top revenue accounts in the same wave as the long tail. - If retention is below a level you consider safe, say to fix retention first and say why. </constraints> <format> Return the three-scenario model as a table artifact, then the recommendation, the preconditions and the timing plan. </format>

You are a customer communications writer who has announced price increases without triggering a churn spike. <context> The increase is decided. Now I have to tell customers in a way that respects them, explains the reasoning, and does not read like a legal notice. </context> <inputs> - Old and new price: [BEFORE, AFTER, PERCENT CHANGE] - Who receives this email: [SEGMENT, PLAN, CONTRACT TYPE] - Effective date and notice period: [DATE, DAYS OF NOTICE] - What has genuinely improved: [SPECIFIC SHIPPED IMPROVEMENTS] - Protections offered: [LOCK-IN OPTION, ANNUAL PREPAY, GRANDFATHERING] - Tone: [PLAIN, WARM, FORMAL] </inputs> <task> Write the announcement email: subject line and two alternatives, the opening that states the change and the date in the first two lines, the reasoning grounded in what shipped rather than in vague cost pressure, exactly what this customer will pay and when, the options available to them including any way to lock the old price, and a direct line to reply or talk to a human. Then write the two follow-ups: a reminder seven days before the effective date and a response template for anyone who replies unhappy. </task> <constraints> - State the new price and date in the first two lines, never buried at the bottom. - No corporate hedging like adjusting our pricing structure; say the price is going up. - Do not blame inflation or costs if the honest reason is that the product is worth more. </constraints> <format> Return the main email, the reminder and the reply template as one document artifact, each clearly labeled and ready to send. </format>

You are a commercial policy designer who decides who keeps an old price and for how long. <context> I am raising prices and I have to decide who gets protected. Grandfathering everyone forever leaves permanent revenue on the table; grandfathering nobody costs me my earliest supporters. </context> <inputs> - Customer cohorts by signup date: [COHORTS AND COUNTS] - Revenue per cohort: [AMOUNTS OR SHARE] - Old and new price: [BEFORE, AFTER] - Contract terms: [MONTHLY, ANNUAL, MULTI-YEAR] - Strategic value of early customers: [REFERENCES, CASE STUDIES, ADVOCACY] - How long I can afford the protection: [MONTHS OR OPEN] </inputs> <task> Design the grandfathering policy: which cohorts are protected, for how long, and under what conditions the protection ends, for example plan changes, seat increases or a lapse in payment. Model the revenue given up under three options: permanent protection, twelve month protection and protection only until the next renewal. Recommend one, write the customer-facing policy in plain language, and write the internal rules support uses to answer the question of whether a specific account is protected. </task> <constraints> - Any protection must have a clear ending condition, even if the end date is far out. - The rules must be answerable by support without escalation in the common cases. - Do not offer protection you cannot enforce in your billing system; flag anything that needs manual tracking. </constraints> <format> Return the three-option revenue model as a table, then the recommended policy in customer-facing and internal versions as a document artifact. </format>

You are a lifecycle operations lead who moves customers off retired plans without losing them. <context> I have five legacy plans nobody can buy anymore, each with its own quirks. Supporting them costs engineering time and makes every pricing conversation harder. </context> <inputs> - Legacy plans in force: [PLAN NAMES, PRICES, CUSTOMER COUNTS, REVENUE] - Current plan lineup: [PLANS AND PRICES] - What legacy customers would gain or lose: [PER PLAN] - Contract and renewal dates: [WHEN EACH COHORT RENEWS] - Team capacity for outreach: [WHO, HOW MANY HOURS] </inputs> <task> Build the migration plan. Map each legacy plan to its best current equivalent and flag every case where a customer loses something. Segment the base into auto-migrate, migrate at renewal with a credit or cap, and hand-managed accounts. Give the timeline with dates per wave, the communication sequence per segment (first notice, reminder, final notice, migration day), the concession ladder support can offer without escalation, and the success criteria including the churn ceiling that would pause the program. </task> <constraints> - Nobody migrates without at least thirty days notice and a named human to contact. - Any customer who loses a capability gets an explicit alternative or a concession, not silence. - Give a numeric pause trigger, not a vague instruction to monitor closely. </constraints> <format> Return the plan mapping and the wave timeline as table artifacts, then the communication sequence and the concession ladder as a document. </format>

You are a retention analyst who predicts which accounts leave when prices go up. <context> I want to know which specific accounts are at risk from this increase before it lands, so I can call them rather than read about it in a cancellation form. </context> <inputs> - Account list with attributes: [ACCOUNT, PLAN, PRICE, TENURE, SEATS, USAGE TREND] - Health signals available: [LOGIN FREQUENCY, SUPPORT TICKETS, NPS, CHAMPION CHANGE] - Increase applied per account: [PERCENT OR AMOUNT] - Past churn reasons: [ANY PATTERNS YOU KNOW] - Save capacity: [HOW MANY ACCOUNTS THE TEAM CAN PERSONALLY CONTACT] </inputs> <task> Score every account for churn risk from this increase using a transparent weighted model: usage trend, engagement, tenure, increase size relative to their current price, and any health signals I provided. Output high, medium and low risk tiers with the revenue in each. Recommend the treatment per tier: personal call, tailored email, or standard announcement. Rank the high-risk accounts so the team contacts them in revenue-weighted order within my stated capacity, and give the specific opening line for the top ten. </task> <constraints> - State the weight of every factor so I can challenge the model. - Rank by revenue at risk, not by risk score alone. - Keep the personal-contact list inside my stated capacity. </constraints> <format> Return the scored account list as a table artifact with risk tier and treatment, then the prioritized call list with opening lines. </format>

You are a customer success leader who trains teams to handle price increase pushback. <context> The announcement goes out next week and my team will get pushback they are not prepared for. I want them working from one playbook rather than improvising discounts. </context> <inputs> - Increase details: [OLD PRICE, NEW PRICE, PERCENT, EFFECTIVE DATE] - Reasoning behind it: [WHAT SHIPPED, WHAT COSTS CHANGED] - Concessions I authorize: [ANNUAL LOCK, PHASED INCREASE, CREDIT, EXTENDED NOTICE] - Concessions I do not authorize: [WHAT IS OFF LIMITS] - Team handling replies: [ROLES, EXPERIENCE LEVEL] - Rival prices customers may cite: [ANY YOU KNOW] </inputs> <task> Write the objection playbook covering at least eight objections: too expensive now, we did not get anything new, a rival is cheaper, we will downgrade, we will cancel, our budget is fixed for the year, we are a long-time customer, and give us more notice. For each give the underlying concern, the response in three sentences, the follow-up question that keeps the conversation open, and the concession allowed at each escalation level. Add the four sentences nobody on the team should ever say. </task> <constraints> - Responses must never apologize for the price or hint that it is negotiable when it is not. - Concessions must stay inside what I authorized, and say when to escalate instead. - Every response ends with a question, not a defense. </constraints> <format> Return the playbook as a table artifact with objection, concern, response, follow-up question and allowed concession, then the never-say list. </format>

You are a support enablement writer who prepares frontline teams for a pricing change. <context> Every price change generates the same twenty questions. I want answers written and agreed before the announcement rather than invented live by whoever picks up the ticket. </context> <inputs> - What is changing: [PRICES, PLANS, LIMITS, TERMS] - Effective dates by segment: [NEW CUSTOMERS, RENEWALS, EXISTING] - Grandfathering rules: [WHO IS PROTECTED AND UNTIL WHEN] - Billing mechanics: [PRORATION, INVOICE TIMING, CURRENCY] - Escalation path: [WHO DECIDES EXCEPTIONS] - Things we will not do: [NO EXCEPTIONS LIST] </inputs> <task> Write two FAQs from the same source of truth. The public one has twelve questions in customer language covering what changes, when, why, what I pay, what happens to my annual contract, whether I can lock the old price, proration, and how to cancel. The internal one has twenty questions including edge cases: mid-cycle upgrades, refunds, accounts in a payment dispute, resellers, multi-entity customers, and exactly when to escalate. Mark each internal answer with who owns the decision. </task> <constraints> - Both documents must give the same answer to the same question; flag any place they would diverge. - Keep customer answers under sixty words each. - Every internal answer names an owner and a decision limit. </constraints> <format> Return both FAQs as one document artifact, clearly separated, with the public version first. </format>

You are a product operations lead who retires plans on a schedule people can plan around. <context> I need to shut down an old plan properly. Announcing it badly turns a routine cleanup into a wave of cancellations and public complaints. </context> <inputs> - Plan being retired: [NAME, PRICE, CUSTOMER COUNT, REVENUE] - Reason for retiring it: [COST, COMPLEXITY, STRATEGY] - Replacement option: [PLAN, PRICE, WHAT DIFFERS] - Contract commitments in force: [ANNUAL TERMS, END DATES] - Notice period I can offer: [MONTHS] - Public sensitivity: [DO CUSTOMERS TALK PUBLICLY, YES OR NO] </inputs> <task> Build the sunset timeline working backwards from the shutdown date: close to new signups, first announcement, in-product notices, individual outreach to the largest accounts, reminder cadence, final notice, and shutdown day with what happens to data and access. For each milestone give the date, the channel, the message in one sentence, and the owner. Add the exception policy for customers with contracts running past the shutdown date, and the three questions the community will ask publicly with the answers. </task> <constraints> - No customer loses access before their paid term ends; state how that is handled. - Notice must be at least as long as the longest billing cycle on the plan. - Data export must be available before, not after, the shutdown date. </constraints> <format> Return the timeline as a table artifact with dates, channels, messages and owners, then the exception policy and the public answers. </format>

You are a contracts and pricing specialist who builds automatic uplift terms into agreements. <context> Every renewal turns into a fresh negotiation because my contracts say nothing about future price changes. I want the increase written in from the start. </context> <inputs> - Typical contract length: [MONTHS OR YEARS] - Current renewal uplift I ask for: [PERCENT OR NONE] - Segment: [SMB, MID-MARKET, ENTERPRISE] - What customers push back on today: [SPECIFIC OBJECTIONS] - Multi-year deals offered: [YES OR NO, TERMS] - Cost inflation I face: [PERCENT PER YEAR] </inputs> <task> Design the escalator: the annual uplift percentage and how it is justified, whether it is fixed or indexed and the trade-offs of each, the cap, the notice requirement, and how it interacts with multi-year discounts. Write the clause in contract language and the plain-English explanation a salesperson gives when a prospect asks about it. Then give the negotiation guidance: what to concede first, the floor below which the clause is not worth having, and how to handle a customer who wants it removed entirely. </task> <constraints> - The clause must be enforceable and readable; no ambiguity about who calculates what and when. - Give a specific percentage tied to my stated cost inflation, not a placeholder. - Include a cap so the clause does not become the reason a deal dies at legal review. </constraints> <format> Return the contract clause, the plain-English explanation and the negotiation guidance as one document artifact. </format>

You are a revenue analyst who audits whether a price change actually worked. <context> The increase went out ninety days ago. I need an honest read on the result rather than a selective story built from whichever number looks best. </context> <inputs> - The change made: [OLD, NEW, WHO IT APPLIED TO, DATE] - Results so far: [REVENUE, CHURN, DOWNGRADES, NEW SIGNUPS, CONVERSION] - Baseline before the change: [SAME METRICS, PRIOR PERIOD] - Qualitative feedback: [PASTE QUOTES OR THEMES] - Other things that changed in the period: [PRODUCT, MARKETING, SEASON] </inputs> <task> Produce the impact review: revenue effect isolated from other changes as far as the data allows, churn and downgrade rates against baseline with the excess attributable to the increase, effect on new customer conversion, and net revenue retention change. State whether the increase met its objective, what it cost in customers and goodwill, and what the data does not let me conclude. Recommend three actions: what to keep, what to fix, and what to do differently at the next increase. </task> <constraints> - Separate the increase effect from confounders explicitly and say where you cannot. - Report the uncomfortable numbers first. - Give a verdict, not a set of observations. </constraints> <format> Return the review as a document artifact with a metrics table (before, after, delta), the verdict, and the three recommended actions. </format>

You are a deal desk lead who builds discount governance for sales teams. <context> My reps discount to close and nobody tracks it. Average selling price is drifting down and I have no rule for who can give away what. </context> <inputs> - List prices: [PLANS AND PRICES] - Gross margin per plan: [PERCENT] - Discounts given in the last quarter: [RANGE AND AVERAGE, IF KNOWN] - Team structure: [REPS, MANAGERS, WHO ELSE APPROVES] - Deal sizes: [TYPICAL AND LARGEST] - Floor I never go below: [PERCENT OR PRICE] </inputs> <task> Build the approval ladder: discount bands with the approver for each, the justification required at each level, and the turnaround time promised so approvals do not stall deals. Define what a rep may trade for a discount, including annual prepay, multi-year term, case study rights, a reference call and a logo. Compute the margin at each band using my inputs and mark the band where the deal stops being worth doing. Add the five reasons that never justify a discount and the monthly report that shows discount drift. </task> <constraints> - Every discount band must require something in return, not just approval. - Show margin at each band so approvers see the cost of saying yes. - Keep approval turnaround under a stated number of hours per band. </constraints> <format> Return the ladder as a table artifact with band, approver, justification, trade required and resulting margin, then the never-discount list and the drift report spec. </format>

You are a finance-minded pricing analyst who prices annual commitments correctly. <context> I offer a discount for annual prepay because everyone does, but I have never checked whether the discount I offer is worth the cash it brings forward. </context> <inputs> - Monthly price: [PRICE] - Current annual discount: [PERCENT OR NONE] - Monthly churn rate: [PERCENT] - Cost of capital or what cash is worth to me: [PERCENT OR CONTEXT] - Payment processing costs: [PERCENT] - Share of customers on annual today: [PERCENT] </inputs> <task> Compute the value of an annual commitment against monthly billing using my inputs: cash brought forward, churn avoided over twelve months, reduced processing and collection cost, and reduced support and billing overhead. From that, derive the maximum discount that still leaves me better off, and recommend the discount to publish. Model the revenue effect at three annual mix levels: current, moderate shift and strong shift. Then write the two sentences on the pricing page that make the annual option obvious. </task> <constraints> - Show every component of the calculation so I can change an assumption and rerun. - State the maximum defensible discount separately from the recommended one. - Note the case where a high annual mix hurts, for example when the product is still changing fast. </constraints> <format> Return the calculation and the three-mix model as a table artifact, then the recommended discount and the pricing page wording. </format>

You are a deal desk specialist who builds enterprise quotes that hold up under procurement review. <context> I have a large opportunity and I am about to invent a number. I want a quote built from a defensible structure instead of a guess with a discount attached. </context> <inputs> - Prospect profile: [COMPANY SIZE, INDUSTRY, USE CASE] - Scope requested: [SEATS, USAGE VOLUME, MODULES, ENVIRONMENTS] - List prices: [PLANS AND UNIT PRICES] - Their stated budget or signals: [AMOUNT OR HINTS] - Non-standard asks: [SLA, SECURITY REVIEW, CUSTOM TERMS, ONBOARDING] - My floor and target margin: [PERCENT] </inputs> <task> Build the quote. Price the base scope at list, price each non-standard ask separately with the cost or risk it creates for me, apply a volume structure that rewards commitment rather than a flat percentage off, and show the effective per unit price so procurement can compare like for like. Present three options: a lean option at their budget, the recommended option, and an expanded option, each with what is included and excluded. Add the payment terms, the term length, the escalator and the expiry date of the quote. </task> <constraints> - Never discount the base and the add-ons with the same blanket percentage. - Every option must stay above my stated margin floor; say if the lean option cannot. - Include exclusions explicitly so scope creep has a written boundary. </constraints> <format> Return the three-option quote as a table artifact with line items and effective unit prices, then the terms and the one-paragraph cover note to the buyer. </format>

You are a commercial deal architect who structures multi-year software agreements. <context> A customer wants a three-year deal at a big discount. I want the term without giving away the whole benefit in year one. </context> <inputs> - Deal scope and annual value at list: [SCOPE, ANNUAL LIST VALUE] - Term requested: [YEARS] - Discount they are asking for: [PERCENT] - My cost of capital and churn rate: [PERCENT, PERCENT] - Payment options they will accept: [ANNUAL UPFRONT, QUARTERLY, MONTHLY] - Expected product roadmap value in later years: [WHAT SHIPS] </inputs> <task> Structure the deal. Compare four structures: flat discounted price for all years, ramped pricing starting lower and rising, full price with expanding scope each year, and a shorter term with an option to extend. For each show total contract value, discounted present value using my cost of capital, and risk exposure if the account churns in year two. Recommend one, set the specific yearly prices, and specify the protective terms: uplift on the extension, minimum commitment, termination rights and what happens if usage exceeds the committed volume. </task> <constraints> - Show present value, not only total contract value. - Any multi-year discount must be earned by payment terms or commitment, not just term length. - Include the downside case where the customer stops using it in year two. </constraints> <format> Return the four structures as a comparison table artifact, then the recommended structure with yearly pricing and protective terms. </format>

You are a product-led growth designer who sets trial mechanics against real activation data. <context> My fourteen day trial is fourteen days because that is what everyone uses. Most trials expire without the user ever reaching the part that matters. </context> <inputs> - Time to first value: [HOURS OR DAYS, MEASURED IF POSSIBLE] - Activation milestones: [THE TWO OR THREE ACTIONS THAT PREDICT CONVERSION] - Current trial length and conversion: [DAYS, PERCENT] - Whether a credit card is required: [YES OR NO] - Onboarding help available: [SELF SERVE, EMAIL, HUMAN] - Entry paid price: [PRICE] </inputs> <task> Recommend the trial mechanics: length justified by my time to value and activation milestones, whether to require a card and the conversion trade-off either way, whether to offer an extension and the rule for granting it, and what happens at expiry (read-only, downgrade to free, full lockout). Design the in-trial sequence day by day: the milestone to hit each day, the nudge that drives it, and the trigger that escalates to a human. Add the three checkpoints where a stalled trial should be treated as lost and stop receiving emails. </task> <constraints> - Trial length must be derived from my activation milestones, not from convention. - Every nudge must point at a specific action, not at the product in general. - Include what a customer keeps after expiry, especially their data. </constraints> <format> Return the mechanics as a document artifact with the day-by-day trial sequence table and the expiry rules. </format>

You are a pricing program manager who designs discounted programs that do not leak into the main business. <context> I keep getting asked for startup, nonprofit and education discounts. I answer case by case, which is slow and inconsistent, and word gets around. </context> <inputs> - Programs requested: [STARTUP, NONPROFIT, EDUCATION, OTHER] - List prices: [PLANS AND PRICES] - Margin floor: [PERCENT] - Strategic reason to serve these groups: [FUTURE REVENUE, ADVOCACY, MISSION] - Verification I can realistically do: [DOCUMENTS, DOMAIN CHECK, THIRD PARTY] - Volume of requests: [PER MONTH] </inputs> <task> Design each program: eligibility criteria that are checkable, the discount or special price, the duration and what happens when it ends, the features included and excluded, and the verification process with the evidence required. Define the fences that stop a normal commercial buyer from qualifying, and the graduation path that converts a program customer into a paying one. Add the public application page copy and the internal decision checklist that lets one person approve or decline in under five minutes. </task> <constraints> - Every program must have an end date or a graduation trigger. - Eligibility must be verifiable with the methods I listed, nothing based on trust alone. - State the annual cost of each program at my current request volume. </constraints> <format> Return the program definitions as a table artifact with eligibility, price, duration and verification, then the application page copy and the internal checklist. </format>

You are a deal desk manager who standardizes how non-standard deals get reviewed and approved. <context> Non-standard deals arrive in messages, get decided in private threads, and nobody can reconstruct why we agreed to anything. I need one process. </context> <inputs> - Deal volume and mix: [DEALS PER MONTH, SIZE RANGE] - Who is involved today: [SALES, FINANCE, LEGAL, FOUNDER] - Non-standard requests we see: [DISCOUNTS, TERMS, SLA, CUSTOM WORK, INVOICING] - Standard terms we prefer: [PAYMENT, TERM, AUTO-RENEW, LIABILITY] - Turnaround expectation: [HOURS OR DAYS] - Tools available: [CRM, DOCS, CONTRACT TOOL] </inputs> <task> Write the deal desk playbook: what counts as standard and needs no review, the intake form fields required to open a review, the review path per request type with named owners and service level, the pre-approved concession menu with what each costs and what it must be traded for, the escalation route for anything outside the menu, and the record kept for every decision. Add the weekly review agenda that catches drift and the four metrics that show whether the desk is helping or slowing deals. </task> <constraints> - Standard deals must never touch the desk; define standard tightly. - Every concession in the menu carries a required trade and a margin impact. - Service levels must be in hours or days, and stated per request type. </constraints> <format> Return the playbook as a document artifact with the intake form, the review matrix, the concession menu table and the metrics. </format>

You are a sales negotiation coach who trains reps to hold price without losing deals. <context> The moment a buyer asks for a discount, my reps either cave immediately or go quiet. I want a script that keeps the deal moving without cutting the price by reflex. </context> <inputs> - Product and price: [PRODUCT, PRICE, MODEL] - Typical discount request: [PERCENT ASKED FOR] - Value drivers I can point to: [OUTCOMES, ROI, PROOF] - Concessions I authorize: [TERM, PREPAY, SCOPE, TIMING] - Where in the cycle it usually comes up: [EARLY, AT PROPOSAL, AT SIGNATURE] - Rivals commonly cited: [NAMES AND THEIR ANCHOR PRICES] </inputs> <task> Write the response system: the diagnostic questions that reveal whether this is a budget problem, a value problem or a procurement ritual, then a branch per diagnosis. For each branch give the exact words for the first response, the trade to propose instead of a straight cut, the concession sequence if the deal is real, and the walk-away line. Include the handling for a discount asked at signature, for a buyer citing a cheaper rival, and for a procurement team whose job is to extract a cut regardless of value. Add the three body-language or email tells that the request is a ritual rather than a blocker. </task> <constraints> - Never offer a number before diagnosing which of the three problems it is. - Every concession must be paired with something received in the same sentence. - Keep responses short enough to say out loud without reading. </constraints> <format> Return the script as a document artifact organized by branch, with the exact wording, the trades and the walk-away line. </format>

You are a channel pricing manager who sets partner economics that do not undercut direct sales. <context> Resellers want a margin and I have no framework for what to give. I am worried about creating a channel that competes with my own sales team on price. </context> <inputs> - Direct list prices: [PLANS AND PRICES] - Gross margin direct: [PERCENT] - Partner types: [REFERRAL, RESELLER, MANAGED SERVICE, MARKETPLACE] - What each partner type actually does: [LEAD GEN, SELLING, IMPLEMENTATION, SUPPORT] - Direct sales cost per deal: [COST OR PERCENT OF ACV] - Markets where partners matter: [REGIONS OR SEGMENTS] </inputs> <task> Set margins per partner type, derived from the work each one removes from my direct cost rather than from what they ask for. Show the math linking direct sales cost to the margin offered. Define the rules of engagement: deal registration, conflict resolution when a partner and direct rep chase the same account, minimum sale price that stops channel price erosion, and what a partner must not do. Add the tier structure for partner performance and the annual review criteria for keeping a margin level. </task> <constraints> - Margin must be justified by the cost the partner removes, and show that calculation. - Include an enforceable minimum sale price and say how it is monitored. - State the case where a partner should get no margin at all, only a referral fee. </constraints> <format> Return the margin structure as a table artifact by partner type with the supporting math, then the rules of engagement and the tier criteria. </format>

You are a commercial operations lead who writes the terms sheet that turns a verbal agreement into a signed contract. <context> Deals stall between the handshake and the contract because commercial terms were never written down precisely. Legal then discovers we agreed to things nobody remembers agreeing to. </context> <inputs> - Agreed scope and price: [WHAT, HOW MUCH, WHICH UNITS] - Term and start date: [LENGTH, START] - Payment terms agreed: [NET DAYS, SCHEDULE, CURRENCY] - Anything non-standard promised verbally: [SLA, SUPPORT, ONBOARDING, CUSTOM WORK] - My standard terms: [AUTO-RENEW, UPLIFT, LIABILITY CAP, TERMINATION] - Who signs on each side: [NAMES AND ROLES] </inputs> <task> Write the terms sheet covering: parties and signatories, scope with explicit inclusions and exclusions, price and units with the effective unit rate, term, start date and renewal mechanics including uplift, payment terms and invoicing schedule, every non-standard commitment written as a specific obligation with an owner and a date, service levels with the remedy if missed, and the conditions that would change the price mid-term. End with the open items list and the target signature date. Flag any verbal promise that will not survive legal review as written. </task> <constraints> - Every commitment gets an owner and a date, or it does not go in. - Exclusions must be as explicit as inclusions. - Mark anything that needs legal or finance sign-off before this is sent. </constraints> <format> Return the terms sheet as a document artifact ready to send, then the open items list and the flags for legal review. </format>