The big play: orchestrate a renewal or strategic account, end to end

Your team already has the renewal-campaign and strategic-account-plan playbooks — the worked recipes for running a renewal and a key account, step by step. This module is the layer above the recipe. It’s where you learn to orchestrate a big play: not to write one, but to run one — a single high-stakes account moment where everything you’ve built comes together, on a clock, with real money and a real relationship on the line, and nothing slips.

It’s Module 4 of the certifiable Sales track, and it’s the module that pulls the others together. By now you’ve built the parts. The foundation (Module 1) decided what you sell on, who you sell to, and how you handle the pushback. The outreach engine (Module 2) turned that into researched, on-narrative outreach that fills the calendar. The deal mechanics (Module 3) carried a live deal from discovery to close. The big play is where all three come together on one account — a renewal-and-expansion, or a strategic key account — run as one planned campaign, in two languages, with every sign-off secured before the offer ships instead of chased at the eleventh hour.

A big play — a flagship renewal, a strategic account — is the day everything you know about a customer gets tested at once: the history, the value, the relationship, the objections you’ll face. And the thing that slips it is almost never the pitch. It’s an unsecured sign-off, a commercial line nobody owned, an Arabic offer that went out a day late as a translation. Orchestration is the discipline that fixes that: a runbook with a name and a date on every line, so the renewal call is execution, not an eleventh-hour scramble.

The runbook is the product

The instinct on a big account is to treat the value story as the deliverable and the schedule as an afterthought — a calendar reminder, an email thread, somebody’s memory of what was promised. That’s backwards. On a renewal or a strategic account, the runbook is the product. It’s the one artifact that holds the whole play: every step, the human who owns it, the date it’s due, and the gate it has to clear first. The brief, the value story, the offer, the call — those are inputs to the runbook, not the thing itself.

• Claude builds the first runbook from the goal and the account history. You don’t start from a blank grid. Give Claude the goal (renew Al Hosn Trading and add two branches), the renewal date, and the account history it already has — the notes, the usage data, the original terms — and ask it to lay out the runbook: every step as a row, with columns for owner, date, and gate. In minutes you have a complete structure to react to instead of a blank page to fill — which is the difference between catching an unsecured approval a week out and discovering it the morning of the call.
• A person owns each line — Claude doesn’t. The runbook’s whole job is to make ownership undeniable. Every row names a human, not a team and not “TBD.” Tell Claude to leave the owner column for you to assign: a play where Claude invents the owners is a play nobody actually owns. The blank owner cell is the single most useful thing a runbook surfaces — it’s the gate that becomes the eleventh-hour scramble, made visible a week early.
• One play, not a scatter. The runbook aims everything at a single planned moment — the renewal call — in a deliberate sequence (the brief, then price and terms, then the offer, then the call), not a drift of whenever-it’s-ready touches spread across a month. The sequence is a decision (secure the gates, then build the offer, then take the call), and the runbook is where you make that decision once instead of improvising it live.

The approval gate is a named step, not a vibe

Here’s what every account veteran knows and every rookie learns the hard way: on a renewal, what slips it is almost never the pitch. It’s an unsecured sign-off. The discount that “was approved.” The contract change nobody owned. The expansion ask that reached the buyer before deal-desk had priced it. The value story was ready days ago; the renewal slipped because an approval lived in someone’s head instead of on the runbook.

• Every gate is a row, with an owner and a deadline. Deal-desk (price), legal (terms), and the Arabic sign-off aren’t a vibe you’ll “loop in” later — they’re named steps on the runbook, each with a human and a date that falls before the offer it gates. The deadline is the entire point: a sign-off without a date is a sign-off that happens after the thing it was supposed to approve.
• The expansion ask and any non-standard discount clear before they reach the buyer — specifically. A renewal makes a commercial ask, and the price and the terms are exactly what a deal-desk and a legal reviewer exist to own. Any number past list, any non-standard discount, any contract change (for a multi-branch expansion, the per-branch terms) gets a deal-desk and a legal gate of its own, traceable to the pricing in your foundation. Confident-and-wrong on terms is expensive on a routine deal; on a flagship renewal it’s a credibility hit at the exact moment the relationship is being re-decided.
• The bilingual sign-off is a person who actually reads the Arabic. The most common gate failure in this region is the second language skipping review because nobody on the approval chain reads it — the Arabic offer ships because the English cleared. Put an Arabic sign-off on the runbook, owned by someone who genuinely reads and judges Arabic commercial copy, not someone approving a shape they can’t read.

