---
name: qbr-pack
description: Assemble the QBR deck from usage, tickets, and account history, with every claim tied to real data. Use this skill when: QBR scheduled on the calendar — Or a manual kickoff two weeks out.
---

# Build the QBR deck before the agenda

Goal: assemble the QBR deck from usage, tickets, and account history and ground every claim in real data.

Connected tools this skill uses: posthog, zendesk, salesforce, slack.

## When to use

- QBR scheduled on the calendar — Or a manual kickoff two weeks out.
- Or when the user asks directly to assemble the QBR deck from usage, tickets, and account history and ground every claim in real data.

## Method

Build the QBR pack for {{account}}, quarter {{quarter}}.

1. Pull {{account}}'s usage trend from PostHog, ticket history from
   {{support_tool}}, and deal/contract facts from {{crm}} since the last
   QBR ({{last_qbr_date}}).
2. Draft the narrative: top 3 wins (with the usage or ticket data behind
   each), any open risk, and the ask for next quarter.
3. Validation: check every claimed win and risk against its source data
   point. Drop any line that isn't backed by a real number or a real
   ticket, don't soften it, remove it.
4. Build the deck from the narrative using the presentation skill: title,
   wins, usage story, risks, next-quarter ask.
5. Save the deck to `documents/qbr/{{account}}-{{quarter}}.pptx` and a text
   version of the narrative to `reports/qbr/{{account}}-{{quarter}}.md`.
6. Post a summary to {{delivery_channel}}: deck link, top win, top risk,
   for the CSM to review before the customer meeting.

Do not send the deck to the customer directly, it is a draft for the CSM
to review, adjust tone on, and present themselves.

## QBR narrative structure

Build the account story in a fixed order: wins, usage story, risks, then the ask.

## Method
1. Open with the top 3 wins since the last QBR, each backed by a usage or ticket data point.
2. Follow with the usage story: adoption trend since {{last_qbr_date}}.
3. State any open risk plainly, without softening language.
4. Close with one clear ask for next quarter.
5. Keep the section order fixed: wins, usage story, risks, ask — do not reorder per account.

## Rules
- Follow the fixed order every time: wins, usage story, risks, ask.
- A claimed win needs a real data point behind it before it enters the narrative.
- State risks directly — no vague language standing in for a real concern.
- What counts as a "win" worth including: (set on first run, then stored in memory).

## Output
A structured narrative with four labeled sections: wins, usage story, risks, next-quarter ask.

## Value-story grounding

Tie every claimed win or risk to a real usage or ticket data point before it reaches the deck.

## Method
1. For each claimed win, name the exact PostHog metric or ticket that supports it.
2. For each claimed risk, name the exact signal: a usage drop, an unresolved ticket, a sentiment shift.
3. Re-check every claim against its source after the narrative is drafted.
4. Drop any line with no real number or ticket behind it — do not soften it, remove it.
5. Keep the data point visible next to the claim in the narrative draft.

## Rules
- No claim ships without a named data source: a metric, a ticket ID, or a contract fact.
- Drop unsupported claims entirely; never rephrase one to sound more defensible than the data allows.
- Prefer a specific number over a general trend description.
- Recheck grounding every run — never carry forward a prior quarter's unverified claim.

## Output
A grounded narrative where every win and risk line has its source data point attached.

## Presentation builder

Turn the validated narrative into a formatted deck using the presentation (pptx) skill.

## Method
1. Take the validated narrative, wins, usage story, risks, ask, as the deck's content source.
2. Structure the deck: title slide, wins, usage story, risks, next-quarter ask.
3. Apply the team's standard QBR deck template and branding.
4. Keep slide text tied to the same data points cited in the narrative — add no unsourced detail on the slide.
5. Save the deck to documents/qbr/{{account}}-{{quarter}}.pptx.

## Rules
- Never add a claim to a slide that is not already in the validated narrative.
- Standard QBR deck template or brand: (set on first run, then stored in memory).
- Keep one slide per narrative section — do not compress or drop a section for length.
- The deck is a draft for the CSM to review and present, never sent to the customer directly.

## Output
A .pptx deck at documents/qbr/{{account}}-{{quarter}}.pptx, plus the text narrative it was built from.

## Recurring jobs

This skill pairs with scheduled jobs. Offer to set each one up; only create the ones the user approves:

- QBR calendar watch (Every morning on weekdays) — https://eluu.ai/cookbook/qbr-pack/jobs-setup/qbr-calendar-watch.md