The client is a B2B SaaS company with about 80 employees, serving mid-market customers. Their customer success team of six was the bottleneck on renewals. They had told us in passing, on an unrelated call, that prepping for a single QBR (quarterly business review) was taking each rep five to six hours. We asked to shadow one.
Here is what we watched the rep do.
The original workflow
For each upcoming QBR, the rep would:
- Pull the customer's billing history from Stripe.
- Pull usage metrics from Mixpanel: daily active users, feature adoption, trend over time.
- Pull account information from Salesforce: contract terms, primary contact, prior renewal notes.
- Open a shared Google Sheet that the team used for "QBR prep notes," which was a freeform list of recent support tickets and product feedback.
- Copy all of this into a Google Slides template, manually formatting the charts.
The slide deck took roughly 90 minutes. The hour and a half before that was spent in Stripe, Mixpanel, Salesforce, and the spreadsheet, switching tabs, hunting for the right view, and translating numbers into screenshots.
Six reps, three to four QBRs each per week, five-plus hours per QBR. Conservative math: 40 to 60 hours a week of pure tab-switching.
What we proposed
Build a single internal screen that, given a customer name, shows everything needed for a QBR on one page. Pull the data live from the source APIs, render the standard charts inline, and add a "copy to clipboard" button for the bits that needed to go into the slide deck.
No machine learning. No AI. Just a focused screen that joined four data sources behind a single URL.
Two-week sprint. One week of discovery, one week of build.
How we built it
The stack was deliberately boring. Next.js for the UI, FastAPI for the backend, Postgres for caching. Each API integration was its own small client module with sensible rate limiting and a 15-minute cache.
The UI was four sections on one page: a header with the account contract terms, a charts row showing usage over time, a recent-activity feed (support tickets, in-app actions, billing events on a single timeline), and a "talking points" section that auto-generated a draft based on simple rules (e.g., "usage is up 22% quarter over quarter, mention it" or "two open support tickets older than 14 days, prepare to discuss").
We did not ship any AI features. The temptation was there. We resisted because the value was in the join, not the summarization. The reps were perfectly capable of writing talking points if the data was in front of them. They just needed it not to take 90 minutes to gather.
What the rollout looked like
We deployed to a staging URL for the CS team on a Thursday. By Monday, all six reps were using it. There was one bug (Mixpanel dates were off by a timezone), which we fixed in an hour.
Two weeks in, the head of CS sent us a Loom. He had timed himself doing a QBR prep with the new tool: 22 minutes, including writing the slides. The 90-minute deck-building step had compressed to 8 minutes of polish, because the talking points were already half-drafted.
The numbers
- Time saved per QBR: about 4 hours.
- Total time saved per week across the team: roughly 40 hours (close to a full FTE).
- Cost of the build: about $34,000.
- Fully-loaded cost of an FTE on this team: roughly $5,000 per week.
- Payback period: 7 weeks.
One of the reps was reassigned to a new high-touch account, because the time freed up turned into capacity for the kind of work they'd been wanting to do for a year.
Why we keep recommending internal tools
Internal tools have the highest ROI of anything we build, by a long way. Customer-facing features compete with whatever else is on your roadmap and rarely have such clean before-and-after numbers. Internal tools have a captive audience (your own team), a clear baseline (how long does the manual version take), and immediate feedback (your team will tell you within two days if it isn't working).
If you have a process where two or more people are doing the same multi-tab thing every week, there is almost certainly a two-week internal tool that pays back in two months. The hard part is noticing the workflow, because the people doing it have stopped noticing how bad it is.