Forecasting method: Prophet

Forecasting · ~6 minute read

The library that made decomposition mainstream

Prophet is an open-source forecasting library released by Meta (then Facebook) in 2017. It is not the most accurate forecasting method in absolute terms — it loses to well-tuned ARIMA, ETS, and gradient-boosted regressors on benchmarks — but it has become widely adopted because it is approachable, robust to messy data, easy to add holidays and known events to, and good enough on most business time-series. For workforce planners who do not have a statistical specialist on the team, Prophet is often the quickest route from spreadsheet-era forecasting to something materially more capable. This article walks through what Prophet is, what makes it different, where it fits in a contact centre context, and the pitfalls to know.

What Prophet actually is

Prophet decomposes a time series into three components: trend (the underlying long-term direction), seasonality (recurring patterns of various periods), and holiday or event effects (specific dates that materially shift the level). The trend is modelled with a piecewise linear or logistic curve that can change direction at automatically detected change-points. Seasonality is modelled with Fourier series, which lets multiple seasonalities (weekly and yearly, say) be fitted simultaneously without manual configuration. Holidays are explicit one-off effects that can be added by name from a country-specific calendar or a custom list.

The model is fitted as a Bayesian generalised additive model. In practice, the planner only sees the API: feed in a dataframe with date and value columns, specify the country’s holiday calendar, optionally add custom regressors, and get back a forecast with confidence intervals.

What it does well

Three properties consistently make Prophet useful in a contact centre context.

Multiple seasonalities out of the box. Most queues have a weekly pattern; many also have monthly billing-cycle effects or annual seasonality. Classical Holt-Winters handles one seasonal period at a time; Prophet handles all of them simultaneously by default. For queues with overlapping patterns this is a meaningful advantage.

Holiday handling. Bank holidays, school holidays, religious calendars — all available as named events. The planner can also add custom events (a marketing campaign, a product launch, a system outage). Each event becomes a fitted coefficient the model uses on future occurrences. This is the feature that often justifies the move to Prophet on its own.

Robustness to messy data. Prophet handles missing values, outliers, and trend changes more gracefully than most alternatives. A queue with intermittent data, occasional system-issue spikes, or a clear structural break partway through history will produce a more sensible Prophet forecast than a less robust method.

Where it falls short

Three weaknesses are worth knowing. Accuracy is decent but not exceptional. On clean weekly-seasonal data, a well-tuned Holt-Winters typically matches or beats Prophet. On data with multiple seasonalities or messy structure, Prophet usually wins. The choice depends on the data.

Sub-daily forecasting is not Prophet’s natural fit. The library handles hourly or sub-hourly data, but the seasonal Fourier components can struggle with the strong intraday peaks contact centres exhibit. For interval-level forecasting, Prophet is usually run at daily grain to predict daily volume, with intraday profiles overlaid separately.

Pure trend extrapolation can mislead. Prophet’s piecewise-linear trend can over-shoot or under-shoot on series that have flattened or are about to. A planner using Prophet should always inspect the forecast visually rather than trust the output blind; obvious problems are easy to catch and easy to fix.

Practical setup for contact centre data

A practical Prophet setup that consistently works in a contact centre looks like this. Use daily data (not interval) for the volume target. Fit Prophet with weekly seasonality on and yearly seasonality on (the defaults). Add the country’s public holidays via the built-in list. Add any custom events the operation knows about — marketing campaigns, billing dates, regulatory deadlines — as explicit holidays with their dates and a tunable window of effect (e.g. the effect extends two days before and one day after the campaign send).

For drivers that vary continuously rather than as discrete events (temperature, marketing email volume, social-media sentiment), use add_regressor() to include them. The model will fit a coefficient for each regressor, and you can then forecast forward by providing the regressor values for the forecast horizon. This is where Prophet starts to overlap with the regression-with-drivers approach — the underlying method is the same, just wrapped in a more approachable API.

Tuning the parameters that matter

Most Prophet defaults work reasonably out of the box, but two parameters consistently reward tuning. changepoint_prior_scale controls how willing the model is to detect trend changes. Higher values let the trend bend more flexibly (good for fast-changing operations); lower values produce a stiffer, more conservative trend (good for stable operations and for avoiding over-fitting). Most contact centre work sits in the 0.01–0.05 range — lower than the default of 0.05. seasonality_prior_scale controls how strongly the seasonal components are enforced. The default of 10 is usually fine, but on queues with very strong, very stable seasonality, raising it to 25 or 50 sometimes helps.

Combining Prophet with operational overrides

Prophet is a baseline-producing method. Like every statistical model, it benefits from a layer of operational overrides for events the planner knows about but the data has not yet seen. The clean workflow is to keep the Prophet baseline untouched (refit weekly or fortnightly on clean data) and to maintain an explicit override register that the planning team adds on top of the baseline before publishing the forecast. This separation makes it easy to see at any time which part of the published number comes from the model and which part comes from human judgement.

Common mistakes

Three patterns recur. Using Prophet at sub-daily grain. The library can run on interval data, but the results are usually worse than running on daily data and then applying an intraday profile separately. Ignoring the changepoint_prior_scale parameter. The default makes the trend more flexible than most contact centre operations need; lowering it usually improves forecasts and certainly improves stability. Confusing the visual output for accuracy. Prophet’s default plots are attractive and the confidence intervals look impressively wide, but the calibration is often poor (intervals are too wide on some data and too narrow on other). Validate accuracy on held-out data, not by looking at the plot.

Conclusion

Prophet is a good default for planning teams that want something more capable than Holt-Winters without committing to the engineering investment of a full machine-learning pipeline. It handles multiple seasonalities, named events, and messy data gracefully, and it produces a forecast the planning team can iterate on quickly. It is not the most accurate method available, and on clean weekly-seasonal data it does not beat well-tuned alternatives. It is, however, often the most pragmatic upgrade path for a planning function ready to move beyond spreadsheets but not yet ready for a custom ML stack. Use it as a baseline, layer operational overrides on top, and benchmark it honestly against the alternatives before committing.

Pair this with exponential smoothing for the comparison baseline, and using AI for contact centre forecasting for the wider context.