business-case-and-proposal

---
name: business-case-and-proposal
description: Builds enterprise business cases, ROI and TCO models, executive summaries, proposals, pricing and negotiation positions, RFP/RFI and security-questionnaire responses, and QBR/EBR decks for customers. Use it whenever the user needs to "justify the investment", "build the ROI", write or review a proposal, SOW summary or exec summary, answer an RFP, prepare a renewal or expansion case, prepare a QBR, or get ready for pricing or procurement negotiations.
---

# Business Case & Proposal

Enterprise buyers approve spend they can defend to their CFO. A business case wins when the buyer believes the numbers because they recognize the inputs as their own. A proposal wins when the economic buyer can read the first page and say yes.

## 1. Business case and ROI

### Inputs: label every one
Each number in the model is one of:
- **Customer-provided:** who gave it and when. This is the strongest kind.
- **Customer-confirmed estimate:** we proposed it and they agreed.
- **Public benchmark:** publisher, report, year and URL. Use it only if it is recent and actually applicable.
- **Our assumption:** stated explicitly, conservative, and listed for the buyer to validate.

Never borrow another customer's results as inputs without permission. Even with permission, show them as a reference point, not as this buyer's expected outcome. Never invent benchmarks.

### Structure
1. **Current state, in the buyer's numbers.** Volumes, cycle times, cost per unit, error and rework rates, people involved, external spend (agencies, contractors, tools).
2. **Value drivers.** Pick the 2–4 that matter to this economic buyer; don't list every possible benefit.
   - **Revenue:** faster time to market, conversion, coverage across new SKUs, markets or channels, fewer lost sales from poor content.
   - **Cost:** hours saved × loaded cost (ask whether savings are redeployed or removed, and say which), agency or vendor spend avoided, tool consolidation.
   - **Risk:** compliance errors avoided, brand consistency, audit readiness.
   - **Strategic:** capacity to take on initiatives they've stated.
3. **Investment / TCO.** Subscription, implementation, services, internal effort (people × time), change management, and ongoing administration. Hiding internal effort destroys credibility with finance.
4. **Scenarios.** Show three, each with explicit assumptions:
   - **Conservative:** lower adoption, slower ramp, partial benefit. **It must still be positive.** If it isn't, change the scope or the price, or tell the truth that the case is marginal.
   - **Expected.**
   - **Upside.**
5. **Outputs.** Net benefit, ROI, payback period, NPV if their finance team uses it, and cost of inaction (what the current state costs over 1–3 years).
6. **Sensitivity.** Name the 1–2 assumptions that drive most of the value, and show what happens if they're wrong.

**Speak the buyer's P&L:**
- **CPG:** place value on their growth tree: distribution × velocity × price/mix + innovation. Trade savings land in net revenue, via gross-to-net. Name the contribution-margin layer you're claiming (see `retailer-jbp-and-line-review/references/commercial-math.md`).
- **Banks:** efficiency ratio, cost-to-serve, backlog hours.
- **Health systems:** operating margin, labor and contract-labor cost, denials, throughput.

**Defend any outcome or lift claim against the buyer's analysts.** Healthcare and CPG analysts will probe it. Cover:
- the baseline method
- a matched comparison group where possible
- regression to the mean and selection bias addressed
- netting out post-period dips
- cost avoidance labeled separately from cash savings
- "contributed to" attribution, with shares across programs that never add up to more than 100%

Show the formulas. A finance reviewer must be able to trace every number. Round sensibly; false precision ("$1,284,331") reads as invented.

### Language
- "Projected", "estimated", "based on your inputs". Never "will save" or "guaranteed".
- Customer references read as "Customer X achieved…", with permission, never "you will achieve".

## 2. Executive summary (one page; the most-read page)

Five short paragraphs, roughly 250–350 words, no jargon:
1. **Their situation and goal**, in their own words.
2. **The problem and its cost**, quantified with their numbers.
3. **The proposed approach**, framed as outcomes, not features.
4. **Expected impact** (the conservative scenario, with the expected one alongside) and how it will be measured.
5. **Why now and the decision requested.** A real reason tied to their timeline (never fake urgency), and the specific next step with a date.

## 3. Proposal structure

