Automating Monthly Business Reviews With Live Database Data

Monthly business reviews (MBRs) are supposed to drive decisions. In practice, they too often become a exercise in data wrangling someone spends two days pulling numbers from multiple sources, pasting them into a spreadsheet, formatting charts, and hoping nothing changed by the time the meeting starts.

The core problem is that MBR data is almost always stale the moment it's assembled. Revenue figures are pulled Monday, the review happens Friday, and by then three deals have closed and two churned. Leaders make strategic calls based on a snapshot that no longer reflects reality.

If your business data lives in a database and for most SaaS companies, e-commerce businesses, and ops-heavy teams, it does there's a better way. This article walks through how to build an MBR process driven directly by live database data, including the SQL patterns that matter and where AI-powered tools can eliminate the manual work entirely.

Why Most MBR Processes Break Down

The typical MBR workflow looks like this: an ops manager or analyst owns the process, exports CSVs from a CRM or analytics platform, combines them in Excel, and builds the same charts every month. It works until it doesn't.

The failure modes are predictable:

The fix isn't to hire more analysts. It's to move the MBR data layer directly into the database, where it belongs.

The Database Queries That Power a Strong MBR

Most of the key MBR metrics are straightforward SQL queries. The challenge is that they need to be recalculated monthly, sliced in multiple ways, and compared against prior periods.

Here are the core queries that underpin most MBRs:

Monthly Recurring Revenue (MRR) by segment:

SELECT
  DATE_TRUNC('month', subscription_start) AS month,
  plan_tier,
  SUM(monthly_amount) AS mrr
FROM subscriptions
WHERE status = 'active'
  AND subscription_start >= NOW() - INTERVAL '12 months'
GROUP BY 1, 2
ORDER BY 1, 2;

New vs. expansion vs. churned revenue (revenue waterfall):

SELECT
  month,
  SUM(CASE WHEN type = 'new' THEN amount ELSE 0 END) AS new_mrr,
  SUM(CASE WHEN type = 'expansion' THEN amount ELSE 0 END) AS expansion_mrr,
  SUM(CASE WHEN type = 'churn' THEN amount ELSE 0 END) AS churned_mrr
FROM revenue_movements
WHERE month >= DATE_TRUNC('month', NOW()) - INTERVAL '6 months'
GROUP BY month
ORDER BY month;

User activation rate by cohort:

SELECT
  DATE_TRUNC('month', u.created_at) AS signup_month,
  COUNT(DISTINCT u.id) AS signups,
  COUNT(DISTINCT e.user_id) AS activated,
  ROUND(COUNT(DISTINCT e.user_id)::numeric / COUNT(DISTINCT u.id) * 100, 1) AS activation_rate_pct
FROM users u
LEFT JOIN events e
  ON e.user_id = u.id
  AND e.event_type = 'key_action_completed'
  AND e.created_at <= u.created_at + INTERVAL '7 days'
WHERE u.created_at >= NOW() - INTERVAL '6 months'
GROUP BY 1
ORDER BY 1;

Support ticket volume and resolution time:

SELECT
  DATE_TRUNC('month', created_at) AS month,
  COUNT(*) AS tickets,
  ROUND(AVG(EXTRACT(EPOCH FROM (resolved_at - created_at)) / 3600), 1) AS avg_resolution_hours
FROM support_tickets
WHERE created_at >= NOW() - INTERVAL '6 months'
GROUP BY 1
ORDER BY 1;

These queries are correct and repeatable. The problem is that someone has to run them each month, interpret the results, and format them for presentation. That's where the process breaks down.

Building a Self-Refreshing MBR Dashboard

Instead of running these queries manually each month, you can build a dashboard that runs them automatically and always shows current data.

The approach: connect your database directly to a dashboard tool that supports scheduled refresh, write each MBR metric as a query, and let the dashboard handle the rest. When someone opens it the morning of the review, the numbers reflect what's actually in the database right now.

With AI for Database, you don't need to write the SQL yourself. You connect your PostgreSQL, MySQL, Supabase, or other database, then ask questions in plain English:

The AI translates each question into SQL, runs it against your live database, and returns a table or chart. You pin those queries to a dashboard, set a refresh schedule, and the MBR data layer is done.

This matters especially for non-technical team members who need to dig into numbers during the review itself. Instead of waiting for an analyst to run a new cut, anyone can type a follow-up question and get an answer immediately.

Setting Up Automated Alerts for MBR Metrics

A dashboard is passive it shows you what's happening when you look at it. But some MBR metrics warrant active monitoring. If your churn rate spikes mid-month, you want to know before the review, not at it.

This is where action workflows change the process. The idea is simple: define a condition based on your database data, and define what should happen when that condition is met.

Practical examples for MBR-relevant monitoring:

In SQL terms, each of these is a query that returns a boolean condition. The workflow watches the database on a schedule, runs the query, and fires the action if the condition is true.

-- Churn spike detection
SELECT
  COUNT(*) AS cancellations_last_7_days
FROM subscriptions
WHERE status = 'cancelled'
  AND cancelled_at >= NOW() - INTERVAL '7 days'
HAVING COUNT(*) > (
  SELECT COUNT(*) * 1.5 / 30 * 7
  FROM subscriptions
  WHERE status = 'cancelled'
    AND cancelled_at >= NOW() - INTERVAL '30 days'
);

When this query returns a row, something worth flagging is happening. The action workflow fires, the right people find out, and the MBR meeting starts with context rather than surprise.

The MBR Meeting Itself: Answering Ad-Hoc Questions Live

Even the best-prepared MBR hits moments where someone asks a question that wasn't anticipated. "Can we see that broken down by geography?" or "What does that look like excluding enterprise customers?" In a traditional setup, that question gets deferred to the next meeting.

With direct database access through a natural language interface, those questions get answered on the spot.

During the review, someone can ask:

Each of these translates to a SQL query that runs in seconds. The answer is live data, not a pre-built chart that may not address the actual question.

This shifts MBR meetings from report-reading sessions to actual decision-making forums. The data is available, it's current, and anyone in the room can ask a follow-up.

Connecting Multiple Data Sources for a Complete Picture

One common MBR challenge is that the full picture spans multiple systems. Revenue data lives in the billing database, support tickets in a helpdesk database, user events in an analytics database, and pipeline data in a CRM.

If all of those systems use databases you can connect to, you can query them in the same interface and build a composite MBR dashboard. A query might join your Supabase user table with your PostgreSQL billing records, or pull from BigQuery event data alongside your MySQL customer table.

The MBR becomes a single source of truth rather than a patchwork of exports from different tools.

For teams that have grown beyond a single database but haven't yet invested in a full data warehouse, this approach covers a lot of ground. You're not ingesting or copying data you're querying it where it lives.