The operating guide is where the org-level version of these gates lives — the standing data, deal-desk, and sign-off rules that sit underneath every play, so each one inherits the policy instead of re-litigating it.

The account map and the multi-thread value story

The account map is the play’s insurance policy, and the whole trick is that it’s built before the call, while you’re calm — not live, with the renewal on the line and a buyer waiting. The ad-hoc version of a renewal is mapping the stakeholders and rehearsing the objections the morning of. The orchestrated version is having the map, the per-stakeholder value story, and the pre-handled objections drafted, gated, and ready days earlier, so the call itself is execution.

• Map the stakeholders and the whitespace. Who decides, who champions, who could block — and where Mizan isn’t yet: the two branches still on spreadsheets, the seats not bought, the FTA auto-filing they haven’t turned on. A single-threaded account is a fragile account; the map’s most valuable output is the single point of failure it surfaces (a renewal resting on one champion who could move teams) and the whitespace nobody had named. Claude builds both maps from the account history; you sanity-check the relationship reads against what the team actually knows.
• A value story per stakeholder, tied to the proof. Different buyers buy on different value. The owner needs the trust-and-penalty math; the bookkeeper who lives in the tool needs the hours saved and the second system removed. Each version leans on the same proof — Al Hosn’s own VAT returns accepted by the FTA without amendment — re-pointed for the person hearing it. The play gives every buyer the version that moves them, not one generic pitch; Claude builds the per-thread case from the one narrative, and you decide which proof lands for whom.
• The objections, pre-handled calm and early. Draft the honest answer to each way the renewal can go sideways — the price increase, the “we barely used it,” a competitor sniffing around — now, with an approver named on each. Under pressure you’ll reach for the line you already wrote; the orchestration is making sure that line exists and is pre-cleared (the price line clears deal-desk before it’s ever said), so an objection on the call is a reframe, not a scramble.

One play, two languages, coordinated

For a MENA account, “bilingual” is not a translation step bolted to the end of the runbook. It’s one offer that lands the same instant in both languages, each native to its own. The failure you’re designing against is the English offer going out and the Arabic trailing a day later as an obvious translation — which tells an Arabic-first buyer, at the exact moment they’re re-deciding the relationship, that they were the afterthought.

• Both languages, one moment. The Arabic and English offers sit on the same runbook, aimed at the same send. Neither is the original; neither is the echo. The runbook is what makes simultaneity a plan instead of a hope — the Arabic offer has its own row and its own time, right next to its English twin.
• Authored, not translated — inheriting the Arabic foundation. The Arabic offer is built from your Arabic value story (the value-narrative-ar.md you wrote in Module 1), adapted for the Gulf buyer — the proof, the lead objection, even which pillar leads can differ. Run the English offer through translation and you get copy that’s technically correct and emotionally foreign; author it and you get an offer that reads native.
• The same gate, in both languages. Both offers clear deal-desk and legal — and the Arabic clears an Arabic reader. One play, two native expressions, both signed off. On a renewal, where the relationship is the whole deal, that isn’t a nicety; it’s the credibility line.

Your assignment

Build a complete plan for one account — your own (recommended: the output is a real play your team keeps) or the sample account Al Hosn Trading, an existing customer of the GCC bookkeeping tool Mizan used throughout this track. Open the folder with the account history, your foundation docs, and the original deal terms in Claude Desktop, approve each read in the “Ask permissions” prompt, and work in the chat — no terminal needed. The runbook and the value story are files you create and edit in the file pane.

Module 4 deliverable — the big play

Pick one real play. (Sample: Al Hosn Trading — a Sharjah trading business and
existing Mizan customer whose VAT return the FTA accepted without amendment, now
up for RENEWAL and a 2-branch EXPANSION — exactly where orchestration earns its
keep.)

