# QBR Prep

Pull account usage and health metrics from connected SaaS systems and assemble them into a structured quarterly business review (QBR) deck outline file for the customer success team.

## When to use

- A QBR is scheduled for a named account and metrics need to be compiled beforehand.
- A customer success manager asks for a fresh outline of account health, usage trends, and renewal risk.
- Recurring end-of-quarter prep cycle for a book of accounts.

## Tools

- `http-get` — read account usage, billing, and support-ticket metrics from connected SaaS systems (CRM, product analytics, support desk).
- `shell-execute` — compute period-over-period deltas, aggregate metrics, and format tables from the pulled data.
- `write-file` — save the finished QBR deck outline as a file artifact.

## Playbook

1. Confirm the target account name and the quarter/date range to cover.
2. Call the CRM REST API with `http-get` (e.g. GET https://api.hubapi.com/crm/v3/objects/companies/{id}) to pull account details, contract value, and renewal date. Authentication is injected by the org's Integration row for this host — never ask for, echo, or hardcode credentials. If the call returns 401/403 or no Integration row exists, stop and message a human via send-message asking them to create the Integration, naming the service and required scopes.
3. Call the product analytics API with `http-get` to pull usage metrics (active users, feature adoption, login frequency) for the account over the target period, using the same Integration-row authentication pattern.
4. Call the support desk API with `http-get` to pull open ticket count, average resolution time, and any escalations tied to the account.
5. Use `shell-execute` to run a small script that merges the pulled data, computes quarter-over-quarter deltas (usage growth/decline, ticket trends), and flags risk signals (e.g. declining usage, unresolved escalations).
6. Structure the results into standard QBR sections: account overview, usage trends, support health, risks, and recommended next steps.
7. Use `write-file` to save the outline as a deck-ready markdown or text file, named clearly with the account and quarter.
8. If any metric needs a correction pushed back into the CRM or another system (e.g. updating a health score field), that is a PATCH/PUT operation and is NOT POSSIBLE with this skill's tools — compile the change into the outline file and hand off to a human via send-message rather than attempting the update.

## Failure modes

- 401/403 response from any API -> missing Integration for that host; stop and escalate via send-message naming the service and required scopes.
- Empty or zero-value metrics returned -> verify the endpoint and query parameters (account ID, date range) before treating the result as real.
- Rate limit (429) response -> back off and retry later; note the limiting service in memory via update-memory so future runs pace requests accordingly.
- Source page or dashboard structure changed and expected fields are missing -> fall back to browser-search to confirm current field names or endpoint paths before retrying.

## Done when

- A QBR outline file exists on disk, written via `write-file`, containing account overview, usage trends, support health, and risk sections populated with real pulled metrics.
- All metrics in the file are sourced from live `http-get` calls made during this run, not stale or placeholder values.
- Any required system-of-record updates are listed as a human handoff rather than silently skipped or falsely marked complete.