Status: Public Preview — behaviour may change.
What it does
Notifies supervisors when live conversation volume stays above forecast for a set number of intervals. A background monitor compares actual volume for the queues in a shift plan against the linked forecast plan and fires an in-app notification once the threshold and duration are both met. It's informational only — it doesn't reroute, restaff, or touch the published schedule.
Key facts
- Off by default. An admin enables it in Copilot Service admin center under Workforce management > Intraday management > Workforce alerts (preview); supervisors then create alerts in Copilot Service workspace
- Requires a published shift plan with a linked capacity plan and forecast — you can't alert on a manually built shift plan that has no linked capacity plan
- Only queues included in the linked capacity plan are monitored; add a queue and the monitor picks it up on a later run
- Alert config: Above forecast (%) (default 5), For duration (intervals) (default 1), expiration date (defaults to shift plan end), and notification recipients
- An interval is the smallest unit in the linked forecast — 15, 30, or 60 minutes — and duration counts consecutive intervals
- The monitor runs every five minutes; a notification can land up to one cycle after the interval that triggered it
- Alert details give an interval-by-interval breakdown (forecast, actual, % above, threshold met) plus spike size and detected time; an alert resolves when volume drops back under threshold for the configured number of intervals
- Turning the feature off retains existing alert definitions but stops new notifications and blocks edits
When to use / skip
Turn it on for clients running WFM forecasting who want supervisors nudged when a queue runs hot, without staring at real-time dashboards. Skip it if they've no published shift plan with a linked forecast — there's nothing for it to compare against — or if they expect it to do something about the spike. It only tells you.
Configuration decisions
- Threshold and duration together: too tight and supervisors get pinged on noise, too loose and the spike's half over before anyone hears. Start around the 25% / 2-interval mark the docs use as an example and tune from real traffic
- Who receives notifications — recipients are set per alert, so decide whether that's a fixed supervisor group or varies by shift plan
- Expiration handling: alerts stop evaluating after their expiration date, which defaults to the shift plan end, so someone owns renewing them for rolling plans
Gotchas
- It's advisory, full stop. Set that expectation with supervisors or they'll assume the system is handling the spike while it's only telling them about it.
- No linked capacity plan means no alert. A manually created shift plan won't work, and that catches people who built plans by hand.
- The five-minute cycle plus the consecutive-interval rule means this is for intraday awareness, not subminute detection. A single interval that dips below threshold restarts the count.
Consultant notes
- The prerequisite chain does the filtering for you: no published shift plan, no linked capacity plan, no alert. In scoping, confirm the client actually runs shift plans with linked forecasts before you promise this — plenty of contact centres have forecasting on but never publish shift plans, and for them the feature simply won't light up.
- Tuning is the whole game. The default 5% / 1-interval will bury supervisors in alerts on any busy queue; the useful settings are client-specific and only emerge from a week or two of real volume. Plan a tuning pass after go-live rather than shipping the defaults and walking away.
- It's preview, so don't build a client's escalation process around it yet. Behaviour and thresholds can change, and it's informational only — the response still lives with the supervisor, not the system.
Check this if: the feature graduates from preview, or the monitor cadence / prerequisites change in a release wave