Jake Diego.
Case study

A command center that replaced five spreadsheets with one screen

How a customer success team went from "who's at risk?" being a Slack question to an answer that updates itself every morning.

What problem does the customer success command center solve?

It replaces scattered spreadsheets and a Slack channel with one screen that shows which customers need attention today.

The customer success team was running on scattered spreadsheets: one for renewals, one for onboarding status, one for at risk flags kept in someone's head and a Slack channel. Nobody had a single place to see who needed attention today, and there was no reliable way to answer a simple question a leadership team asks constantly: is the customer success function actually working, in dollars?

Manual tracking also meant the team's own effort was invisible. Follow ups happened, calls got made, and none of it rolled up into a number anyone could point to.

What is inside the customer success command center?

A single web dashboard combining customer health, at risk flags, renewal dates, task assignments, and meeting history.

Everything rolls up into one live view: the team opens one tab in the morning instead of five spreadsheets and a Slack search.

Command center overview dashboard screen

The overview screen: today's flagged accounts, workload by team member, and pipeline health at a glance.

Key pieces of the system:

  • An at risk flagging workflow that surfaces accounts needing attention before they churn, not after.
  • A renewal and retention view that tracks every account through to a resolved outcome.
  • Task and meeting logs tied directly to each customer record, so history isn't scattered across tools.
  • An operator task board that runs the team's daily and weekly routines with one click, keeps the primary action obvious by placing secondary and legacy options behind a toggle, and moves wound down workflows into a separate retired section so the active list stays focused.
  • An internal value/ROI ledger that credits the team with the revenue its work actually retains.
Churn and at risk tracking screen

The at risk view: every flagged account tracked through to an outcome.

Retention tracking screen

Retention tracking: renewals and save attempts in one queue.

What results did the command center produce?

33 at risk customers were tracked to a resolved outcome, with 20 retained and $30,321 in credited revenue.

The screens above are shown with illustrative example data for a fictional company, Brightline Ops. The metrics directly below are different: they are real, measured outcomes from the production system this case study describes, with the client anonymized. Further down, the "Retention value engine" panel returns to clearly labeled illustrative data.
33 at risk customers tracked to a resolved outcome (measured)
20 of 33 retained, with the rest churned or still open (measured)
1 screen replaced five separate spreadsheets and a Slack channel
Same day visibility into every account's status, instead of a weekly manual roll up
$30,321credited to the workflow; every dollar traces to a retained account; nothing is credited for churned or still open ones (measured)
20 retained · $30,321 credited 5 churned · $0 credited 8 open · still pending
Value and ROI ledger screen

The value/ROI ledger: retained revenue credited directly to the workflow that saved it.

Retention value engine

Illustrative data for Brightline Ops, a fictional company, shown to demonstrate how the value engine reads a weekly churn trend before and after the workflow goes live.

workflow went live Week 1 Week 12
Before (weekly churn, preworkflow) After (weekly churn, workflow live)

Illustrative example, not a verified client outcome:

Illustrative data 24 at risk customers retained by the workflow
Illustrative data $60,000 retained revenue (24 customers x $2,500 avg lifetime value)
Illustrative data 46 hrs manual tracking and follow up hours saved per month

Methodology: the baseline churn rate is the trailing average measured before the workflow went live. Each week after launch, the engine computes a counterfactual expected churn count from that baseline and compares it to what actually happened, crediting the difference only down to a conservative floor band so a quiet week never overstates the save. The chart and stats above use illustrative numbers scaled from the same method the real engine runs, not figures from any specific customer.

Tech approach

Built with Python on the backend and a lightweight web dashboard on the front end, with a spreadsheet backed data model so the team could keep using familiar tools underneath a much better interface. Data updates flow in on a schedule rather than requiring anyone to manually refresh a report. The value/ROI layer uses event sourcing (it records each change as a dated, replayable entry rather than overwriting a running total), so every credited dollar traces back to a specific tracked outcome, not an estimate.

The goal throughout was to build something the team would actually open every morning, not a reporting tool that gets checked once a quarter.

Related systems

Market Intelligence Pipeline · an automated four stage pipeline that turns raw public data into a ranked opportunity list.

Price History Tracker · stitches every price sheet into one self refreshing time series, built in a day.

AI Visibility Audit · a structured audit run on this very site to make it findable, trusted, and quotable by AI answer engines.

Video to Documentation Pipeline · turns one monthly walkthrough recording into four polished, branded release documents automatically.

Try the live interactive demo →   Back to projects