```
1. Executive summary
2. Our understanding — objectives, challenges (include 2–3 real challenges; a proposal that says everything is easy isn't believed), success criteria
3. Proposed solution — mapped to their requirements/criteria, in their language
4. Implementation plan — phases, milestones, roles (theirs + ours), timeline
5. Success measurement — KPIs, baseline, review cadence
6. Business case summary — link to the model
7. Commercials — pricing, terms, options (genuine options, not decoys), validity date
8. Scope — inclusions, explicit exclusions (at least 3), assumptions, customer responsibilities
9. Why us — approved proof only; relevant references (with permission)
10. Mutual action plan — remaining steps to signature and kickoff, owners, dates
11. Appendix — security/compliance (approved wording), team, detailed specs
```

**Rules:**
- **Mirror their language** from discovery.
- **Keep the main body short.** Detail goes in appendices. Executives skim, so use clear headings and tables.
- **Mark it confidential** and give it a validity date.
- **Read it from the reviewer's chair.** Someone who wasn't on the calls should understand it.
- **Present pricing options honestly.** Options should be real alternatives that suit different needs. Don't use decoy tiers or anchoring tricks; enterprise procurement sees through them, and it costs trust.

## 4. RFP / RFI and security questionnaires

- **Bid / no-bid first.** Do we have a relationship? Did we shape the requirements? Can we meet the mandatory requirements? Is the deal size worth the effort? If a competitor wrote the requirements and we've never spoken to the buyer, say so.
- **Compliance matrix.** List every requirement with: meets / partially meets / roadmap / does not meet, plus the evidence. Answer exactly what is asked, in the order and format asked.
- **Answer from approved sources only.**
  - Content library: product facts, security documentation, legal boilerplate.
  - "Partially" and "does not meet" are honest answers. Overclaiming in an RFP becomes a contractual problem later.
  - Roadmap answers need approval and must carry no committed dates unless those are approved.
- **Win themes.** 3–4 themes tied to the buyer's stated priorities, repeated consistently throughout the response.
- **Security questionnaires.** Every answer traces to approved security documentation. Flag anything unanswerable for the security team; never improvise. Keep wording consistent with previous answers to the same buyer.
- **Final checks.** Customer name correct throughout (no leftovers from a reused answer), page and word limits met, required forms signed.

## 5. Negotiation preparation

Prepare this before any pricing or procurement conversation. It is internal only.
- **Positions:** opening, target, and walk-away, each with its justification.
- **Concessions:** an ordered list, each paired with what we ask in return.
- **The buyer's likely asks** and our planned responses.
- **Signature authority and approval chain on both sides.**
- **Non-price levers:** term, scope, phasing, payment terms, services, success criteria, references.

**Give/get rules:**
- Never discount without getting something in return. For example:
  - a longer term or larger commitment
  - an earlier signature tied to the buyer's own timeline, not fake urgency
  - a public case study or reference (subject to their approval process)
  - reduced scope
  - payment terms
- Keep internal approval thresholds and floors out of anything customer-facing.
- No fake deadlines, invented "other customers asking for this slot", or manufactured scarcity.

For handling the objections that come up in negotiation, see `competitive-and-objections`.

## 6. QBR / EBR (existing customers)

The purpose is to prove value, realign on goals, and earn the right to expand. It is not a usage report.

```
1. Executive summary — value delivered vs. agreed success criteria (on track / at risk / missed)
2. Outcomes in their metrics — with baseline and evidence; attribution stated honestly ("contributed to" where it's shared)
3. Wins (top 3) — what happened, why, how to repeat it
4. Misses — root cause (theirs / ours / external) + corrective action. Never hide them; customers know.
5. Their priorities for the next period — confirm, don't assume
6. Recommendations (3–5) — each with impact, effort, owner; expansion only where it serves their goals
7. Mutual action items — owner (theirs/ours), date, success measure
Appendix — detailed data
```

**Internal prep:** account health (see `enterprise-deal-strategy/references/account-plan-template.md`), renewal risk, stakeholder changes, and expansion hypotheses. None of this goes in the customer deck.

## Before it goes out

Run the business case, proposal, RFP and QBR deck through `customer-facing-quality-gate` at the **External – high sensitivity** tier. Those documents get forwarded to finance, legal and procurement, and parts of them may end up in contracts.

From writer/skills at 20837c9, shown as plain text under its license: CC0-1.0 (permissive). The license text is in LICENSE.

• SKILL.md9.7 KB · b7ca7b8db445

1 file, 9.7 KB in total. Each file has a sha256 in the pin's manifest; the first 12 characters are shown.