← The Finance Station ~ dish 08 of 10 · the finance station

Scenario Modeling Support

When the CFO needs to model "what if we raised pricing by 5 percent" or "what if churn went from 3 percent to 5 percent," the station runs the numbers fast. Revenue impact. Margin impact. Cash impact. The Chef's hands stay on the wheel. This is drafting under pressure, not analysis at scale. The leverage is the Four D's stance. This dish stays in DIALING. The station generates. The Chef decides what to stress-test next.

The job

Scenario modeling is where financial strategy lives. The CFO thinks: “What if we lost our biggest customer.” That’s not analysis work. That’s decision-support work. The CFO needs the math in 10 minutes so the next decision follows, not a 40-minute report.

Right now the CFO builds a scenario in Excel. Plugs in assumptions. Waits. The next scenario takes another 20 minutes because the first one was a one-off. The model doesn’t remember the structure. It’s fragile. One assumption shift breaks the cascade.

The station runs this recipe right when the Chef gives it a baseline model (last close, actuals, forecast), defines what moves (pricing, churn, volume, cost structure), and asks the next question. The station returns the impact across revenue, margin, and cash. The Chef reads it. Asks the next question. The model remembers what changed.

The recipe

All seven ingredients still apply. The leverage on this dish is The Four D’s stance (DIALING). The station generates scenarios. The Chef’s hands stay on the wheel. This is sparring partner work, not reporting work. The Chef drafts the scenario in plain language (“what if we hired three more people”) and the station translates to numbers and impact.

Training matters. Show the station one baseline scenario you built by hand. How you structure assumptions. How you show impact (revenue line, COGS impact, OpEx impact, net cash impact). Context matters. The station reads the most recent close (actuals), the forward forecast (what’s baked in), and the cost structure by line. Guardrails matter. What never goes below zero on cash. What moves require a second read before the Chef acts on it.

How to build it

  1. Pull your last close. Actuals by revenue line, COGS, operating expense. Build the baseline model from that close plus your current forecast.
  2. Define what moves. Pricing (by segment, by product). Volume (by customer, by vertical). Churn (by customer tier). Cost structure (fixed, variable, one-time). What assumptions are in your baseline.
  3. Pull one scenario you built by hand. “We lose customer ABC” or “we raise pricing by 5 percent.” Show the structure. How you show revenue impact. How you cascade to margin. How you show cash impact. That’s the template.
  4. Pipe in your cost structure by line. Fixed costs. Variable costs. What moves if volume changes. What’s locked in.
  5. Define the guardrails. Cash never forecasts below the safety threshold. Pricing moves over X percent require a second read. Churn over Y percent gets flagged. Customer loss over Z percent gets escalated.
  6. Test on a mock run. Give the station three scenarios: raise pricing 5 percent, lose customer ABC, increase customer acquisition spend by 20 percent. It models each one. You read each. Does the structure make sense. Are the assumptions called out. Adjust.
  7. Go live with Chef on every scenario. The station models. The Chef reads, flags assumptions that feel off, asks the next question. Over time, the model tightens because the Chef’s feedback shapes it.

What breaks it

  • Baseline model is static. The station builds a scenario off a baseline from six weeks ago. Revenue moved. Costs shifted. The baseline is stale before it’s born. Refresh the baseline every two weeks from actual close data, not from “what we expected.”
  • Assumptions are hidden. The scenario says “revenue impact: +$200K” without saying which customers moved, what volume did, what price did. Two weeks later the assumption was wrong. You can’t trace why. Always write assumptions into the scenario output, not into separate notes.
  • Cost structure is incomplete. The model shows variable COGS but misses the semi-variable costs (if you add headcount, you add payroll + benefits, health insurance goes up incrementally, rent might stay flat). Incomplete cost structure means scenarios are wrong by line item.
  • Guardrails are missing. The station models a scenario where cash drops to zero. The Chef doesn’t know until they read it. Define what-if scenarios require a second read upfront. Cash below threshold. Revenue below forecast by X percent. Customer concentration over Y percent. Flag before you model.
  • Feedback loop death. The Chef runs a scenario and thinks “that churn assumption feels high.” The Chef never tells the station. Next scenario uses the same high assumption because the feedback never made it back.

When it’s working

At week four, the Chef can ask for a scenario in plain language and get the modeled impact in 10 minutes. Three assumptions are called out. The Chef reads it and asks the next question without clarifying. Decisions on pricing, hiring, and customer concentration happen faster because the math is instant, not a bottleneck. The Chef runs six to ten scenarios a month, not one or two.

The signal that the recipe is sharp: the Chef asks for three scenarios in rapid succession without waiting for the analysis to be written up. The model is live. The Chef is thinking. The station is following.

Monday Move

Build your baseline model from the last close. Define what moves (pricing, volume, churn, cost structure). Pull one scenario you built by hand. Pipe in your cost structure by line. Define your guardrails. The station is modeling on Monday.

Dish 8 of 10 on the Finance Station. Build-note leverage: Four D’s stance (DIALING).