Automating the Weekly Business Review

Most weekly business review meetings fail in the same way. Someone spends Monday morning copying numbers out of five systems into a deck, the numbers disagree with what a director pulled from a different dashboard, and the first twenty minutes of the meeting get spent reconciling instead of deciding. The reporting was automated in name only: the charts refreshed, but the assembly, the definitions, and the judgment did not.

Automating a weekly business review well is less about scheduling a report and more about enforcing a sequence. Compute the numbers deterministically. Lock them. Then, and only then, let anyone (human or model) write about them. This article covers the metric set, the assembly pipeline, the exception rules that make the meeting worth holding, and the specific failure modes that turn automated reporting into a credibility problem.

What the weekly business review is actually for

A weekly review is not a status update and it is not a board report. Its job is narrow: detect drift early enough to act, and force a small number of decisions into the open.

That gives you three concrete outputs per week:

1. A stable metric block. The same numbers, computed the same way, every week, so that trend is readable.
2. Exception callouts. The handful of things that moved outside their normal range, with enough context to argue about.
3. Decisions and owners. What we are changing, who owns it, by when.

Everything else is decoration. If your current pre-read runs eighteen pages and produces no decisions, automating it faster just gets you to the wrong outcome sooner. Cut the metric set before you automate the assembly, because automation preserves whatever structure you feed it.

The other thing worth deciding up front: the meeting reads a document, it does not watch a presentation. A written pre-read, distributed the evening before or an hour before, is the artifact you are automating. Slides are a worse container for this because they encourage one metric per slide and discourage comparison.

Choosing the metric set

The practical ceiling is somewhere around ten to fifteen headline metrics for a company-level review, and three to six per function. Beyond that, nobody reads it and everybody skims to their own section.

Pick metrics along three lines:

• Output metrics that describe the result: revenue, new customers, churned revenue, active accounts.
• Leading metrics that move before the output does: qualified pipeline created, trials started, activation rate, support backlog age.
• Health metrics that catch things breaking quietly: error rate, P1 incident count, time to first response, failed payments.

The reason to separate them is that they answer different questions. Output metrics tell you what happened. Leading metrics tell you what is about to happen. Health metrics tell you what will embarrass you in three weeks.

Define each metric once, in writing

Every metric in the review needs a written spec that lives in version control or a shared doc, not in someone's head. At minimum:

The week boundary line causes more real-world pain than any other row in that table. Finance often runs on calendar months, product analytics tools frequently default to Sunday-start weeks in the account's local timezone, and your warehouse may store UTC. If you do not pin this down, your weekly business review will produce numbers that are individually correct and collectively incoherent.

Watch the denominators

Rates are where weekly reviews go wrong fastest. A conversion rate computed over 40 sessions will swing wildly for reasons that have nothing to do with your business. Set a minimum denominator below which you report the raw count instead of the rate, and say so in the document. "Trial to paid conversion: 3 of 11, rate suppressed, denominator below threshold" is more honest than "27.3%".

Compute the numbers before any AI writes about them

This is the discipline that separates automated reporting you can trust from automated reporting you have to double-check, which is worse than no automation at all.

The rule: language models never do the arithmetic. They receive a finished, locked result set and write prose about it. Anything else, and you will eventually ship a review where a plausible sentence contains a number that exists nowhere in your systems, and you will not catch it because it reads well.

Concretely, the pipeline has two hard-separated stages.

Stage one, deterministic computation. SQL against your warehouse or production replica, API pulls from tools that hold data you cannot query directly, and a small amount of transform logic. The output is a table: metric name, current value, prior value, baseline value, delta, and a flag column. Nothing else. This stage must be reproducible: run it twice on the same day against the same data and you get byte-identical output.

Stage two, narrative generation. Takes the locked table as input and produces sentences. It may explain, connect, and prioritize. It may not compute, estimate, or introduce a number that was not in the input.

A few implementation details that matter more than they sound:

• Snapshot the results. Write stage one output to a dated table or file. When someone asks in April what the March 3rd review said, you want the actual numbers from that day, not a recomputation that now includes backfilled data.
• Round once, at the end. Rounding mid-pipeline and then computing deltas from rounded values produces deltas that do not reconcile with the displayed numbers.
• Bucket in SQL, not in prose. Categorical logic like segment assignment, health tiers, or lifecycle stage should be expressed once in the query. If you are writing long CASE chains for this, it is worth reading up on the patterns and pitfalls of SQL CASE WHEN, because bucketing logic that drifts between queries is a common source of two dashboards disagreeing.
• Make the model's input auditable. Store the exact table that was handed to the writing stage. When a sentence looks wrong, you want to check the input before you debate the prompt.

