The final readout went well. The deck was sharp, the ROI-by-channel chart made the room nod, and the recommendations sounded right. The vendor got paid. Everyone shook hands.

Here’s what sometimes happens next: nothing. The deck goes in a shared drive. Twelve months later, someone asks “didn’t we buy a model for this?” and the answer is technically yes, but:

• nobody can run it
• the data behind it is a year stale
• the one analyst who understood it left in March

An MMM is an asset. Like any asset, it only pays out if you build a way to tap into the value. That “build-out” is not the vendor’s job unless you explicitly spelled that out in the scope of work. Using the model, and building what you need to do so, is on you.

This article is the playbook for that operation. If you haven’t signed a contract yet, even better. Every section below is something you can demand as a deliverable before you sign, which is the cheapest moment you’ll ever have to ask.

1. Get everything machine-readable while the vendor is still in the room

The easiest-to-avoid, expensive mistake in MMM engagements is accepting outputs you can look at but can’t compute with. A slide that says “TV ROI: $2.40” is a fact about the past. To forecast anything, you need the model itself, in a form a computer can read:

• Coefficients: for every variable, as a CSV or JSON file.
• Adstock / carryover parameters: how long each channel’s effect persists, and the exact decay function used.
• Saturation curve parameters and functional form: the actual equation (Hill, negative exponential, s-curve, whatever they used) with fitted parameters per channel. A picture of the curve is not the curve.
• Full decomposition: base vs. incremental by channel by period, so you can reconcile the model against your actuals. This is especially useful for evaluating the accuracy of the model, since you can look at when budgets shifted, what the model says should happen, and what actually happened.
• Transformation documentation: every step between your raw data and the model’s inputs (lags, splits, mappings, outlier treatment). If you can’t reproduce the input, you can’t refresh the model. You can also skinny this down, with effort, so that you only pull the data used in the model, and only perform the transformations that ended up in the final model.
• Holdout / validation results and ideally the delta test: does the model correctly predict what happened during your biggest historical spend shifts?

In an earlier post I said to demand an interactive Excel tool before signing. This is the level below that: the Excel tool is built from these files. If the vendor can hand you the tool but not the parameters, you have a black box with a friendly face.

The test: could a competent analyst who has never met the vendor rebuild the scenario tool from what you received? If not, you have a subscription to the vendor rather than a model you can use.

2. Wire the data flows so the model never goes stale

A scenario forecast is only as current as its most recent input. The day the engagement ends, three data streams need to keep flowing without anyone remembering to do it:

• Media spend and activity actuals: by channel, at the model’s level of detail (weekly, usually), matched to when the media actually ran, not when it was invoiced. If your direct mail spend posts three weeks after the drop, that mapping needs to be part of the pipeline, not a manual fix.
• Sales / revenue actuals: from the same system of record the model was trained on. Not “close to” it.
• External variables: every economic, weather, pricing, and competitive series the model uses. If the model includes it, the pipeline feeds it.

Then treat it like a pipeline:

• A schedule. Refresh at the model’s level of detail. If it was a weekly model, do a weekly refresh. Monthly at absolute minimum.
• Validation checks. Does channel spend reconcile to what finance booked? Are there missing weeks? Did a source file quietly change format? A model that gets fed broken data produces confidently wrong forecasts. This is worse than no forecast, because people act on it.
• A named owner. One person whose job description includes “the MMM data are current and correct.” Unowned pipelines die quickly.

3. Write your assumptions down, and version them

Future spend, you control. The economy, the weather, and your competitors, you don’t. And yet every forward-looking scenario embeds a guess about all three. The difference between a defensible forecast and an incomplete one is whether those guesses are explicit inputs or numbers buried in a spreadsheet cell nobody remembers editing.

My suggested, practical defaults for the data:

