Build a usage based forecast that holds up when the quarter closes

A usage forecast only works if the inputs are clean. Split every active contract into three revenue streams: fixed platform fees, seat or license revenue, and metered consumption. Platform fees roll forward as a flat line until the renewal date. Seats forecast off headcount and the renewal schedule. Consumption is the stream that needs the full model because it moves daily. Do this split in the CRM first so every downstream report pivots the same way. Teams that skip this step end up double counting committed-use burndown as new revenue, or applying overage math to flat-fee contracts, and the variance never ties out.

• Tag every active contract line with one of three types: platform_fee, seat, or consumption
• Attach the pricing schedule, included units, and overage rate to each consumption line in Strkr
• Build the roll-up so Finance can see the three streams side by side before any forecast math runs

The baseline is the usage an account will produce if nothing changes. For every active account, compute a trailing rate at the meter that bills them: calls per day, gigabytes per month, compute hours per week, whichever matches the invoice. Use a trailing twenty-eight day median rather than a mean so one spike does not pull the baseline up. Normalize for business days when the workload is weekday heavy. Store the baseline per account as a durable field in the CRM, timestamped, so the next cycle can compare drift. Reps and CSMs should see this number next to the account the same way they see ARR today, because it is the anchor every other number in the forecast moves from.

• Pick the meter that matches the invoice line, not the easiest telemetry to pull
• Use a trailing twenty-eight day median and store it as consumption_baseline on the account
• Flag any account whose baseline shifted more than fifteen percent week over week for CSM review

A baseline alone is a flat line. Growth rate turns it into a trajectory. Fit a simple exponential or linear slope on the trailing ninety days of usage per account, then annualize. Pin the slope between a floor and a ceiling so a two week spike cannot imply three hundred percent annual growth. Group accounts into expected growth bands (contracting, flat, growing, scaling) and publish the band next to the account record. For enterprise cohorts, override the fitted slope with the account team's documented expansion plan when one exists. The point is to force a number per account that someone will defend, not a company-wide assumption that hides the variance.

• Fit the slope on log-transformed usage so exponential growth lands as a straight line
• Clamp the annualized rate to a sensible band, often negative fifty to positive two hundred percent
• Publish growth_band on the account and require CSM confirmation for anything in the scaling band

Accounts on tiered plans only generate overage revenue when projected usage exceeds the plan ceiling. Compute, for every account, the probability that projected usage in the forecast period crosses the included-units line. Pull the trailing variance of the account's weekly usage, assume a reasonable distribution, and integrate the tail above the ceiling. The output is an expected-value overage per account, not a yes or no. Sum those across the book and that is the overage line of the forecast. This is where consumption forecasts diverge most from seat models: a sizable share of next quarter's revenue sits inside this one bucket, and it moves every week as account usage moves.

• Compute projected period usage = baseline x period length x (1 + growth rate x fraction of period)
• Model usage variance from the trailing twelve weeks and estimate P(usage > ceiling)
• Multiply the expected overage units by the contract overage rate and roll the expected value into the forecast

Every book of consumption business has a shape of silent decline. Accounts stop deploying new workloads, projects wrap, teams reorganize, and the meter softens without a cancellation ever being filed. Build a cohort decay curve from historical data: group accounts by their start quarter, measure what share of each cohort is still producing meaningful usage at month three, six, twelve, and twenty-four, and fit a decay curve to the shape. Apply that curve to the current book as a drag on the baseline. This is the number that separates teams who hit on consumption forecasts from teams that keep getting surprised, because decay compounds quietly while the headline growth metric still looks healthy.

• Group all accounts by their activation quarter and track active-share month by month
• Fit a decay curve and apply it as a negative multiplier against the baseline for aging cohorts
• Review the decay curve quarterly, because a new onboarding motion or a pricing change will reshape it

The model so far projects revenue from the installed base. Layer two more streams on top: net new logos closing in the period, and documented expansion commits from existing accounts. Keep these honest by treating them the same way a seat forecast would. Each new logo carries a close probability, an expected go-live date, and a ramp curve from zero to projected steady-state consumption. Each expansion commit carries a signed order or a mutual action plan with a committed start date. Do not inflate the installed-base model to compensate for a thin new logo pipeline. The streams must stay separate so leadership can see which lever is actually moving.

• Give every forecasted new logo a ramp curve, not a flat day-one consumption number
• Require evidence (signed order, mutual action plan) before expansion commits land in the Commit tier
• Flag any period where more than forty percent of growth sits in net new logos as a concentration risk

The model is one view. The account team is another. Put the two numbers side by side for every account and flag the gaps. Where the model projects higher usage than the CSM expects, ask what the CSM knows that the signals do not: a project ending, a workload migration, a budget freeze. Where the CSM expects higher usage than the model, ask for the evidence: a new workload approved, a committed-use upgrade in flight, a champion confirmed. Strkr AI can score the delta and surface the five or ten accounts that drive most of the variance so the reconciliation call is tight. The goal is not to pick a winner. It is to force a conversation and get to one defensible number per account.

• Build a side-by-side view: model projection, CSM commit, delta, and reason code
• Review every account where the delta exceeds ten percent of the account's trailing month
• Lock the reconciled number per account in the CRM so the submission trail is auditable

Consumption numbers move every day. A monthly submission is too slow. Set a weekly cycle where usage snapshots refresh on Monday, CSM and model deltas reconcile on Tuesday, Finance signs the number on Wednesday, and the CRO submission goes out on Thursday. Keep the artifact short: three streams (installed base, overage, new logo plus expansion), top five swing accounts, top three risks, top three upside drivers, and variance to prior week. Lock the number inside the CRM once Finance signs, so any later movement creates an audit entry instead of a quiet overwrite. The cadence is what pulls the forecast error down over time, because the loop between a usage shift and a forecast update stays under seven days.

• Automate the Monday snapshot so Finance and RevOps start the week from the same data
• Standardize the Thursday packet shape so the board sees the same five lines every week
• Immutably store each submission so the variance review has clean inputs after the period closes

A consumption forecast gets accurate the same way a seat forecast does: by scoring itself every week and every quarter. After each weekly submission, compare last week's projection to the actual usage that landed, decompose the gap by stream and account, and tag reasons: baseline drift, growth rate change, overage probability miss, decay faster or slower than modeled, new logo slip, expansion delay. Feed those tags back into the model weights. Quarterly, pull the full variance report, publish it to the exec team, and tighten the next cycle's assumptions. Teams that run this loop cut their consumption forecast error roughly in half within three quarters, because the model stops repeating the same mistakes and the account teams stop defending the same optimism.

• Compute weekly variance per stream and tag the top five contributors to the gap
• Decompose quarterly variance by cohort, segment, and reason code and publish the distribution
• Update baseline window, growth clamps, decay curve, and overage variance based on what the tags show