How big does a contact centre need to be before it needs WFM software?

Size is a poor guide. A 25-seat centre with three skills, part-time contracts and a service level target will outgrow a spreadsheet before an 80-seat centre with one queue and fixed shifts. The better test is the number of decisions the planner has to remake every week by hand, and whether anyone can check them.

Can I keep the spreadsheet for forecasting and use software only for rostering?

Yes, and it is a sensible first step: the forecast is where most planners have the most invested and the roster is where the spreadsheet hurts most. The catch is that the requirement has to travel from one to the other every week, so the tool you pick should accept a requirement or a forecast as an import rather than insist on producing its own.

When a spreadsheet stops being enough for workforce planning

A spreadsheet is the right tool for workforce planning in a small contact centre. It is free, everyone can read it, and every number in it can be traced to a cell. Most planners built their first staffing model in one, and many of the calculators on this site are the same formulas you would put in it. The question is not whether spreadsheets are bad. It is how to tell when yours has stopped being a tool and become a job.

What a spreadsheet does well

One queue, one week, one planner. A single forecast column, an Erlang column beside it, shrinkage at the bottom, a shift grid on another tab. It is transparent and it works.
Thinking. A spreadsheet is where you try an idea: what if handle time drops ten per cent, what if we open an hour later. The what-if is a copy of the tab, and that is fine while there are few of them.
Explaining. Finance understands a spreadsheet. A requirement that can be walked through cell by cell is a requirement that gets approved.

Nothing below argues for giving those up. It argues for noticing when the spreadsheet is no longer doing them.

The signs

1. The requirement is right and the roster is wrong. The Erlang maths is easy to get right; fitting shifts to a curve by hand is not. If your roster’s schedule efficiency sits below 85 per cent and moving a shift to fix one interval breaks another, the spreadsheet has become a manual optimiser, and people are slow optimisers.

2. Every week starts with copying last week. Copy the tab, rename it, paste the new forecast, fix the formulas that broke, re-enter the leave. If the first hour of the planning week is maintenance, the model is costing you the time it was meant to save.

3. More than one skill. Two queues sharing agents means the requirement for each depends on how the other is doing. A spreadsheet can hold two Erlang columns; it cannot easily model an agent who takes both, and the usual workaround, a fixed split, is wrong every time volumes move.

4. Shrinkage is a single number. Breaks and coaching cluster mid-morning and mid-afternoon; leave peaks in August. A flat 30 per cent overstaffs the quiet intervals and understaffs the busy ones. Modelling shrinkage by interval and by week in a spreadsheet is possible and nobody does it, because the sheet becomes unreadable.

5. Agents cannot see or change anything. Swaps, leave requests, preferences and overtime all arrive as messages to the planner, who edits the sheet. Each one is a small change and a chance to break a formula. Self-service is not a luxury feature; it is how the planner stops being the bottleneck.

6. Nobody can check it. There is one copy, one person who understands it, and a set of unwritten rules about which cells not to touch. When that person is on leave, the roster is whatever was published last.

7. Versions have disappeared. Which forecast was the roster built on? What did the requirement say before the change on Tuesday? A spreadsheet overwrites its own history unless someone maintains a naming convention, and conventions do not survive a busy week.

8. The forecast is a copy of last year. Not a sign of the spreadsheet failing, but of the time it consumes: when the planning week is spent on the roster, the forecast gets the leftovers.

If three or more of these are familiar, the spreadsheet is no longer the cheap option. It is the expensive one; the cost is just spread across the week where nobody adds it up.

What breaks first

The order is fairly consistent. The roster goes first, because fitting shifts to a curve is the part a spreadsheet was never designed for. Then the intraday: the sheet can say what should happen at eleven, but not what is happening at eleven, so re-planning during the day is guesswork. Then versioning and audit, which nobody notices until an argument about what was agreed. The forecast goes last; it is usually the best part of the model, and it is also the part that ports most easily.

Try the size of the job

The planner below is what your requirement tab does, for one day. It is quick here; the work is doing it for every day, with the real forecast, and then building shifts that cover the curve.

Inputs

Requirement curve

FTE at roster efficiency

65.9

90% of rostered hours land on the curve.

On the phones
Shrinkage allowance

Theoretical FTE: 59.3
Agent-hours per week: 2,225.0 h
Agent-hours per day: 445.0 h
Peak interval: 53 at 11:00
Average scheduled: 37.1
Contacts per day: 3,000

Show the working

3000 contacts per day is the average open day: 15000 a week across 5 open days, spread over 8:00 to 20:00 in 30-minute intervals using the "Morning and afternoon peaks" shape.
The day-of-week split is even, so every open day carries 3000 contacts.
Each interval runs Erlang C for 80% within 20 s, adds agents until occupancy is at or below 85%, then divides by (1 − 30%) and rounds up.
Mon's peak is 11:00: 187 contacts need 37 on the phones and 53 scheduled.
Agent-hours per day = Σ scheduled × 30 ÷ 60 = 445.0 h; × 5 days = 2225.0 h a week.
FTE = 2225.0 ÷ 37.5 contracted hours = 59.3. Shrinkage is already in the per-interval numbers, so contracted hours are the right divisor.
At 90% roster efficiency, 59.3 ÷ 0.90 = 65.9 FTE to cover the curve with real shifts.

This is one typical day. Pebble WFM does every day from your forecast, then builds and publishes the roster. Free month, no card needed.

What to do about it

Do not throw the spreadsheet away. Keep it as the check. Any tool you bring in should reproduce its requirement for a week you already know, before you trust it with a week you do not.
Move the roster first. It is the part that hurts most and the part a tool improves most. Feed it the requirement from the spreadsheet if that is where the forecast lives.
Insist on a requirement you can read. A tool that produces a roster without showing the requirement per interval has removed the one thing the spreadsheet did well. Every number should still be traceable.
Get agents into it early. Self-service for swaps and leave removes more planner hours than any forecasting improvement, and it is the change agents notice.
Start with a sample. Pebble WFM opens with a populated sample organisation, so you can see the forecast, requirement and roster working before you load your own data. That is the fair comparison with the spreadsheet: not a feature list, but the same week, done both ways.

Where next

How to calculate FTE from contact volume: the calculation your requirement tab is doing.
How to measure schedule efficiency: the test that tells you whether the roster is the problem.