Want help applying this guide?Ask the DripTell team
A workforce planner opens the familiar Microsoft Customer Service forecast on Monday and expects to use it for next month's roster. This time the problem is not a bad forecast. The feature itself is going away.
Microsoft says support for forecasting case and conversation volumes, plus forecasts for customer service representatives handling conversations, ends on October 30, 2026. The feature will be removed after that date. The practical response is to preserve the evidence behind today's forecasts, rebuild the same operating scope in Workforce Management, run both methods on identical demand, and switch only after a named owner accepts the differences.
Confirm What Microsoft Is Removing
Read the product boundary before planning the migration. Microsoft's official deprecation notice names forecasting in Dynamics 365 Customer Service. It does not say that your historical customer demand disappears, nor does it validate a new forecast for you. It says the old feature loses support on October 30 and will be removed afterward. Microsoft recommends forecast scenarios in workforce engagement management.
Start by listing every forecast the team still uses. Separate case volume, conversation volume, and representative demand. Note the channel, queue, time zone, interval, historical window, exclusions, holiday treatment, and the person who turns the result into a decision. This inventory belongs beside your support operating model, because a report without a decision owner is only an output.
Do not treat the deadline as permission to replace definitions silently. A conversation may mean an offered session in one report and an engaged interaction in another. Average handle time may exclude work your planners previously included. Write the current definitions before configuring anything new.
Freeze the Evidence Before Rebuilding
Export or otherwise preserve the inputs and outputs you are entitled to retain under your organization's policy. Keep enough closed periods to reproduce a recent forecast, the actual results for those periods, and the assumptions used for events, backlog, operating hours, shrinkage, and concurrency. Record the forecast version and the decision it supported.
- Name the scopeList each case or conversation forecast, channel, queue, interval, time zone, and owner.
- Preserve the baselineKeep historical inputs, exclusions, forecast outputs, actuals, and the decisions they supported.
- Rebuild deliberatelyCreate separate scenarios for work that has different demand patterns or handling effort.
- Run in parallelFeed old and new methods the same closed period and compare errors by interval and queue.
- Approve the switchRecord acceptance, unresolved differences, rollback evidence, and the owner of the next review.
Preserve exceptions too. A product launch, outage, holiday, or queue redesign can make one period unrepresentative. If that context lives only in a planner's memory, the replacement model may look cleaner while becoming less truthful. Store migration evidence under the same access rules as other customer and workforce data. Your security controls should limit who can view employee analytics and conversation history.
Microsoft's forecast scenario guidance also warns that forecasting is not intended for employment decisions and must be used under applicable laws. Keep a human review between the model and any staffing action.
Rebuild Scope Before You Tune the Model
The replacement workflow lets a planner choose Conversation or Case, then select channels and queues. Short-term scenarios use an intraday interval for up to 42 days. Long-term scenarios use a daily interval for up to 1,095 days. Both forecast volume and average handle time from historical data.
Those settings are not clerical. They define what the forecast means. Rebuild one scope at a time. Keep queues separate when skills, service promises, handling effort, or opening hours differ. Keep the time zone explicit. If an external data source is used, note that Microsoft says automatic refresh is unavailable for that source. Decide who owns each manual upload and what happens when it is late.
| Migration gate | Evidence to compare | Stop the cutover when |
|---|---|---|
| Scope | Cases or conversations, channels, queues, time zone | Old and new populations do not match |
| History | Included dates, exclusions, holidays, backlog | A material exception is missing |
| Output | Volume and handle time by interval | Differences cannot be explained |
| Operations | Capacity, schedule, and queue decision | The same forecast leads to a different unowned action |
| Governance | Access, owner, job history, rollback copy | Nobody owns failure or review |
Use CRM context to explain known changes in customer mix, not to hide them inside an adjustment. Use automation to make repeatable data steps visible, not to skip review.
Run Old and New Forecasts in Parallel
Choose a closed historical period first. Give both methods the same eligible work, date range, time zone, queue map, and known-event treatment. Compare total volume, but also compare interval shape, queue-level error, handle-time assumptions, and the staffing decision that follows. A small total difference can still hide a serious midday gap.
Then run one live planning cycle in parallel before October 30. Keep the old forecast as the reference, not as automatic truth. If the new scenario performs differently, locate the first changed definition or input. Microsoft's scenario workflow provides output snapshots and job history. Preserve the accepted snapshot and note which run informed capacity planning.
The shared inbox can help an operations team observe queue ownership and actual demand while it checks the forecast. The forecast still needs an accountable planner. Software visibility does not replace acceptance criteria.
Switch With an Acceptance Record
Approve the cutover only when the team can reproduce the population, explain material differences, see successful jobs, and turn the output into a workable plan. Record the accepted scenario, its source data, the comparison period, open limitations, access owner, and rollback evidence. Do not delete the old exports as soon as the new screen looks right.
After switching, schedule a short review after the first complete cycle. Compare forecast with actual demand and the capacity decision. Keep forecast error separate from schedule adherence or individual performance. AI assistance may help classify or summarize operational evidence, but it should not silently change scope or decide employment outcomes.
A reliable migration is not a perfect match between two charts. It is a documented change where the team still understands what was counted, why the result moved, who approved it, and what to do when the next run fails.
Frequently Asked Questions
When will Microsoft remove Customer Service forecasting
Microsoft says support ends on October 30, 2026, after which the forecasting feature will be removed. Plan and validate the replacement before that date.
Should the new forecast match the old one exactly
No. It should use an equivalent scope and every material difference should be explainable. A different method may produce a different result, but the team must know whether the change came from data, definitions, intervals, or the model.
How long should a parallel run last
Complete at least one real planning cycle that includes normal operating variation. Higher-risk teams should compare more than one closed period and one live cycle before cutover.
DripTell Editorial
Practical guidance reviewed by the DripTell product and customer workflow team.
See how DripTell checks product claims, uses primary sources and handles corrections.
Editorial and source policy