Practice a Forecast Review With a Changing Baseline

TL;DR

• In this fictional forecasting exercise, a changed baseline must not be confused with a planned intervention's effect.
• Keep the original dated forecast and offer scenarios with explicit conditions.
• Define an update rule and evaluate error against the decision while distinguishing planned changes from observed response.

Establish what the forecast was assuming

In this fictional interview, a team forecasts support demand using recent ticket volume. Before the next period begins, the product changes its pricing and launches a new onboarding flow. The interviewer asks whether you would keep the original forecast.

Start by identifying the forecast's purpose, horizon and underlying assumptions. A staffing estimate may need a range and a contingency plan, while another decision may tolerate a rough directional view. Do not treat the forecast as an immutable promise simply because it was presented earlier.

The business change does not automatically invalidate every historical observation, but it can weaken the assumption that the recent pattern will continue unchanged. Explain what may have shifted and what evidence is available before replacing the estimate.

Separate the baseline from the intervention

Keep the original baseline forecast as a reference, with its date and assumptions. Then describe the expected mechanisms of the new changes: more signups, different customer questions, altered product usage or fewer onboarding problems. These mechanisms can move demand in opposite directions.

Do not assign precise effects merely because the table has empty cells. The purpose is to make uncertainty explicit and identify which observations would be informative.

Offer scenarios with conditions

A useful candidate response may provide a baseline, a higher-demand case and a lower-demand case, each tied to stated assumptions. These are conditional planning scenarios, not measured probabilities unless the evidence supports that interpretation.

Explain what would move the team from one scenario toward another. For example, a sustained increase in relevant contacts after the launch could justify revising the near-term workload estimate. A brief spike caused by a one-time announcement may call for a temporary response rather than a permanent new baseline.

Avoid presenting a narrow range simply to appear confident. A wider honest range can support better contingency planning when the underlying change is substantial. The decision maker needs to know which uncertainty matters to staffing, not just receive a more precise-looking number.

Define an update rule before the results arrive

Choose a review cadence and the evidence that will trigger reconsideration. That might include new arrivals, contact reasons, handling effort and backlog age. Ticket count alone may not represent workload if the new questions take longer to resolve.

Record revisions with the information available at the time. Do not overwrite the original forecast and later judge yourself only against the latest version. Keeping versions allows the team to distinguish reasonable updates from retrospective explanations.

Also preserve the metric definition. If the support system begins counting automated responses as tickets, an apparent demand change may be an instrumentation change. Check comparability before attributing the movement to pricing or onboarding.

Evaluate error in relation to the decision

An overestimate and an underestimate may have different consequences. Overstaffing consumes resources; understaffing may leave users waiting and increase backlog. Discuss those costs with the decision owner rather than choosing a metric without considering the use case.

Do not imply that a single accuracy measure proves the forecast is useful. Review whether it supported the decision, whether the uncertainty range was informative and whether the update process reacted appropriately to new evidence.

Our AI system design guide can help connect model outputs to the decisions people make from them. The forecasting method is only one part of that system.

Keep planned intervention and observed response separate in the forecast record. If the launch is delayed, the scenario based on that launch should change even before new ticket data arrives. This is an assumption update, not proof that the original statistical method failed. Explain the revised timing and its effect on the decision horizon.

Rehearse a misleading early signal

Ask a practice partner to reveal that the first two days show a sharp increase, but most contacts concern a temporary announcement error. Explain why you would investigate the cause before extrapolating that rate through the entire period.

Then change the facts: the new customer mix consistently needs more involved support. Describe how that evidence affects both expected arrivals and handling workload. Updating one number may be insufficient if the operational task has changed.

Finish with the baseline, scenario assumptions, update rule and contingency action. In a mock interview session, assess whether you distinguish observed data from hypothesised mechanisms. A strong answer does not defend an outdated forecast for consistency or replace it with an unsupported guess; it gives the business a transparent way to act while learning.