WFM guideTechnology

WFM platform implementation guide

Q: What data do you need before implementing a WFM system?

Before a WFM platform can produce reliable output, you need: (1) Interval-level ACD data — volume offered and handled, and AHT, at 15- or 30-minute intervals, for at minimum 12 months (24 months preferred to capture seasonal patterns). This data must be at interval level — daily or hourly aggregates are not sufficient for Erlang C calculations; (2) Agent-level data — each agent's contracted hours, shift eligibility, skill profile, and employment start date. This typically comes from the HR or payroll system; (3) Historical shrinkage data — absence rates, training hours, meeting time, and other planned non-available time, ideally at team and agent level; (4) Contact type taxonomy — the wrap code or contact classification system must be clean enough to produce a stable mix calculation. If 30% of contacts are coded 'Other', forecasting by contact type is not feasible; (5) Service level targets — the SL target that the WFM system should plan toward, by queue and interval.

Q: How long does a WFM system implementation take?

A WFM implementation for a medium-sized contact centre (100–500 agents) typically takes 4–9 months from contract signature to full deployment: (1) Discovery and data preparation — 4–8 weeks. ACD data extraction, data quality assessment, agent data collection, initial configuration of queues and skill profiles. (2) Configuration and testing — 6–10 weeks. Platform configuration, forecasting model setup, schedule generation testing, integration with ACD and HR. (3) Parallel running / pilot — 4–8 weeks. WFM platform runs alongside existing scheduling process for one or more teams. Discrepancies between platform output and actual schedules are investigated and configuration adjusted. (4) Full deployment — 4–8 weeks. Remaining teams migrated, planners trained, agent self-service (if configured) enabled. Typical total: 18–34 weeks. Complex operations with multiple contact types, multi-site, or multiple ACD platforms take longer. The most common timeline overrun is in the data preparation phase — interval-level ACD data is frequently not available in the format the WFM platform requires.

WFM implementations fail for predictable reasons: interval-level ACD data does not exist, agent skills data is incomplete, the planning team was not involved in configuration, and the schedule that the platform generates does not match what the operation actually does. None of these are vendor failures. They are preparation failures.

Data requirements before implementation

Interval-level ACD data (contacts offered, handled, AHT)

12 months minimum; 24 months preferred

Why it matters: Forecasting requires sufficient historical data to model day-of-week, time-of-day, and seasonal patterns. 12 months captures one full seasonal cycle. 24 months allows the algorithm to separate trend from seasonal variation.

Common gotcha: Daily or hourly aggregates are not sufficient. WFM platforms require 15- or 30-minute interval data. If your ACD only retains 30-day interval history, you need to extract and preserve data before implementation begins.

Agent-level data (contracted hours, skills, start date)

Current snapshot for all active agents

Why it matters: Scheduling requires knowing each agent's contracted hours, eligibility for shift types (overnight, weekends), and skill profile. Erlang C routing requires skill coverage by skill group.

Common gotcha: Agent data is frequently incomplete or inconsistent in HR systems. Skill profiles are often held in a spreadsheet outside the HR system and are not maintained. Plan 2–4 weeks for data cleansing before this can be loaded into the WFM platform.

Historical shrinkage data

12 months at team level; agent level preferred

Why it matters: Shrinkage assumptions must be grounded in historical data rather than estimated. Using an incorrect shrinkage assumption inflates or deflates the headcount requirement that the WFM platform plans to.

Common gotcha: Most operations do not have granular shrinkage tracking — they track absence but not internal meetings, coaching time, or system down-time at agent level. An absence-only shrinkage assumption will understate true shrinkage by 5–10pp.

Contact classification / wrap code taxonomy

Clean enough to produce reliable contact mix

Why it matters: WFM forecasting by contact type requires a stable taxonomy. If the mix is substantially unknown ('Other' >20%) or unstable (codes recently changed), mix-based forecasting cannot be reliable.

Common gotcha: WFM vendors typically recommend redesigning the wrap code scheme as a prerequisite to implementation. This is correct — but it adds 4–8 weeks to the data preparation phase and requires agent retraining.

Service level targets by queue

Agreed targets for each queue the WFM platform will plan

Why it matters: The WFM algorithm plans headcount to meet a defined SL target. Without a target, the algorithm has no objective to optimise toward.

Common gotcha: Operations often have informal SL targets that differ from what is formally documented. Ensure the agreed target in the WFM platform matches operational expectation — a mismatch between planned SL and reported SL will create credibility problems for the WFM team from day one.

Implementation phases and typical durations

