Case Study 1 — The Executive Summary That Buried the Ask

A note on accuracy. This is a composite, fictional-but-realistic scenario built to illustrate one structural principle. The company, the people, and the numbers are invented; nothing here is drawn from a real organization's documents.

The situation

Priya Menon, a senior operations analyst at a mid-sized insurance firm, had spent six weeks building the case to replace the company's aging claims-intake system. She was right on the merits: the old system was slow, error-prone, and propped up by manual workarounds that cost the team hundreds of hours a month. She wrote a thorough twelve-page proposal and, on top of it, an executive summary for the leadership committee that would approve the spend.

The committee met for ninety minutes and had eleven items on the agenda. Priya's proposal got six minutes. The members read her executive summary, exchanged a few puzzled looks, and tabled it: "Let's circle back when we understand the scope better." Priya was baffled—everything they needed was in the document. The problem was not the document. It was that the one part they actually read, the executive summary, never told them what she wanted or why it was obvious.

Here is what she wrote.

The "before" — the ask is buried

❌ Before (the recommendation arrives last, hedged into invisibility):

Over the past several years, our organization has experienced steady growth in policy volume, and with that growth has come a corresponding increase in the number of claims our team processes on a monthly basis. The claims-intake system currently in use was originally deployed in 2014 and, while it has served the organization reliably for many years, it was designed for a transaction volume considerably lower than what we now handle. As a result, members of the claims team, along with colleagues in IT and operations, have over time identified a range of pain points, including slower processing speeds, an increase in manual data re-entry, and occasional data-integrity issues that require correction downstream. In light of these challenges, and after a careful evaluation process spanning two quarters that involved consultations with several vendors, reference checks, and a structured scoring of options against criteria such as cost, integration capability, scalability, and vendor stability, our team has reached the conclusion that the adoption of the ClaimStream platform would likely address a significant proportion of the issues described above. We therefore recommend that the committee give consideration to moving forward with the procurement of ClaimStream, which carries an annual cost of approximately $140,000.

That is 210 words, and a committee member who reads it learns what Priya wants only in the final sentence—and even there, the ask is "give consideration to moving forward," which is not an ask at all. Read the way a busy committee reads it, the summary is four sentences of things they already know (the company grew; the old system is old; people have complaints) followed by a buried, hedged recommendation with no number that matters attached to it.

Against the chapter's principles, the failures are exact:

• The ask is buried (§20.4). The recommendation is the last sentence, behind 180 words of context.
• Hedging guts it (§20.8). "Would likely address a significant proportion," "give consideration to moving forward"—every verb is softened until nothing is actually being requested.
• No decision-grade numbers. The only figure is the cost ($140,000). There is no ROI, no payback, no cost of inaction—nothing that makes the spend look worth it.
• No next step. There is no specific action, owner, or deadline. The committee literally cannot tell what saying "yes" would commit them to.
• It does not stand alone. To understand the scope, the value, or the timeline, the reader must open the twelve-page body—so the summary failed its one job (§20.4).

No wonder it was tabled. The summary gave the committee no reason to act and no clear action to take.

The "after" — lead with the ask

Now rebuild it for how the committee actually reads—recommendation first, justified by numbers, with a dated next step:

✅ After (the ask leads; the case is self-contained):

Recommendation: approve the purchase of ClaimStream to replace our 2014 claims-intake system, at $140,000/year.

Our current system can't keep up with claim volume. Manual re-entry and error correction consume about 600 staff-hours a month—roughly $310,000 a year in labor—and data errors delay an estimated 8% of claims, hurting customer satisfaction scores. In a two-quarter evaluation, ClaimStream eliminated the manual re-entry step and cut intake errors by 90%. It pays for itself in about 9 months through recovered staff capacity (the equivalent of four full-time hires we won't need to add as volume grows), and the cost of doing nothing—continued labor waste plus the rising risk as volume climbs—exceeds the cost of switching within the first year.

We need the committee's approval by April 30 to begin a phased rollout before the Q3 volume peak. Full evaluation, options comparison, timeline, and budget detail follow in the attached proposal.

Why it's better: The recommendation is now the headline, before any context. The justification is concrete—600 hours, $310,000, 90% fewer errors, a 9-month payback, four hires avoided—where the "before" offered only adjectives. The cost of inaction is named, reframing the $140,000 as the cheaper path. The hedging is gone: "approve the purchase" replaces "give consideration to moving forward." And there is a real next step with a date and a reason for the date ("by April 30 … before the Q3 volume peak"). A committee member who reads only this can approve it—which is the whole point. The body still exists, but it no longer stands between the reader and the decision.

The lesson

Priya's idea never changed; only the structure of the half-page that carried it did. The "before" treated the executive summary as an introduction—a ramp into the real document. The "after" treats it as the chapter's threshold concept demands: the executive summary is the document, the only part most deciders will read, so it must contain the entire decision. The test that separates the two versions is the one to run on every summary you write: could the reader approve this from the summary alone? For the "before," the answer was no, and it was tabled. For the "after," the answer is yes—and a yes is what a proposal exists to earn.

Related: Chapter 20 §20.4 · Case Study 2 · Exercises