# How we put together first-draft QBR decks for key accounts Each week, a Machine agent reads Postgres and HubSpot for every account with a QBR coming up and builds a draft Google Slides deck plus a Google Docs briefing for the CSM to edit and present. Canonical page: https://themachine.myapps.ai/use-cases/qbr-prep A quarterly business review lives or dies on the homework. Trouble is, the homework is spread all over the place. How much the account uses the product sits in the product database. Its health score and the CSM's notes are in HubSpot. Support history is buried in three months of tickets. The growth opportunity is mostly in somebody's head. Turning that into slides by hand eats an afternoon per account. Multiply by a few dozen accounts and QBR week becomes a slide factory, when it should be time spent thinking about each customer. Our QBR-prep agent on Machine handles that gathering every week. It pulls from each source, writes a draft deck and a matching briefing doc for every account with a review coming up, and then stops. It never writes back to a source and never presents. The CSM opens the draft, reworks the story, and takes it into the meeting. - **Team:** Machine - **Runs on:** A cron once a week - **Connected systems:** Postgres · HubSpot · Google Slides · Google Docs - **Mode:** Only reads the sources · writes one draft deck and one briefing doc per account ## The problem Everything you need for a QBR exists. It's just not in one place. Usage over time lives in Postgres. Health, CSM notes and the history of the deal live in HubSpot. Support pain is a quarter of tickets nobody has the hours to read again. And the upsell story gets stitched together from all of that, often from memory, minutes before the call. A template gives you a nice layout. It doesn't do the gathering. Somebody still has to fetch each figure, read each note, and choose what deserves a slide. One account takes an afternoon. Every due account, every week, is the bit that gets skipped, rushed, or dumped on whoever looks least busy. That's precisely how a CSM ends up underprepared for a renewal conversation. ## What we built Once a week, a cron on Machine starts an agent in a sealed-off session that can read Postgres and HubSpot but not change them. It works out which accounts have a QBR due in the coming window. For each one it gathers usage trends, the value the customer has had, account health, a summary of support, and openings to expand. It turns that into a draft deck in Google Slides and a briefing doc in Google Docs that holds the supporting detail. Then it stops. Nothing gets shared, presented or sent. The CSM reviews both and runs with them. ## How it works ### Start once a week A **cron trigger** kicks off the agent weekly. Each run gets a new **session**, a fresh cloud computer set up just for that run. It has no memory of last week, so it works out again who's due and what their numbers say, straight from the data as it stands today. ### Hand it the QBR outline What belongs in the deck, and the order it goes in, is written into a **skill**, the playbook the agent carries. It spells out how we measure a usage trend, what "value delivered" means for our product, how account health adds up, how to sum up three months of support without hiding the one problem that counts, and what makes an expansion signal believable rather than wishful. ### Read the sources, write only the drafts Scoped **connectors** link the agent to each system. Machine keeps the tokens on its own servers, so the model never sees one. With them the agent: - **Pulls usage from Postgres.** How active each account has been and how far adoption has spread across the quarter. - **Pulls account and CSM details from HubSpot.** The health score, CSM notes, past support tickets and the deal record, which also tell it who's due and why. - **Builds the draft deck in Google Slides.** The QBR deck itself, one for each account that's due. - **Builds the briefing doc in Google Docs.** The detail behind each slide, so the CSM has backup when a question goes past what the deck shows. ### Draw the lines Postgres and HubSpot are **read-only**. However much the agent reads from them, it can't alter a usage record, a health score, a note or a deal. The only things it writes are the new deck and the new doc it makes. Credentials are stored encrypted in the Secrets Manager, added at run time, and only handed to the agents you grant them to. ### Drop off the drafts and step back By the end of a run, each due account has a draft deck and a briefing doc in a shared folder, named after the account and the quarter. The agent says where it put each one and stops. The CSM checks the story, rewrites the commentary, and is the person who runs the meeting and presents. > **The pattern** > Once a week a **cron** opens a session with **connectors** that can only > read Postgres and HubSpot. A **skill** holds the deck outline. The agent > reads the account's quarter, makes exactly two drafts, a deck and a > briefing doc, and hands over to the CSM. ## Guardrails This agent reads a lot of account data, so what it can reach is narrow and what it can produce has a hard edge: - **Kept apart.** Each run gets its own sealed-off sandbox. The session can reach only the systems it's been scoped to, and the new deck and doc are the only things it sends back out. - **Locked-down keys.** The Postgres and HubSpot credentials are stored encrypted in the Secrets Manager, added to the sandbox at run time, and only handed to the agents you grant them to. - **The sources are read-only.** Its connectors to Postgres and HubSpot can only read. Usage records, health scores, CSM notes and deals are there to learn from, never to edit. - **Drafts, never sent.** The deck and the briefing doc stay drafts. The agent won't share, present or email either of them. The CSM reviews and does the presenting. - **All of it lives in code.** The deck outline, the skill and what each system lets it do are files in the repo. They're versioned, and you change them with a reviewed **change request**, not a setting on a dashboard. ## The outcome - **Weekly:** Each account with a review coming up gets fresh prep before the CSM meets them - **Read-only:** Postgres and HubSpot are never written to - **2 drafts:** A deck and a briefing doc for each account, without fail The afternoon of digging up numbers and rereading tickets now takes care of itself each week, for each account that needs it. The CSM opens a deck that already shows the trend, the health picture, the support summary and a possible expansion angle. They rewrite the story in their own voice and present it themselves.