Demand planning collaboration is the structured process by which sales, marketing, product, and finance contribute their domain knowledge, and demand planning consolidates those inputs into a single agreed demand plan that downstream functions execute against. It's the difference between a plan generated in isolation by a planner and one that reflects what the whole organisation knows.
Two words get used interchangeably that shouldn't be. The forecast is the statistical baseline derived from historical data. The demand plan is what results once sales, marketing, and finance input has been layered on top of that baseline. Collaboration doesn't rewrite the forecast. It builds the demand plan. Keeping that distinction clear is what makes it possible to later measure whether any given contributor's input helped or hurt.
The word “collaboration” carries some baggage. In many companies, demand planning collaboration has degenerated into a negotiation. Sales pushes the number up. Not to beat a quota: their sales target is a separate number from the operational forecast. It's to make sure the product is actually available when they need to sell it. Marketing pushes the number up too, typically optimistic around new launches. Finance tends to pull the other way, favouring a neutral or conservative number, especially at public companies wary of overstating future revenue. Real collaboration is not a negotiation. It's the structured exchange of information so the resulting demand plan is more accurate than any single contributor could produce alone.
This page explains what effective demand-planning collaboration looks like, the common failure modes, and the discipline that makes it work.
Horizon's collaboration model is built around the five principles. Each contributor has their own interface for adding overlays: sales see customer-level views, marketing sees promotion and launch views, with structured fields for SKU, time period, magnitude, and reason. Overlays are automatically tagged with the named owner.
Conflicts between overlays (e.g. sales add +500, marketing adds +800 to the same SKU) are surfaced as exceptions for demand planning to resolve. The consensus demand plan is owned by demand planning, with the contributing overlays preserved as an audit trail.
FVA is calculated per contributor and per overlay type, visible in a dashboard that each contributor can see for their own inputs. The system also flags overlays from a contributor whose FVA has been persistently negative, not to punish but to surface a conversation.
For companies that have been relying on unstructured collaboration (email, meetings, late adjustments), the transition to structured collaboration is as much a process change as a tool change. Most implementations include 2-4 weeks of process design alongside the system configuration.
Demand planners working alone, even with excellent tools, produce plans that are blind to information they cannot access. Sales reps know which customers are planning expansions, which are at risk, which have promised orders not yet entered. Marketing knows which promotions are landing, which launches are coming, which competitive shifts are affecting category demand. Product knows which discontinuations are imminent. Finance knows which budget assumptions changed.
None of this information is in the historical data. A forecast generated only from history will systematically miss it. The choice is not whether to collaborate. It's whether to collaborate in a structured way (with overlays, named owners, and reasons captured in the planning system) or in an unstructured way (emails, hallway conversations, and late-cycle adjustments that arrive after the plan is published).
In Horizon's experience working with demand planning teams, companies that collaborate well typically build demand plans that run noticeably more accurately than those that don't, on the same underlying statistical baseline, and even a few extra points of accuracy can meaningfully move inventory costs and revenue. Companies that collaborate poorly often perform worse than the statistical baseline alone: collaboration degrades the demand plan rather than improving it. The difference is process discipline.
The collaboration process starts with the system-generated statistical baseline: the forecast. Contributors add overlays on top to build the demand plan; they don't generate forecasts from scratch. This separates the unbiased machine forecast from human judgment, which makes FVA measurement possible later.
Each overlay has a named owner, a specific reason, and a clear scope. “Customer A confirmed expansion +500 units in Q3 Europe” is a valid overlay. “Sales feels Q3 looks soft” is not. The discipline matters because vague overlays cannot be evaluated for accuracy and cannot be reasoned about later when they prove wrong or right.
After collaboration, demand planning owns the consensus demand plan as a single number. Sales, marketing, and finance contribute to it but do not own it. This is the structural choice that prevents collaboration from degenerating into negotiation: there's no “sales number vs. planning number” to argue about; there's one demand plan with structured inputs.
When sales and the statistical baseline disagree on a SKU, the collaboration process should surface that disagreement, not hide it. The disagreement gets adjudicated based on data. What does sales know that's not in the history? Is the information specific enough to act on? The conversation is data-driven, not authority-driven.
Six months after the cycle, FVA measurement reveals which overlays improved accuracy and which destroyed it. Contributors see their own FVA: sales rep A's overlays improved accuracy on average, sales rep B's destroyed it. This feedback loop turns collaboration into a learning system rather than a recurring argument.
Forecast bias is a consistent, one-directional gap between the forecast and actual demand: not random error, but a systematic tendency to lean one way or the other.
Bias rarely comes from one bad actor. It comes from structural sources:
Bias is measured with metrics such as Mean Error (ME) or Mean Forecast Error (MFE), which indicate whether a forecast consistently over- or understates demand, distinct from accuracy metrics like MAPE or RMSE, which measure the magnitude of error regardless of direction. For a deeper look at how these metrics work together, see BCG X's overview of forecast evaluation metrics. FVA tells you whether an overlay improved the plan; bias tells you whether a contributor (or a model) is nudging it the same direction every time.
Without the “one number, owned by planning” principle, each function brings their own number, and the meeting becomes a debate about whose number wins. Symptoms: meetings run long, decisions get escalated, and the final demand plan reflects organisational pull rather than information. Sales pushes up for availability, finance pulls down for caution, with no data-driven resolution in between.
Sales submits “increase Q3 by 8%” rather than specific overlays per SKU/customer with reasons. The demand plan moves, but accountability evaporates. When Q3 misses, no one owns the adjustment because no one made a specific claim.
Without FVA, contributors don't see whether their overlays improved or hurt accuracy. The same overlay patterns repeat cycle after cycle. The team is collaborating but not learning.
Overlays arrive after the demand plan has been published downstream. Production has already committed schedules; procurement has already placed orders. The late overlay either gets ignored or forces costly replanning. Set a cutoff date and enforce it.
Most mature collaborative demand planning runs on a monthly cycle that feeds directly into the broader S&OP/IBP process:
Within this rhythm, FVA from prior cycles informs which overlays to weigh heavily and which to challenge.
