> ## Documentation Index > Fetch the complete documentation index at: https://docs.minoa.io/llms.txt > Use this file to discover all available pages before exploring further. # Agent Recipes > What to ask the business case agent and the deal page agent, indexed by what you need out of it Two agents do most of the work in Minoa, and most people use one of them for one thing. The **business case agent** builds, edits, and explains the model. The **deal page agent** turns that model into the documents that reach people who will never open it. Learn what to ask each one and a task that used to be twenty clicks becomes a sentence.

Below are examples of prompts that you can copy-paste into the Minoa agent to help you build a value story and business case. Background on the two surfaces: [AI Value Engineer](/pages/business-case/ai-value-engineer) is the teal sparkle inside any business case. [Work Your Deal from the Deal Page](/pages/recipes/work-your-deal-from-the-deal-page) covers the Docs tab where documents get generated. ## Which agent | Agent | Where | Ask it for | | :---------------------- | :---------------------------------- | :-------------------------------------------------------------------------------------------------------------- | | **Business case agent** | Teal sparkle inside a business case | Scenarios, use cases, inputs, investment, timelines, calculations, the overview, exports | | **Deal page agent** | Docs tab on any deal | Value hypothesis, discovery summary, one-pager, cost of inaction, renewal pitch, expansion, churn save, handoff | They feed each other. The business case is the model. The deal page docs are how it travels. A one-pager is only as good as the case behind it, and a case nobody circulates does not move a deal. ## Find your prompt | I need to | Jump to | | :------------------------------------------------ | :------------------------------------------------------------------ | | Get a first case built from what we already know | [Build the case](#build-the-case) | | Show a range instead of one number | [Scenarios](#scenarios-and-the-shapes-worth-building) | | Understand a calculation well enough to defend it | [Calculations and use cases](#calculations-and-use-cases) | | Turn their export into a number I can defend | [Files and trend analysis](#files-and-trend-analysis) | | Show when value arrives, not just how much | [Timelines](#timelines-create-and-update) | | Lay something out as a table | [Tables](#tables) | | Back a claim with a case study | [Case studies and proof](#case-studies-and-proof-points) | | Stop the case sounding like our brochure | [Rename to personalize](#rename-to-personalize) | | Say the same thing to a CFO and a VP Ops | [Reframe for personas](#reframe-for-personas) | | Walk into a call knowing where it gets hard | [Call prep](#call-prep) | | Price the deal and handle a discount ask | [Investment and pricing](#investment-and-pricing) | | Send something my champion can forward | [Deal page agent](#the-deal-page-agent) | | Make waiting expensive | [Cost of inaction](#cost-of-inaction) | | Renew on evidence rather than relationship | [Renewal, expansion, churn save](#renewal-expansion-and-churn-save) | ## How to prompt either agent "Make this more compelling" gets you a rewrite. "My champion has to defend the invoice number to their CFO, so show me where it came from and what is weak about it" gets you a decision. "Their VP Ops said 14 minutes per ticket on the March 3 call." That value becomes traceable instead of plausible, and the agent records it rather than treating it as an assumption. One message carries a sequence. "Create a best case scenario, raise adoption to 85%, add a 3-month onboarding phase at 30% ramp, then show payback for both." Every edit ends in a number. Ask for it. A wrong magnitude is obvious in the result and invisible in a list of edits. The business case agent proposes, you approve. Every action surfaces an approval card before anything changes. Read the card, especially on inputs and investment. Approving a batch without looking is how a decimal point reaches a buyer. *** # The business case agent ## Build the case **So you get a draft grounded in what the customer actually said** ```text theme={null} Summarize the deal context, then tell me which use cases you would put in this business case and why. Cite what each one is based on. ``` **So you are not carrying a use case you cannot defend** ```text theme={null} For each use case in here, what is it based on, and how confident are you? What inputs do I still need to validate with my customer. Drop any that rest on a single throwaway line. ``` **So you know what's happening when updates and changes are made** ```text theme={null} Walk me through the changes that you made and how I can best walk my customer through this Business Case ``` **So the case covers a problem the customer raised and we missed** ```text theme={null} They spent ten minutes on duplicate data entry between systems. Is there a use case in our library for that? Add it if so. ``` **So you know what still needs a real number** ```text theme={null} List every input in this case, its value, and whether it came from the customer, a document, public research, or an assumption. ``` **So you fill in the gaps in the right order** ```text theme={null} Which of my remaining assumptions move the total benefit most? I want to fix those first. ``` **So you can continue to build the value story** ```text theme={null} Look at the attach files/transcripts. Update existing use cases and suggest additional use cases. Add any relevant value positioning. ``` Correct the assumptions first, verify anything from public web research second, and leave values that came from a call alone unless you know better. Those came from the customer. ## Scenarios and the shapes worth building A single case says "here is the number." Scenarios say "here is the range, and here is what has to be true for each." The default, and it works because buyers pick the middle. The middle only reads as credible if the outer two are real positions rather than padding. **So the buyer chooses between options instead of deciding whether to proceed** ```text theme={null} Create three scenarios: Conservative, Expected, and Best Case. In Conservative, drop adoption to 50% and assume only the first team goes live. In Best Case, assume full rollout at 90%. Keep the investment identical in all three. Show me benefit, ROI, and payback for each. ``` **So your conservative case is genuinely conservative** ```text theme={null} Is my Conservative scenario actually conservative? Compare every input against the Expected case and flag anything optimistic. ``` Name the middle one after what the deal actually is: "Phase 1 Rollout", "EMEA Only", "Agreed Scope". A scenario called "Expected" invites debate about expectations. One called "Phase 1 Rollout" invites debate about phase 1, which is the conversation you want. For a bake-off where the buyer is comparing line items instead of outcomes. **So doing nothing stops looking free** ```text theme={null} Create a scenario called "Status Quo" where the benefit is zero but the cost of the current state is still modeled: keep the current-state inputs, remove the projected improvement. Then create "Competitor A" at 60% of our improvement rate with a lower one-time fee. Leave my case as is. ``` **So a cheaper competitor stops looking cheaper** ```text theme={null} Compare Competitor A to my case on total cost over the full contract, not just fees. Where does the gap actually sit? ``` For land-and-expand, where the question is not whether but how much. **So a discount conversation becomes a scope conversation** ```text theme={null} Create three scenarios by scope: "One Team", "One Region", "Global". Scale the volume inputs to 40, 200, and 900 users. Adjust the recurring fee proportionally. Show ROI for each. ``` **So you recommend the right scope, not the biggest** ```text theme={null} At which scope does ROI stop improving? That is the one I should recommend. ``` If ROI improves with scope, the buyer's cheapest move is to buy more, and the chart says so without you saying it. Post-sale. One Value Realization Scenario per business case, alongside the projections it was sold on. **So the renewal runs on evidence** ```text theme={null} Create a value realization scenario based on my "Phase 1 Rollout" scenario. Set the contract start to July 2025 with a 12-month duration. Then show me realized value to date against the estimated curve. ``` **So you compare against the right promise** ```text theme={null} Which of my future scenarios most closely matches what they actually signed? Copy from that one, not from Best Case. ``` Ask the agent to create aWalk, Crawl, Run Scenario and ask how you can best walk your customer through the three different scenarios. ## Stress-test before they do The highest-value section on this page, and the one almost nobody runs. **So the hardest question gets asked somewhere private** ```text theme={null} Act as the CFO reviewing this case for the first time. Which three numbers would you challenge, and what would you ask me to prove? ``` **So you know which number the whole case rests on** ```text theme={null} Which input has the biggest effect on total benefit? If I cut it by 30%, what happens to ROI and payback? ``` **So the case does not collapse if one use case gets dismissed** ```text theme={null} Show me each use case as a percentage of total benefit. Is this case load-bearing on one of them? ``` **So you are not claiming the same saving twice** ```text theme={null} Are any two use cases counting the same saved hours or the same revenue? ``` **So the number passes a laugh test against their size** ```text theme={null} Sanity-check the total benefit against the headcount and revenue in the deal context. Does this hold up for a company this size? ``` **So you can explain what differs between your options** ```text theme={null} What differs between my Conservative and Expected scenarios? List every changed input and the value in each. ``` If one use case carries more than half the benefit and its key input is an assumption, you do not have a business case yet. You have a bet. Get that number from the customer, through a [survey](/pages/business-case/customer-survey) if you have to. ## Calculations and use cases Business cases fail in a specific way. The number is right, the logic is sound, and the rep cannot explain it. A buyer asks "where does the 340 come from?" and the answer is a pause. **So you know the shape of what you are presenting** ```text theme={null} Walk me through this business case from the top. Total benefit, what each use case contributes as a percentage, and where the investment sits against it. ``` **So you can explain one use case without hedging** ```text theme={null} Explain the "Reduce Manual Invoice Processing" calculation as if you were explaining it to their VP of Finance. What is it measuring, what does it multiply by what, and what is the result? ``` **So you have a sentence you would actually say out loud** ```text theme={null} Give me one sentence per use case that explains the value in the customer's terms, with the number in it. No jargon. ``` **So you know the objection before it arrives** ```text theme={null} Is this a cost reduction, revenue uplift, or custom calculation? What is the strongest objection to this shape of argument, and how do I answer it? ``` **So an operator can accept your number without accepting your dollar conversion** ```text theme={null} Which of these could I present as a non-monetary outcome instead? Show me the hours or error-count version alongside the dollar version. ``` **So a benchmark change does not leave this deal behind** ```text theme={null} Is the loaded hourly cost here linked to our global input, or a local value someone typed? What is the difference between them? ``` **So the case stops claiming something you cannot defend** ```text theme={null} The projected cost is too low. We claim we automate the review step entirely and we do not. Assume analysts still spot-check 15% of invoices, then show me the new number. ``` **So a real number replaces a default** ```text theme={null} The 12-minute default does not fit them. Their team said 22 minutes on the March 3 call. Update it and record that the customer gave us that value. ``` If a calculation is wrong because the logic does not fit this kind of customer rather than because of a value you entered, patching it in one business case leaves every other deal wrong. Report it to whoever owns your value framework. Card explanations are regenerated from the calculation icon in the use case toolbar. Have the agent write the wording first: "Draft me a better explanation for the invoice automation card, in the customer's language, with the source of the key assumption in it." ## Files and trend analysis The most valuable thing a customer gives you is a file. It usually gets skimmed, quoted once, and forgotten, because turning it into an input is tedious. Load context first. Attach every relevant call, add the files with the paperclip, and use the prompt field to steer ("focus on the operations team, not IT"). **So nothing you just added gets left on the floor** ```text theme={null} What did you learn from the files and calls I just added that is not yet reflected in this business case? ``` For a file the agent needs to read line by line, your own assistant connected over [MCP](/pages/integrations/mcp) can do the analysis and write the result in. **So your input is grounded in their data, not a default** ```text theme={null} Here is their ticket volume export for the last 12 months. Work out the monthly average, the trend line, and whether volume is growing. Then tell me what average monthly volume I should use in the Acme case, and why. ``` **So a growing problem is priced as a growing problem** ```text theme={null} Volume is up 18% year over year. Should I model the current run rate or the projected one? Show me the benefit both ways. ``` **So you scope the case where it is strongest** ```text theme={null} This spreadsheet has handle times by team. Which teams are outliers, and would our case be stronger scoped to those teams than across the whole org? ``` **So you know which number to trust when sources disagree** ```text theme={null} Compare what this export says to the value they gave us on the discovery call. If they differ, which is more defensible and what should I ask them? ``` **So the number carries its source into the case** ```text theme={null} Update the monthly ticket volume input to 14,200 and record that it came from their Q1 to Q4 support export. ``` **So realized value has a shape instead of a total** ```text theme={null} Here is the monthly actuals export, January through August. Switch the "tickets handled per month" input in the value realization scenario to monthly tracking and record each month's value. ``` There is no file upload over MCP. Your own assistant can read a local file and write values into Minoa, but it cannot hand Minoa the file. To keep the file with the deal, upload it to Deal Context or attach a shareable link. ## Timelines: create and update A case without a timeline claims full value from day one. Every buyer who has run an implementation knows that is not how it works. **So the case shows when value arrives, not just how much** ```text theme={null} Add a timeline. Contract starts January 2026, runs 24 months. Place all use cases. "Pre-Sales Business Case Automation" starts month 1. "Post-Sales Renewal Pitch" starts month 4, since it needs the first renewals to come round. Everything else month 2 to the end. ``` **So the benefit reflects real adoption instead of instant adoption** ```text theme={null} Add three phases: "Initial Rollout" months 1 to 2 at 25% ramp, "Expanded Rollout" months 3 to 4 at 80%, rest at 100%. Then tell me what that does to total benefit and payback. ``` **So the timeline is theirs and they cannot argue with it** ```text theme={null} On the kickoff call they said: pilot with the UK ops team in Q1, EMEA in Q2, North America in H2, finance module last because of their year-end freeze. Build the timeline and phases to match, and add month notes explaining each phase. ``` **So a flat month reads as planning rather than a problem** ```text theme={null} Add a note to March saying "their fiscal year-end, no deployments". ``` **So one slow use case does not drag the rest down** ```text theme={null} Ramp the invoice automation use case at 25% month 1, 50% month 2, 80% month 3, full value from month 4. Leave the others at 100%. ``` ### When reality moves This is the part that matters most and gets done least. A timeline still showing the original plan is worse than no timeline, because it is visibly wrong. **So payback is honest about the new signature date** ```text theme={null} Signature slipped to March. Move the contract start to March 2026 and shift every use case and phase forward two months, keeping durations. Show me the new payback. ``` **So you know what a delay costs before anyone asks** ```text theme={null} The EMEA rollout is a quarter behind. Push that phase and everything in it back three months, keep North America where it is, add a note explaining the delay. What does that cost us in year-one benefit? ``` **So you revise the number before the customer discovers it** ```text theme={null} Adoption in the pilot is running around 45%, not the 70% we modeled. Reduce the ramp for months 1 through 6 to match, and give me the revised benefit for the year. ``` **So new scope shows up as new value** ```text theme={null} They are adding the finance team in Q3. Add the two finance use cases starting September 2026, run to end of contract, new phase called "Finance Expansion". Show me the delta. ``` **So you know what you can still claim after a cut** ```text theme={null} They dropped the Americas rollout. Remove those use cases from the timeline and tell me what the case is worth now, and whether it still clears the ROI bar we quoted. ``` Once a timeline is active, a use case with no date range contributes zero benefit. If your total drops to zero, that is why. And hiding the timeline tab does not revert your calculations: to go back to full-contract math you have to clear the date ranges. ## Tables Three places a table does real work, and the agent can produce all three. **So the buyer can check your arithmetic instead of trusting it** ```text theme={null} Rewrite the overview so the arithmetic is visible: a table of input, value, source, and contribution for each use case. ``` **So a comparison reads at a glance** ```text theme={null} Put the three scenarios in a table on the overview: scenario, total benefit, ROI, payback, and the one assumption that differs. ``` **So a multi-year deal is legible** ```text theme={null} Add a table showing benefit, investment, and net benefit by contract year. ``` Showing the arithmetic is a confidence move and it works. Buyers who can check your math stop auditing your motives. Buyers who cannot check it assume the worst about the parts they cannot see. The scenarios tab gives you a side-by-side comparison view for free, and the ramping modal is itself a spreadsheet grid. Reach for a written table when you need it inside something you are sending. ## Case studies and proof points A number you assert is a claim. A number with a case study, an export, or a survey response behind it is evidence. **So a claim has something behind it** ```text theme={null} Attach this link as a resource and name it "Northwind - AP automation case study, 2025". ``` **So the input traces back to the file it came from** ```text theme={null} Attach their FY25 support volume export as a resource called "Acme - FY25 support volume, source for ticket inputs". ``` **So you add the proof that would actually move this buyer** ```text theme={null} Which use cases here would be strongest with a customer proof point, and what kind of proof would move this specific buyer? ``` **So the case study earns its place in the narrative** ```text theme={null} Work the Northwind result into the overview: one sentence, named, with the number, positioned right before our projection for them. ``` Resources attach by shareable URL. Check the link works outside your company before you send the case, and confirm you are allowed to name the customer. When you do not have a number, ask for one. Group the open inputs into a [customer survey](/pages/business-case/customer-survey) and send the link. A response with their name attached beats a plausible estimate. ## Rename to personalize Your framework is written in your company's language because it has to be. But a use case called "Workflow Automation Module" is one your champion cannot repeat. Renaming into their language is the highest ratio of impact to effort in the product. Renaming inside a business case does not touch your value framework, so be as specific to this customer as you like. **So you use their vocabulary instead of guessing at it** ```text theme={null} Based on the calls and context on this deal, what words does this customer use for their own processes, teams, and problems? List the phrases they repeat. ``` **So you see the renames before they happen** ```text theme={null} Using those phrases, propose new names and descriptions for every use case in this case. Show me before and after. Do not change anything yet. ``` **So only the renames that hold up get applied** ```text theme={null} Apply renames 1, 2, and 4. Leave 3, their term for that is too vague. ``` **So the inputs read like their reporting** ```text theme={null} Rename the inputs to match how they talk about volume. "# of Invoices" should be "Monthly AP Volume", which is what their controller called it. ``` **So a finance reader recognizes the line item** ```text theme={null} Rename the calculation inside "Cut Invoice Approval Time" to "Annual AP Processing Cost". ``` **So pricing does not trigger a conversation about your packaging** ```text theme={null} Rename the recurring fee from "Platform Subscription Tier 3" to "Annual Platform Fee", and the one-time fee to "Implementation and Enablement". ``` **So the timeline matches the program they already named** ```text theme={null} Rename the timeline phases to their program names: "Wave 1 - UK", "Wave 2 - EMEA", "Wave 3 - Americas". ``` Name for the outcome, not the feature. "Cut Invoice Approval Time in Half" lands with a VP Finance. "AP Automation Module" does not. If your champion cannot say the name out loud in their own internal meeting, it is the wrong name. ## Reframe for personas Same case, same numbers, completely different arguments. The mistake is presenting the CFO version to the COO and wondering why it did not land. **So the person who signs sees size, confidence, and who validated it** ```text theme={null} Rewrite the overview for their CFO. Lead with the cost of the status quo, then net benefit, ROI, and payback. Reference the sources behind the two largest inputs. No product language at all. ``` **So the risk question is answered before it is asked** ```text theme={null} Add a short paragraph on what would have to go wrong for this not to pay back, and what we are doing about each. ``` **So the operator sees relief rather than ROI** ```text theme={null} Rewrite the overview for their VP of Operations. Lead with the operational outcome: hours returned, backlog cleared, error rate. Dollar figures secondary. Reference the rollout timeline. ``` **So the ask on their team is visible and small** ```text theme={null} Add what this asks of their team during rollout, honestly. They will assume it is more than it is unless we say. ``` **So the likeliest veto has nothing to veto** ```text theme={null} Rewrite the overview for their IT director. Lead with what we integrate with, what data we touch, and what implementation asks of their team. Frame value as reduced maintenance burden, not revenue. ``` **So your champion has the document they were going to write anyway** ```text theme={null} Write the version my champion would send internally with no seller present. Their voice, not ours. What they are recommending, what it costs, what the return is, and what happens if the company does nothing. ``` **So a build-versus-buy comparison includes the cost of building** ```text theme={null} They are comparing us to building it internally. Reframe the overview around what building would cost them: engineering time, maintenance, time to first value. ``` **So the case connects to the mandate they are under** ```text theme={null} They are under board pressure to show AI adoption this year. Reframe the summary so the outcome ties to that mandate without overclaiming what we do. ``` **So a local team can read it in their own language** ```text theme={null} Switch this business case to German for their local finance team. ``` Language switching serves your framework's existing translations. Untranslated text shows up highlighted, which is your cue that a use case needs a German version. See [Internationalization](/pages/value-framework/internationalization). Reframing changes emphasis. It must not change claims. Run this before you send: "Check that overview against the actual calculations. Does it claim anything the math does not support?" ## Investment and pricing **So the numbers reflect how you actually sell** ```text theme={null} Add a recurring fee of 120,000 per year for the full contract with a 5% annual increase, plus a one-time implementation fee of 45,000. ``` **So the benefit side lands before the price does** ```text theme={null} Hide the investment tab for now. I want to walk them through the benefit first. ``` **So a concession is priced before you offer it** ```text theme={null} If I drop the annual fee 15%, what does that do to ROI and payback? Is there a scope reduction that would be better for both of us? ``` **So a multi-year structure is legible** ```text theme={null} Model this as a three-year deal with the fee stepping up as they add regions, and show net benefit by year. ``` ## Call prep Ten minutes, three questions, in this order. **So you know what you are actually presenting** ```text theme={null} Summarize this business case as if I have never seen it. Total benefit, ROI, payback, the use cases included, and what it is currently claiming. ``` **So you find the soft spot before they do** ```text theme={null} Which numbers here can I not source to something the customer said or a document we have? List them by how much they move the total. ``` **So the call has an agenda instead of being a status update** ```text theme={null} Based on those gaps, give me the five questions I should ask on this call to close them. Phrase them the way I would say them out loud. ``` Then, depending on the meeting: **So a discovery call has a number they can react to** ```text theme={null} What are the two or three most likely pain points based on the context, and roughly what is each worth? Give me a number I can put down and invite them to correct. ``` **So you find out whether the case survives without you** ```text theme={null} Write me a two-sentence framing for each use case that my champion could repeat to their CFO with me not in the room. ``` **So you do not get ambushed by your own case** ```text theme={null} Act as this CFO. Ask me the five hardest questions about this business case, one at a time, and tell me whether my answer would hold. ``` **So a QBR leads with evidence rather than adoption charts** ```text theme={null} Compare realized value against the estimated curve. Which use cases are ahead, which are behind, and by how much? ``` **So nothing the buyer should not see is visible** ```text theme={null} Is anything in this business case currently visible to external users that I would not want them to see before this meeting? ``` ## Export and share **So your champion can edit and defend it** ```text theme={null} Export this to Google Slides. ``` **So you know what to check before you send** ```text theme={null} Which slides in this export would I want to edit before sending? Tell me what is weak about them. ``` Check your browser is not blocking popups. That is far and away the most common reason an export appears to fail. Copy the deck to your own drive before editing. *** # The deal page agent The business case is the model. Deal page docs are how the model reaches an executive sponsor who is never going to open it and inspect your calculations. Pick a template on the Docs tab and the agent drafts it from your deal context. Everything it produces is editable, and your edits teach it how you write. ## Do this first: correct the signals Deal intelligence sits between your calls and every document generated from them. Five minutes correcting signals improves every draft afterwards. Skip it and you will fix the same wrong emphasis in four documents. **So you know what the agent thinks this deal is about** ```text theme={null} Show me the priorities and challenges you have extracted for this deal, with the quote behind each. Which are you least confident about? ``` **So you know which signals to dismiss** ```text theme={null} Which of these rest on a single offhand comment rather than something they raised more than once? ``` **So the last call is reflected** ```text theme={null} I just added Tuesday's call. Re-analyze and tell me which signals changed and which are new. ``` Editing and dismissing happens on the Deal intelligence tab. A dismissed signal is a correction the agent carries forward, not just a hidden row. ## Early in the deal ### Value hypothesis The qualitative story, before any numbers. It becomes the first tab of the business case, so getting it right pays twice, and it is the one document that also exports to slides. **So you open on their problem rather than your product** ```text theme={null} Regenerate the value hypothesis around the three things they actually said were broken, in their words. No feature names, no capability lists. ``` **So it lands with whoever is in the room** ```text theme={null} Tailor this for a CRO audience. Revenue impact and sales efficiency, in the language a revenue operations leader uses. ``` **So you know whether you have earned this conversation** ```text theme={null} What is this assuming about their business that we have not confirmed? List it so I know what to ask next. ``` Full walkthrough: [Create a Value Hypothesis](/pages/recipes/create-value-hypothesis). ### Discovery summary What the buyer told you, in their own words, attributed. It converts a conversation into a shared record. **So a same-day follow-up does real work** ```text theme={null} Draft the discovery summary from today's call. Attribute each point to who said it. One page. I am sending it within the hour. ``` **So you get a number confirmed without asking for a favour** ```text theme={null} Include a short section listing the figures they gave us with the values, framed as "here is what we captured, correct anything that is off." ``` **So you see the gaps in your own discovery** ```text theme={null} Based on this summary, what did I fail to ask about? Give me the five questions that would have made this stronger. ``` That middle one is the highest-leverage move on this page. A buyer correcting your numbers is a buyer validating your numbers, and it costs them thirty seconds. ### Account POV Internal. A hypothesis about what is driving the account, built before you have talked to anyone. **So you have something to be wrong about, which beats having nothing** ```text theme={null} Generate the account POV. I want a specific claim about what is driving their cost base right now, not a summary of their website. ``` **So research becomes an opening line** ```text theme={null} From this POV, give me the one sentence I should open the call with, and the number I should put next to it and invite them to correct. ``` ## Late in the deal ### One-pager The document that actually travels. A sponsor-ready summary with a link back to the full model for whoever gets asked to check it. **So the case reaches people you will never meet** ```text theme={null} Draft the one-pager from the current business case. My champion is sending it to their CFO and their COO, so it has to work for both. ``` **So you know where it falls apart without you there** ```text theme={null} Which claim in this one-pager is my champion least equipped to defend on their own? Rewrite that part so they can. ``` **So what is circulating does not go stale** ```text theme={null} The business case changed since I generated this. Regenerate it and tell me what is different, so I know whether to resend. ``` Send the one-pager and the business case link together. The executive reads the page, their analyst opens the model. Supplying both saves a round trip and signals you are not hiding the arithmetic. ### Cost of inaction What every quarter of delay costs. The right document when the deal is not lost, just not urgent, which is how most deals die. **So "next quarter" gets a number attached** ```text theme={null} Draft the cost of inaction from the business case. Per quarter and per month, so a delay has a price in the meeting. ``` **So the delay is concrete rather than theoretical** ```text theme={null} Frame it against their fiscal year. If they sign in November versus February, what is the difference in realized value by their year-end? ``` **So it addresses the real objection** ```text theme={null} Their stated reason for waiting is budget timing. Draft this so it speaks to that specifically, not a generic urgency argument. ``` Cost of inaction only works if the underlying benefit is credible. Run it after you have stress-tested the case. An inflated delay cost is the easiest claim in the deal to dismiss. ## Renewal, expansion, and churn save **So you open with the number instead of the anecdote** ```text theme={null} Draft the renewal pitch from realized value in this case. Total benefit against total spend, then the one ask I am making. ``` **So you start 90 days out rather than three weeks** ```text theme={null} We are 90 days from renewal. Based on realized value so far, is this pitch strong enough to send? If not, what do I need before it is? ``` **So the ask is specific enough to act on** ```text theme={null} The ask is too soft. Rewrite the close as a named commitment: which teams, how many seats, starting when. ``` **So one team's result becomes the case for three more** ```text theme={null} Draft the expansion doc. Lead with what the UK team actually realized, then model the same unit economics for EMEA and North America. Label the projection as forward-looking. ``` **So the proof is not diluted by the projection** ```text theme={null} Is the realized number carrying the headline, or have I mixed a projection into it? Separate them. ``` **So you propose the expansion the data supports** ```text theme={null} Based on realized value by use case, where is the strongest expansion case, and where would I be overreaching? ``` **So you keep the account by getting ahead of the bad news** ```text theme={null} Draft the churn save. Open with what is at risk and the shortfall against what we promised, then what did land, then a named cause, then a plan with owners and dates. ``` **So no part of it blames the customer** ```text theme={null} Read this back as their VP would. Does any part imply the shortfall is their fault for not adopting properly? Fix it if so. ``` **So the recovery plan is checkable** ```text theme={null} Every action needs an owner and a date. Fill in what you can from our milestones and flag what I have to supply. ``` A customer who watches you open with the bad news, unprompted, tends to conclude the good news was probably true as well. See [Prove Value to Existing Customers](/pages/recipes/prove-value-to-existing-customers). **So the CSM inherits the truth, not just the total** ```text theme={null} Draft the deal handoff: what we promised, which inputs the customer validated and which we assumed, the timeline they agreed to, and the two numbers most likely to be challenged at renewal. ``` **So the landmines are flagged rather than buried** ```text theme={null} Add a section on what I would be worried about if I were taking this account over. Be blunt, this is internal. ``` **So a loss teaches you something** ```text theme={null} Draft the retro. At which point was this winnable, what did we get wrong about their priorities, and what would I do differently on the next account like this? ``` Do the handoff in the week the deal closes, while you still remember which numbers were soft. ## Make any draft defensible **So a skeptical reader can trace every claim** ```text theme={null} Add references to this document. ``` That runs a second pass annotating each claim with citations back to the calls and notes behind it. Hover a reference and you get who said it, when, and the quote. **So nothing internal reaches a buyer** ```text theme={null} Read this back as their procurement lead. What would you challenge, and is anything in here reading as internal rather than customer-facing? ``` Documents lock while the references pass runs, so edit first and add references after. And check which section you are in before sharing: Internal Documents carry hedged guesses and stakeholder read-outs not written for a buyer. ## Keep the two in sync Documents are generated from a snapshot. When the case changes, they do not follow on their own. **So an old number is not circulating while you present a new one** ```text theme={null} List the documents on this deal and tell me which quote figures from the business case. Those are the ones I need to regenerate. ``` **So the story is the same everywhere** ```text theme={null} Compare the one-pager, the value hypothesis, and the business case overview. Do they claim the same things in the same order, or has the story drifted? ``` You have a model you can defend line by line, and documents that say the same thing, in the customer's language, traceable back to what they actually told you. ## Key takeaways * **Lead with the outcome.** The agent acts on "so my champion can defend this", not on "make it better". * **Source every number.** "The customer told us" ends an argument. "The system defaulted it" starts one. * **Ask the agent to attack your case.** It finds the load-bearing assumption faster than you will. * **Correct the deal intelligence signals first.** Every document downstream reads from them. * **The one-pager travels, the business case backs it up.** Send both. * **Regenerate when the case changes.** A stale document you already sent is worse than one you never wrote.