Phase	Typical duration (100–500 agents)	Key activities	Common delay cause
1. Discovery and data prep	4–8 weeks	ACD data extraction and quality assessment; agent data collection; wrap code review; SL target agreement; skill profile design; initial queue configuration	ACD data not in required format (interval level unavailable); agent data inconsistencies; skill profile missing or outdated
2. Configuration and integration	6–10 weeks	WFM platform configuration: queues, skills, shift types, shrinkage parameters; ACD real-time integration (for adherence monitoring); HR/payroll system integration (agent contracts, absence data); SL model setup and calibration	ACD integration API issues; HR system does not have the right data fields; vendor configuration timeline overruns
3. Pilot (parallel running)	4–8 weeks	WFM platform runs alongside existing scheduling process for 1–2 pilot teams; schedule from platform compared to actual schedule; discrepancies investigated; configuration adjusted; planner feedback collected	Discrepancy investigation takes longer than expected; pilot team atypical (recently formed or unusual contact mix); planners lack time for parallel operations
4. Full deployment	4–8 weeks	Remaining teams migrated; planners trained; agent self-service portal (if included) enabled; real-time adherence dashboards deployed; management reporting connected; legacy scheduling tools decommissioned	Planner training insufficient; agents unfamiliar with self-service portal; management dissatisfied with report design

Total typical duration: 18–34 weeks. Complex multi-site or multi-ACD operations take longer. The most common overrun is in Phase 1 — interval-level ACD data is frequently not available in the required format, adding 4–8 weeks for data engineering.

Four common WFM implementation failures

Inadequate planning team involvement in configuration

How it happens: The IT team or the vendor configures the WFM platform based on a requirements document written without the planners who will use it daily. The scheduling rules, shift types, and SL parameters are configured correctly per the spec — but the spec does not reflect how the operation actually works.

Consequence: Planners override the system daily. The WFM platform becomes a reporting tool rather than a scheduling engine. Planners revert to spreadsheets within 3 months.

Fix: Planners must be in every configuration session. The acid test: the planner who will use the system daily should sign off on every scheduling rule before it goes live.

Assuming the system will fix the underlying data problems

How it happens: The organisation knows its ACD data is incomplete or its wrap codes are inconsistent. The expectation is that the WFM platform will aggregate and normalise the data, producing reliable forecasts despite poor inputs.

Consequence: Garbage in, garbage out. The WFM platform generates schedules based on incorrect historical data — producing staffing levels that are wrong in a way that is difficult to diagnose because the numbers look plausible.

Fix: Fix data quality before implementation. An implementation delayed by 8 weeks for data cleansing produces better outcomes than an on-time implementation built on bad data.

No change management for agents

How it happens: Agents transition from a known schedule (produced by a planner they can talk to) to a system-generated schedule without explanation of how it works. Preferences submitted online appear to be ignored. Agents lose faith in the system and escalate every schedule query to TLs.

Consequence: TL time is consumed by schedule queries. Agent satisfaction with scheduling drops. The WFM team is perceived as having made things worse.

Fix: Agent communication programme before deployment: how does the algorithm work, how are preferences used, what is the escalation path for concerns. Publish the rules — agents who understand the system trust it more than agents who do not.

Big-bang deployment without pilot

How it happens: The implementation skips the parallel running phase to meet a go-live deadline. All teams are migrated at once.

Consequence: Configuration errors that would have been caught in a 4-week pilot with 1–2 teams affect the entire operation simultaneously. The WFM team is managing a system crisis while also running the operation.

Fix: Pilot phase is mandatory, not optional. Start with the most 'average' team — not the most complex or the most simple. Plan for the pilot to surface configuration changes that delay full deployment.

WFM implementation questions

What data do you need before implementing a WFM system?

Five data requirements: (1) Interval-level ACD data at 15 or 30 minutes, minimum 12 months; (2) Agent-level data (contracted hours, skills, start dates) from HR/payroll; (3) Historical shrinkage data — absence plus internal non-available time; (4) Clean contact classification taxonomy — 'Other' above 20% makes mix-based forecasting unreliable; (5) Agreed SL targets by queue. Daily aggregates are not sufficient — interval level is required for Erlang C calculations.

How long does a WFM system implementation take?

18–34 weeks for a medium CC (100–500 agents): Phase 1 discovery/data prep 4–8 weeks; Phase 2 configuration/integration 6–10 weeks; Phase 3 pilot/parallel running 4–8 weeks; Phase 4 full deployment 4–8 weeks. The most common overrun is Phase 1 when interval-level ACD data is not in the required format, adding 4–8 weeks for data engineering. Multi-site or multi-ACD operations take longer.