Inherit everything upstream. The play does NOT re-invent the message — it runs
it:
  - value-narrative.md + battlecards.md (+ value-narrative-ar.md) from M1
  - the outreach engine from M2, the deal mechanics from M3

1. renewal-runbook.md  (or account-plan.md — one table that owns the play)
   - every step × its owner × its date × the gate it must clear
   - every approval gate as its OWN row — deal-desk (price), legal (terms),
     the Arabic sign-off — each with an owner and a deadline BEFORE what it gates
   - the hard dependencies marked (deal-desk prices the expansion before the
     offer is built; the Arabic sign-off before the Arabic offer sends)

2. value-story.md + the risk map  (built before the call, not during it)
   - the stakeholder + whitespace map (every single point of failure flagged)
   - a value story per stakeholder, each tied to the trust proof
   - the renewal objections pre-handled — price increase, "we barely used it,"
     a competitor sniffing — each with an approver named

3. The approval gates, made explicit — not a vibe
   - who signs price (deal-desk), who signs terms (legal)
   - who reads and signs the ARABIC (someone who actually reads it)

Bilingual teams: the Arabic offer is authored — not translated — and lands the
SAME moment as the English. Both languages, one runbook, one send.

The What you keep section below gives you a fill-in template for the runbook and the value story, plus the prompts that build them — so you start from structure, not a blank grid.

How it’s graded — the rubric

This is the part the free playbook doesn’t have, and the part that makes the credential mean something. Your plan is scored against five criteria. Each is meets / nearly / not yet — and a “nearly” on any one is a revise, not a pass.

Big-play rubric — five criteria, each meets / nearly / not yet.
A "nearly" on any one is a revise, not a pass.

1. Every line is owned       Every step and gate names a human and a date. A
                             blank in the owner or date column is the gap that
                             becomes the eleventh-hour scramble — caught a week
                             early here, not live on the renewal call.
2. The gates are explicit    Deal-desk (price), legal (terms), and the Arabic
                             sign-off are their own rows with deadlines, before
                             what they gate. The expansion ask and any non-
                             standard discount show a named sign-off, not an
                             assumed one.
3. One coordinated play      Every step aims at a single planned moment — the
                             renewal call — in a deliberate sequence, not a
                             scatter of whenever-it's-ready touches.
4. The message is inherited  Every claim traces to the value narrative and its
                             proof. The play runs the message; it doesn't invent
                             a louder claim for the renewal.
5. Bilingual + simultaneous  The Arabic offer is authored (not translated),
                             lands the same moment as the English, and is signed
                             off by someone who actually reads it. (Bilingual
                             teams.)

The discipline is deliberately what an account lead would demand: a flagship renewal fails expensively and in front of the customer, so the gaps that a routine deal can absorb quietly — an unowned line, an unsecured sign-off, an Arabic offer a day late — have to be caught here, on the runbook, before the call.

The bar, shown — a worked model answer (Mizan)

You don’t have to guess what “meets” looks like. Here’s a passing excerpt for the sample account — Al Hosn Trading’s renewal plus a two-branch expansion. Your own doesn’t need to look like this; it needs to clear the same bar.

renewal-runbook.md — Mizan: Al Hosn Trading renewal + 2-branch expansion (excerpt)

Step                           Owner            Date       Gate
Renewal brief + risk map       You              May 10     —
Deal-desk: price the expansion [deal-desk]      May 14     ← this IS the gate
Legal: multi-branch terms      [legal]          May 16     ← gates the offer
Arabic offer — read & sign     [Arabic reader]  May 18     ← gates the AR send
Value story + stakeholder map  You              May 18     deal-desk ✓
Renewal offer — EN             You              May 20     deal-desk · legal ✓
Renewal offer — AR             [name]           May 20     deal-desk · legal · AR-read ✓
Renewal call                   You              May 22     offer sent ✓

