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 is the teal sparkle inside any business case. 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
Show a range instead of one number	Scenarios
Understand a calculation well enough to defend it	Calculations and use cases
Turn their export into a number I can defend	Files and trend analysis
Show when value arrives, not just how much	Timelines
Lay something out as a table	Tables
Back a claim with a case study	Case studies and proof
Stop the case sounding like our brochure	Rename to personalize
Say the same thing to a CFO and a VP Ops	Reframe for personas
Walk into a call knowing where it gets hard	Call prep
Price the deal and handle a discount ask	Investment and pricing
Send something my champion can forward	Deal page agent
Make waiting expensive	Cost of inaction
Renew on evidence rather than relationship	Renewal, expansion, churn save

How to prompt either agent

Lead with the outcome, not the feature

“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.

Say where your numbers came from

“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.

Chain the steps you would have clicked

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.”

Ask for the resulting number

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

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

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

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

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

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

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

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.”

Conservative / Expected / Best
Status quo vs. competitor
Scope ladder
Realized vs. projected
Walk/Crawl/Run

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

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

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

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

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

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

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

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

Which of my future scenarios most closely matches what they actually signed?
Copy from that one, not from Best Case.

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

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

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

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

Are any two use cases counting the same saved hours or the same revenue?

So the number passes a laugh test against their size

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

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 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

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

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

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

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

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

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

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

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

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 can do the analysis and write the result in. So your input is grounded in their data, not a default

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

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

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

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

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

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

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

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

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

Add a note to March saying "their fiscal year-end, no deployments".

So one slow use case does not drag the rest down

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

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

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

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

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

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

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

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

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

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

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

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

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 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

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

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

Apply renames 1, 2, and 4. Leave 3, their term for that is too vague.

So the inputs read like their reporting

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

Rename the calculation inside "Cut Invoice Approval Time" to "Annual AP Processing
Cost".

So pricing does not trigger a conversation about your packaging

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

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.

CFO
COO or VP Ops
IT or security
The champion's internal case
Situational

So the person who signs sees size, confidence, and who validated it

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

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

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

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

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

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

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

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

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.

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

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

Hide the investment tab for now. I want to walk them through the benefit first.

So a concession is priced before you offer it

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

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

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

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

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

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

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

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

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

Is anything in this business case currently visible to external users that I would
not want them to see before this meeting?

So your champion can edit and defend it

Export this to Google Slides.

So you know what to check before you send

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

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

Which of these rest on a single offhand comment rather than something they raised more
than once?

So the last call is reflected

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

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

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

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.

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

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

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

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

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

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

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

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

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

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

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

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

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

Renewal pitch: renew on evidence, not relationship

So you open with the number instead of the anecdote

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

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

The ask is too soft. Rewrite the close as a named commitment: which teams, how many
seats, starting when.

Upsell and expansion: let proven value carry the next deal

So one team’s result becomes the case for three more

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

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

Based on realized value by use case, where is the strongest expansion case, and where
would I be overreaching?

Churn save: name the gap before they do

So you keep the account by getting ahead of the bad news

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

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

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.

Deal handoff and retro: stop the next cycle starting from zero

So the CSM inherits the truth, not just the total

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

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

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

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

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

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

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.

Start here

Create assets for customers

Run the value conversation

Codify value selling in your organization

For your buyer

Agents

Agent Recipes

Which agent

Find your prompt

How to prompt either agent

The business case agent

Build the case

Scenarios and the shapes worth building

Stress-test before they do

Calculations and use cases

Files and trend analysis

Timelines: create and update

When reality moves

Tables

Case studies and proof points

Rename to personalize

Reframe for personas

Investment and pricing

Call prep

The deal page agent

Do this first: correct the signals

Early in the deal

Value hypothesis

Discovery summary

Account POV

Late in the deal

Cost of inaction

Renewal, expansion, and churn save

Make any draft defensible

Keep the two in sync

Key takeaways

​Which agent

​Find your prompt

​How to prompt either agent

​The business case agent

​Build the case

​Scenarios and the shapes worth building

​Stress-test before they do

​Calculations and use cases

​Files and trend analysis

​Timelines: create and update

​When reality moves

​Tables

​Case studies and proof points

​Rename to personalize

​Reframe for personas

​Investment and pricing

​Call prep

​Export and share

​The deal page agent

​Do this first: correct the signals

​Early in the deal

​Value hypothesis

​Discovery summary

​Account POV

​Late in the deal

​One-pager

​Cost of inaction

​Renewal, expansion, and churn save

​Make any draft defensible

​Keep the two in sync

​Key takeaways

Which agent

Find your prompt

How to prompt either agent

The business case agent

Build the case

Scenarios and the shapes worth building

Stress-test before they do

Calculations and use cases

Files and trend analysis

Timelines: create and update

When reality moves

Tables

Case studies and proof points

Rename to personalize

Reframe for personas

Investment and pricing

Call prep

Export and share

The deal page agent

Do this first: correct the signals

Early in the deal

Value hypothesis

Discovery summary

Account POV

Late in the deal

One-pager

Cost of inaction

Renewal, expansion, and churn save

Make any draft defensible

Keep the two in sync

Key takeaways