QBR Prep

skill

Pull account metrics via API and assemble a QBR (quarterly business review) deck outline file.

Download .md

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.