Dependency: deal-desk prices the expansion (May 14) BEFORE the offer is built.
Dependency: legal clears the multi-branch terms (May 16) BEFORE either offer ships.
Dependency: Arabic sign-off (May 18) BEFORE the Arabic offer sends.

Every line has an owner and a date; the gates — deal-desk (price), legal (terms), Arabic-read — are their own rows with deadlines that fall before the offer they clear; and the Arabic offer sits on the same May 20 send as its English twin, not a day behind. The bracketed roles are where a named human goes — that blank is the point: an unfilled owner cell is the gap, surfaced a week early instead of live. Now the value story it’s all built around:

value-story.md — Mizan: Al Hosn Trading (excerpt)

What they got (the shared result — proof on their own account)
  Two VAT returns filed this year, both accepted by the FTA without amendment.
  Every figure traces to its source — the books a bank or auditor takes without
  a redo. This is "trustworthy, not just fast," proven on Al Hosn's own account.

For the owner (economic buyer)
  The ask is two more branches on one trustworthy system — not two more sets of
  books to worry about. Cost of doing nothing: a late VAT return is an
  AED 1,000+ penalty per return, and that risk multiplies with every branch
  left on spreadsheets.

For the bookkeeper (champion, daily user)
  The two new branches close in the same place as the first three — no second
  tool, no re-keying. Turn on FTA auto-filing and the last manual step (pressing
  submit) goes away too.

The expansion, plainly
  Growth (AED 249/mo) → Multi-branch (AED 499/mo) + 2 branches at AED 79 each
  = AED 657/mo, billed annually with 2 months free (AED 6,570/year). Anything
  past list goes to deal-desk before it reaches Al Hosn.

holding line — "the renewal price went up"

"It did — you're moving from Growth to Multi-branch so the two new branches run
on the same trustworthy books as the first three. Set against one late-VAT
penalty (AED 1,000+ per return, per branch) or an accountant's data-entry hours
(~AED 1,500/mo), the renewal replaces a cost you're already carrying — it
doesn't add one. If the number is a blocker, I'd rather talk options than lose
the trust."

[Any number past list clears deal-desk before this goes to Al Hosn.]

renewal-offer-ar.md — Mizan: Al Hosn Trading (note)

The Arabic offer is authored, not translated, and sits on the SAME May 20 row
as the English — not a day behind. It leads with the trust proof in local terms:
Al Hosn's own VAT returns were accepted by the FTA without amendment. Register is
lightly formal MSA with Gulf-natural phrasing; numbers Western. It clears the
same gates — deal-desk (price), legal (terms) — plus an Arabic reader who signs
the Arabic before it sends.

Notice what the value story does and doesn’t do: it makes the case on the proof from the foundation (Al Hosn’s own FTA-accepted returns; figures trace to source), re-anchors the price on the cost of doing nothing rather than arguing it down, talks to each stakeholder in the value they buy on, and keeps the commercial ask inside the deal-desk gate. The holding line is honest, re-frames the increase as a cost already carried, and names its approver — written now, while calm, not live on the call.

What you keep — toolkit additions

These extend the Foundation toolkit you already installed. Save them in the folder your team works in; every renewal and key account from now on starts from structure, not a blank grid. Replace the Mizan / Al Hosn placeholders with your own.

The renewal-runbook.md (or account-plan.md) template

# renewal-runbook.md — [Account]: renewal + [expansion]

Goal:         [the one outcome — e.g. renew + add 2 branches — one sentence]
Renewal date: [the hard date everything aims at]
Languages:    [EN / AR — the offer lands the same moment in both]

## The runbook (every line has an owner and a date)
Step                       Owner          Date         Gate
[renewal brief + risk map] [name]         [date]       —
[deal-desk: price]         [deal-desk]    [date]       ← this IS a gate
[legal: terms]             [legal]        [date]       ← this IS a gate
[Arabic offer — read]      [AR reader]    [date]       ← gates the AR send
[value story + map]        [name]         [date]       deal-desk
[renewal offer — EN]       [name]         [date]       deal-desk / legal
[renewal offer — AR]       [name]         [date]       deal-desk / legal / AR-read
[renewal call]             [name]         [date]       offer sent