• Economic variables: Use published consensus forecasts (or FRED series projections) as your baseline, and define one upside and one downside case. You’re just trying to get a range for the forecasts to see how the economics could sway things.
• Weather: Use 10-year averages as the baseline. If you want to get fancy, you can re-run with the historical best and worst years. Weather is a driver you can’t predict but can absolutely create a boundary for.
• Pricing and promotions: This comes from your own calendar, entered as a forward input of what you’ll do.
• Competitive activity: Depending on the industry data you get and the timing of the data, this can be a difficult piece to predict. At a minimum, you can define a “competitor does something big” scenario that would push your own results down a certain percentage. That way, the possibility is part of the conversation and an explicit part of the scenario.

The rule that makes all of this work: assumptions live in a table, with a date and a label. When someone asks in October why the March forecast missed, you can answer “March assumed consensus GDP and normal weather; we got neither”. That’s a solid answer to the question.

4. Give the model a home: SQL, Excel, and Power BI (or Tableau, or other visualization tool) are a stack, not a choice

You might ask “should we put the model in a database, or Excel, or Power BI?” My answer is “yes”. They’re layers for different audiences, and they compose:

• SQL is the source of truth. Tables for coefficients, curve parameters, the assumptions register from section 3, and every forecast run you execute (inputs + outputs + timestamp). This is what makes forecasts reproducible and auditable, and what feeds everything else.
• Excel is the planner’s interface. A workbook that pulls the current parameters and lets a channel manager type spend into cells and watch the forecast move. This is where scenario planning actually happens, because it’s where planners actually live. One workbook with parameters fed from SQL.
• Power BI is the communication layer. Actuals vs. forecast, the decomposition waterfall, and scenario comparisons. These are refreshed from the same SQL tables that feed the planner’s Excel file, so the CMO’s dashboard and the planner’s workbook can never disagree.

You can start all of this with just Excel. A well-built workbook is a legitimate version. When multiple people need slightly different things from the outputs, and more than two people are running scenarios, a fuller stack with the single source of truth becomes a powerful upgrade.

5. What scenario forecasting actually looks like

Everything above exists to make the next two tools possible. Both are live, so click around.

First: response curves. Every channel has one, and the entire point of an MMM is that they’re curved, so the next dollar does not perform like the average dollar. Pick a channel, drag the spend level, and watch marginal ROI fall away from average ROI as you climb the curve:

That gap between average and marginal ROI is one place where budgets can go wrong. A channel can look great on average and still be exactly the wrong place for the next incremental dollar.

Second: the planner view. This is the tool your team should be able to open in any budget meeting. Spend levers plus the assumption inputs from section 3, against a forecast with uncertainty bands:

Both of these run on illustrative numbers, but the mechanics are the real thing: saturation curves per channel, assumptions applied as explicit multipliers, and a comparison against the committed plan. If your vendor delivered the parameters from section 1, tools like these would take days to create, not months. If they didn’t, now you know what to ask for next time.

6. The ways this dies quietly

MMM internalization can die if:

• The coefficients go stale. The market shifts, a channel’s role changes, and nobody re-estimates. Rule of thumb: re-estimate annually, or after any major mix shift, new channel launch, or structural break.
• The pipeline loses its owner. A reorg, a departure, and the refresh just … stops. See section 2: named owner, in writing.
• The model only runs when the vendor is re-hired. This means you never internalize it at all. You bought a series of reports and a vendor subscription.
• The Excel tool gets copied and changed. Twelve copies, twelve sets of “adjusted” parameters, no consistency. The SQL source of truth exists precisely to prevent this.

None of these are modeling failures. They’re operational failures, but that makes them preventable with decisions you can make now.

The model is the easy part

Here’s the uncomfortable summary: the thing you paid the vendor for is maybe half the value. The other half is the system around it, including: the deliverables you insisted on, the pipeline that keeps it fed, the assumptions that are spelled out, and the stack that puts a live forecast in front of every budget decision.

If you’re staring at a finished MMM engagement and wondering how to turn it into that system, or if you’re about to sign with a vendor and want the contract to guarantee you can put in the system, that’s exactly the work I do. Get in touch.