Optimized Sales Optimized Marketing Target Accounts For CROs For CFOs For CMOs Blog News Glossary Compare Tools About Schedule a Demo
Revenue Operations

How to Run a Weekly Revenue Update

Pete Furseth 6 min read
weekly revenue updaterevenue reportingoperating cadencerevenue operationssales operationssales operations metrics
How to Run a Weekly Revenue Update
Home/ Blog/ How to Run a Weekly Revenue Update

What is a weekly revenue update?

A short written report, sent the same day each week, showing what changed in the revenue numbers and why.

The emphasis belongs on changed. A weekly report that restates every metric at its current value teaches readers to skim, because almost all of it is identical to last week. A report built around movement tells the reader in 60 seconds where their attention is needed.

The format that people read is a message containing the numbers they care about with an explanation of what moved since the previous week, specific to their business. That is a low bar in principle and a rare thing in practice, because most revenue reporting is organized around the metric list rather than around the delta.

Put this to work on your numbers
Run your own numbers with the free Pipeline Velocity Calculator, then see how ORM builds it into a custom model.

Why send a written update instead of adding a meeting?

Because retrieval is what consumes meeting time, and retrieval does not require a meeting.

Watch any weekly revenue meeting and count the minutes spent pulling up numbers, reconciling two versions of the same figure, or explaining how a metric is defined. That work can happen once, in writing, before anyone joins a call. What is left is discussion of decisions, which is what the meeting is for.

A written update also creates a record. Six weeks later you can see what was known and when, which makes quarter retros a matter of reading rather than remembering.

What goes in it?

Six sections, in the same order every week.
SectionWhat it reportsCommentary trigger
Quarter to date versus planClosed won against the quarter targetAlways
Forecast movementCommit and best case change since last weekAny change above your threshold
Pipeline createdNew opportunities by source and segmentCreation below the weekly target
Pipeline coverage by segmentCoverage where the gaps are, never in aggregateAny segment moving by half a turn
Close date changesCommitted deals whose date moved this weekEvery occurrence, named
Retention movementContraction, churn, and expansion booked this weekAny account above your size threshold
The close date row deserves its permanent place. A rep changing a close date is the strongest single signal that a deal is at risk, and a deal that slips from one quarter into the next is less likely to close even when it stays in commit. Surfacing those changes weekly, by name, makes a pattern visible that a quarterly review would find far too late.

Coverage belongs in the update by segment and never as a single company number. A company can hold 4x coverage and still miss when the pipeline is concentrated in the wrong segment, aged, or dependent on a few large deals. Across ORM's customers coverage runs from 1.4x to 5x with most near 3.5x, and the aggregate figure conceals exactly the composition problems that decide the quarter.

What counts as a change worth writing about?

Set thresholds in advance, or the update turns into narration.

Without thresholds, whoever writes the update includes everything that felt notable, which varies by author and by week. Define the triggers once and apply them mechanically:

- Any single deal above a set share of the quarter target moving forecast category. - Any segment whose coverage moved by more than half a turn. - Any close date change on a committed deal. - Any renewal or contraction above a stated ARR threshold. - Forecast accuracy at the current week of quarter drifting outside its normal band.

Everything else appears as a number in the table with no commentary. That restraint is what keeps the document to a page and keeps executives reading it.

Who writes it and when does it go out?

RevOps drafts from frozen data, the revenue leader adds interpretation, and it ships at the same hour every week.

The freeze matters. Draft from the same locked snapshot the forecast call uses so the update and the meeting cannot disagree. Two documents with different numbers destroy trust in both.

Keep the leader's contribution short. Two or three lines of interpretation on what the movement means and what the team is doing about it is enough, and it signals that a decision maker has read the numbers before circulating them. Send it the same day and hour every week, and hold that schedule even in quiet weeks, because a report that only arrives when something is wrong becomes an alarm rather than an instrument.

What should never appear in it?

Vanity metrics, silently restated history, and untraceable numbers.

Vanity metrics are the easiest to spot. If a number has never changed a decision, it does not belong in a weekly document, however good it looks. Total activity counts and cumulative lifetime totals are the usual offenders.

Restated history is more damaging. When a prior week's number changes because of a data correction or a definition change, say so in a line at the bottom. Numbers that quietly move destroy confidence faster than bad numbers honestly reported.

Traceability is the one to design for from the start. Every figure in the update should point back to the report or query that produced it. This is the gap that matters most with AI-generated summaries: if you cannot trace a number to its source, validating it takes as long as building the analysis yourself, which erases the time the automation was supposed to save. A weekly update whose numbers can be traced in one click gets trusted and acted on. One that cannot gets quietly re-derived by three people in three spreadsheets, which is where your reporting problem started.

Frequently Asked Questions

What is a weekly revenue update?

A short written report sent on the same day each week that shows what changed in the revenue numbers since the previous week. It reports movement and the reasons behind it rather than restating the full metric set.

Who should write the weekly revenue update?

RevOps drafts it from the frozen data snapshot and the revenue leader adds interpretation. Splitting it that way keeps the numbers consistent while making sure a decision maker has read them before anyone else does.

What should a weekly revenue update include?

Quarter to date against plan, forecast movement week over week, pipeline created, coverage by segment, close date changes on committed deals, and retention movement. Each item gets commentary only when it crosses a defined threshold.

Why send a written update instead of holding another meeting?

Because most meeting time goes to retrieving numbers rather than deciding anything. Sending the numbers in advance means the meetings you keep can start at the decision.

What should never appear in a weekly revenue update?

Vanity metrics that never change a decision, restated history without a note explaining the change, and any number whose source cannot be traced. An untraceable number costs the reader as much to verify as it would have cost to produce.

PF
Pete Furseth
ORM Technologies
Pete has built custom revenue forecast models for B2B SaaS companies for over a decade.

See how ORM turns these insights into action

ORM builds custom revenue forecast models for B2B SaaS companies. Not dashboards. Prescriptive analytics that tell you what to do next.

Schedule a Demo