## Approval gates (each is its own row above, repeated here with a deadline)
- Deal-desk (price):  [owner] — by [date, BEFORE the offer is built]; covers
                      [the expansion price / any non-standard discount]
- Legal (terms):      [owner] — by [date]; covers [the multi-branch terms]
- Arabic sign-off:    [owner who actually reads Arabic] — by [date]

## Dependencies (what blocks what)
- [deal-desk prices the expansion] BEFORE [the offer is built]
- [legal clears the terms] BEFORE [either offer ships]
- [Arabic sign-off] BEFORE [the Arabic offer sends]

The value-story.md template (per stakeholder)

# value-story.md — [Account]

## What they got (the shared result — proof on their own account)
[the concrete results so far, with real numbers; tie to the trust proof]

## Per-stakeholder case (the version that moves each one)
- [Champion / daily user]: [what they need to believe] · proof: [the point that lands]
- [Economic buyer]:        [what they need to believe] · proof: [the point that lands]
- [Blocker]:               [what they need to believe] · proof: [the point that lands]

## The whitespace (where we're NOT yet — the expansion)
[extra branches · more seats · capabilities not turned on, e.g. FTA auto-filing]
[flag every single point of failure — a relationship the renewal rests on alone]

## The expansion, plainly (real numbers)
[current plan/price] → [proposed plan/price] = [total]; [annual terms].
Anything past list goes to deal-desk before it reaches [Account].

Saved prompts (Big play)

Build the runbook from the goal
  "We're renewing [account] on [renewal date] and proposing [the expansion], in
   [EN and AR]. Read the account brief, the value story, and value-narrative.md
   in this folder. Build a renewal-runbook table: every step, its owner, its
   date, and which approval gate it must clear first. Add deal-desk (price),
   legal (terms), and the Arabic sign-off as their OWN rows, with deadlines
   BEFORE what they gate. List the hard dependencies. Leave the owner column for
   me to fill — don't invent names."

Map the stakeholders and the whitespace
  "Read the account notes, threads, CRM export, and usage data. Build a
   stakeholder map (each person, their role — champion / economic buyer /
   blocker — what they care about, and how strong our relationship is) and a
   whitespace map (which branches, seats, and capabilities have us vs. don't,
   ranked by opportunity). Flag every single point of failure — a renewal
   resting on one relationship. Don't draft any outreach yet."

Red-team the renewal as a skeptical deal-desk
  "Read renewal-runbook.md and the value story as a skeptical deal-desk. Find
   every line with a blank owner or date, every offer that ships before its
   price or terms gate clears, every claim that isn't backed by the proof, and
   every place the Arabic trails the English instead of landing the same moment.
   List the gaps in priority order — the ones that stall the renewal first."

On the Terminal & Automation track these prompts become one-keystroke slash commands; on Desktop you paste them in the chat with the right files open, and they do the rest.

What you’ve proven — and what’s next

Clear this rubric and you’ve proven the part of sales that never shows up in any single email or call: not running a deal, but orchestrating an account — a flagship renewal or strategic key account where the foundation, the engine, and the deal mechanics come together at once, in two languages, with every deal-desk, legal, and Arabic sign-off secured before the offer ships instead of chased on the day. That’s the big-play stage of “Certified Sales with Claude” — the module that proves you can hold the whole thing at scale, which is exactly the skill a team buys the certificate to vouch for.

One module remains before the capstone, and it’s the one that makes the next play better than this one:

• Module 5 — measure & forecast: close the loop. Read what the play actually did — won, expanded, slipped — separate signal from noise in the pipeline, and feed the lesson back into the foundation, so Module 1 gets sharper every cycle instead of going stale.

Then the capstone — Account-in-a-Box — runs all five modules end to end for a single account: foundation, engine, deal, big play, and measurement as one integrated motion, taken from cold to won-and-growing and graded into the credential. The play you just planned is one of its five pieces, and you’ve now built the hardest one to coordinate. The operating guide is the data, deal-desk, and sign-off layer that sits underneath all of it.

Next: Module 5 — measure & forecast, then the capstone.