If your metric layer is genuinely messy, with the same concept defined differently in three places, the fix is upstream of the review. A semantic layer or a shared model file gives every consumer one definition. Our overview of data modelling tools and how to pick one covers the tradeoffs between heavyweight modelling layers and lighter approaches for small teams.

Assembling the weekly business review from source systems

Most companies cannot answer the weekly questions from a single database. Revenue lives in the billing system, pipeline in the CRM, incidents in the on-call tool, support load in the helpdesk, and shipped work in the issue tracker. The assembly problem is real work, and it is where the hours go.

There are several common approaches. The right one depends on how much of your data is already in a warehouse and who is going to maintain the thing in six months.

Two honest notes on that table. First, the screenshot approach is more defensible than people admit, provided the dashboard is the source of truth and the doc is explicitly a pre-read of it. Second, a scripted pipeline is the most durable option and the slowest to start, which is why most teams begin somewhere else and migrate.

Where Skopx fits, and where it does not

Skopx connects to nearly 1,000 business tools and lets you query PostgreSQL, MySQL, and MongoDB directly in chat, alongside data pulled through those integrations. That covers the assembly problem: getting last week's closed-won deals, open P1 tickets, and billing numbers into one place without writing a new connector for each.

It does not build dashboards. Skopx is not a BI tool and does not produce drag-and-drop visualizations. If what you want is an interactive dashboard your team clicks through, use a dedicated BI product and use it well. Skopx is the right tool for the other half of the job: pulling from many systems, answering questions with cited sources, flagging exceptions, and generating the written pre-read on a schedule.

You describe the automation in plain English rather than building it in a canvas. A realistic instruction:

Every Monday at 07:00 UTC, run our weekly metrics query against the Postgres warehouse for the previous ISO week plus the four weeks before it, pull closed-won deals and pipeline created from HubSpot and open P1 tickets from Zendesk for the same window, flag any metric that moved more than 15 percent against its four-week average, then write a one-page pre-read that uses only those numbers and post it to the #leadership Slack channel.

That builds a scheduled workflow: a schedule trigger, integration steps against each source, a transform that computes deltas and sets the flag column, an AI step that writes the narrative from the locked result, and a Slack post. Every run is inspectable step by step, so when a number looks off you can open the run and see exactly what each step returned. The workflows page covers the trigger and step types in more detail.

The limits are worth stating plainly, because they will decide whether this fits your review. Workflows are acyclic and capped at 20 steps. Triggers are manual, schedule (15 minute minimum), or webhook. There are no custom code steps and no human-approval steps in the middle of a run, so a review that requires a finance sign-off before distribution needs that sign-off to happen outside the automation. AI steps run on your own provider key, so the model writing your narrative is one you chose and pay for directly.

Exception callouts are the part that earns the meeting

A table of fifteen metrics with green and red arrows is not analysis. The value of a weekly business review comes from the three to five things that are genuinely off, stated clearly enough that someone has to respond.

Automating exceptions means writing rules, and the rules should be boring and explicit:

• Deviation from baseline. Metric moved more than X percent against its trailing four week average. Set X per metric, not globally, because a 15 percent swing in support ticket volume is normal and a 15 percent swing in gross revenue is not.
• Streaks. Metric moved in the same direction for three or more consecutive weeks, even if no single week broke a threshold. This catches slow bleeds that percentage rules miss entirely.
• Absolute floors and ceilings. Some numbers matter in absolute terms regardless of trend: any P1 incident, any failed payment above a dollar threshold, any enterprise account with zero activity for two weeks.
• Missing data. If a source returned nothing, that is an exception, not a zero. The single most damaging automated report is one that quietly reports zero because an API token expired.

Give every flagged exception the same four-part shape: what moved, by how much against what baseline, what we currently think caused it, and who owns the follow-up. The causal claim is the one part that should be clearly marked as a hypothesis, including when a model wrote it. "Signups down 22 percent versus four week average. Hypothesis: the paid search budget was paused Thursday. Owner: Maya. Confirm by Tuesday." That is useful. "Signups declined due to market conditions" is filler.

Cap the exception list. Five is a reasonable maximum for a company review. If your rules produce twelve every week, the thresholds are wrong and people will start ignoring the section.

Writing the narrative without letting the model invent

Assume the writing stage receives the locked metric table and nothing else. The instructions that actually prevent problems:

• Use only numbers present in the input. If a number is not there, say it is not available rather than estimating.
• Do not compute new figures, including percentages, ratios, or annualized values, unless they are already columns.
• Attribute causes as hypotheses, and name the source of any context used (a specific deal, an incident ID, a campaign name).
• Lead with exceptions, not with the metrics that behaved normally.
• Keep it to one page. Length is the enemy of readership.

Then verify. The cheapest effective check is programmatic: extract every numeral from the generated narrative and confirm each one appears in the source table. Anything unmatched gets flagged before distribution. This catches the failure mode that human proofreading reliably misses, because a wrong number in a well-written sentence does not look wrong.

Charts, and when to stop trying to make the document do everything

A written pre-read benefits from a small number of charts, and suffers from many. Two or three, showing trend over enough weeks to see a pattern, usually beats a grid of twelve.

Chart selection matters more in a recurring document than in a one-off analysis, because readers learn the shapes. Keep the same chart type for the same metric every week so people can compare at a glance, and resist the urge to redesign. If you are deciding what form each metric should take, our guides to choosing the right chart for your data and the different types of charts and when each one works go through the tradeoffs.

The honest division of labor: your BI tool renders the visuals and hosts the interactive drill-down. The automated pre-read carries the metric table, the exceptions, and the narrative, and links to the dashboard for anyone who wants to dig. Trying to make one system do both jobs usually produces a worse version of each.

A four week rollout

Automating this all at once tends to produce a pipeline nobody trusts. A staged approach:

Week one: define. Write the metric specs, including week boundaries and baselines. Get the owners to sign off on the definitions. Do not build anything.

Week two: compute manually, distribute manually. Run the queries by hand, assemble the doc yourself, hold the meeting. You will find three definition problems this week, and it is much cheaper to find them now.

Week three: automate stage one only. Schedule the deterministic computation. A human still writes the narrative. Compare the automated numbers against your manual pull for two consecutive weeks before you trust them.

Week four: automate assembly and drafting. Add the exception rules and the writing step. Keep a named human reviewer who reads the draft before it goes out, indefinitely. The review of the review is not overhead, it is the control that lets you keep the automation.

One durable rule: when the automation and a human disagree about a number, the meeting stops and the discrepancy gets resolved before anything else. Skipping that once is how organizations learn to quietly distrust their own reporting.

Frequently asked questions

What metrics belong in a weekly business review?

Ten to fifteen at company level, split across output metrics, leading indicators, and health metrics. Every one needs a named owner and a written definition covering source of truth, filters, week boundary, and comparison baseline. If a metric has gone six weeks without prompting a question or a decision, cut it.

Should an AI write the narrative for the review?

It can write the draft, but only from numbers that were computed deterministically first and locked before the writing step begins. Never let a model calculate the figures it is describing. Add a programmatic check that every numeral in the generated text appears in the source table, and keep a human reviewer on the final draft.

How do we handle late-arriving data that changes last week's numbers?

Decide the restatement window in advance and publish it: for example, weeks restate for 14 days, then lock. Snapshot every week's computed values to a dated table so the historical record reflects what was actually reported at the time. When a restated figure changes a prior conclusion, call it out explicitly in the next review rather than letting it change silently.

Can Skopx build the dashboards for our weekly business review?

No. Skopx is not a BI or dashboard-building tool and does not produce drag-and-drop visualizations. It handles the assembly and distribution side: querying PostgreSQL, MySQL, and MongoDB in chat, pulling from connected tools across nearly 1,000 integrations, flagging exceptions, and generating the written pre-read on a schedule with a step by step audit trail. For interactive dashboards, use a dedicated BI product alongside it.

What are the limits of automating this with workflows?

Workflows are acyclic with a maximum of 20 steps. Triggers are manual, schedule with a 15 minute minimum, or webhook. There are no custom code steps and no human-approval steps mid-run, so any required sign-off has to happen before or after the run rather than inside it. AI steps use your own provider key, and Skopx does not mark up AI costs.

What does Skopx cost?

Skopx is a paid product and billing starts on day one. There is no unpaid tier and no trial period. Solo is $5 per month, Team is $16 per seat per month with no seat cap, and Enterprise and White Label are $5,000 per month. Current details are on the pricing page. AI usage runs on your own provider key, and Skopx does not mark up that cost.

Skopx catches what falls between your tools, which is usually where the weekly review's most important number was hiding. But the automation is only as trustworthy as the definitions underneath it. Write the specs first, compute before you narrate, and keep a human on the final read.