Planning coverage around your own demand: from gut feel to a roster that works

In most service teams the roster is built back to front. First you look at who's available, then you divide the hours as fairly as possible, and then you hope it works out. When customers actually get in touch barely features in that sequence.

The result is a pattern almost every team recognises. At some moments three people are waiting for work. At others the queue builds while one person is on duty. Total coverage may be exactly enough, but it's sitting on the wrong hours.

That's a waste, because this is one of the few improvements in customer service that costs nothing. You need no extra people and no new software, just an honest picture of when it's busy and the willingness to adjust the roster to it. This article shows how to build that picture and what to do with it.

Start with the simplest analysis there is: count incoming customer queries per hour of the day and per day of the week, over at least eight weeks. Not your handled queries, but your incoming ones, because that's what's coming at you regardless of whether you coped.

Almost every company discovers the same base pattern. Monday morning is the peak. The weekend leaves a tail that lands on Monday. There's a dip around lunch and a second peak late afternoon. But the details differ sharply per business, and the details are where the gains are. A webshop with many delivery questions peaks in the hours after the standard delivery round. A B2B supplier peaks at the start of the working day and is near silent after four.

Then split that profile per channel, because the patterns don't align. Phone is tightly bound to office hours and peaks sharply. Email arrives all day and has a heavy evening tail. Chat follows traffic on your site and therefore peaks along with your marketing and sales moments.

That distinction matters because it determines how tightly you must plan. A phone peak has to be absorbed in the hour itself, because those questions can't wait. An email peak can be spread across the day, as long as you meet the agreed response time. Roster both the same way and you are by definition wrongly staffed on one of them.

With the profile in hand the arithmetic is simple. Multiply the number of queries in an hour by average handling time and you know how many working minutes that hour produces. Twenty queries at an average of eight minutes is a hundred and sixty minutes of work, almost three full person-hours.

That isn't the same as rostering three people, though. Nobody spends sixty minutes of an hour on customer queries. There's discussion in between, and breaks, and a colleague with a question. On phone there's unavoidable waiting time between calls too. Calculate with seventy to seventy-five percent productive time and those hundred and sixty minutes need roughly four people, not three.

That gap is exactly where most rosters go wrong. Planning happens against paper capacity, and the moment anything goes against you the queue builds. That backlog then rolls into the next hour, which already has its own volume. This is how you get the familiar picture of a team still working through Monday on Thursday.

On asynchronous channels you can calculate a little more loosely, because work can shift within the day. On synchronous channels you can't: there the query is gone or angry if you're not present. So planning phone more generously than the arithmetic suggests isn't luxury, it's the only way to meet the promise.

The most common rostering mistake isn't too little coverage, it's too even coverage. Everyone from nine to five, the same number of people every day. That feels fair and is simple to build, but it runs directly counter to how customer queries arrive.

If Monday morning brings twice the queries of Friday afternoon and you staff both identically, you buy two problems at once. On Monday the wait is too long and work gets rushed, producing errors and reopened queries. On Friday capacity sits idle that you badly needed on Monday.

The fix isn't a complicated system but a roster with a wave in it. Weight on the peaks and thinner coverage in quiet hours. The lunchtime dip is used deliberately for meetings, training and updating your knowledge base. That work has to happen anyway and it's the only work that genuinely can wait.

The same principle applies across the week. If Monday is structurally your heaviest day, it shouldn't carry the same headcount as Wednesday. And holidays, public holidays and peak periods shouldn't arrive as a surprise: they're in the calendar months ahead and can therefore be planned for, provided somebody does it.

A waved roster does ask something in return from the organisation: early clarity. Varying shifts are perfectly workable as long as people know them well in advance and they're distributed fairly. Shifting things at the last minute is what wears teams down, not the fact that coverage differs by hour.

A roster is a forecast, and a forecast you never test doesn't improve. The test is simple: set your planned coverage per hour against actual volume and realised waiting time.

Two patterns are then interesting. Hours where waiting time rose despite plan-adequate staffing mean your handling time is higher than assumed or your productive room is smaller than thought. Hours with generous coverage and barely any volume mean your capacity sits at the wrong moment, not that you have too many people.

Also look at the link with quality. Does the share of reopened queries rise precisely in the busiest hours? Then understaffing is costing you money rather than saving it. Rushed queries come back and get paid for twice. Which other figures to track is worked out in our article on KPIs for modern customer service.

Revisit the demand profile every quarter. Do it certainly after any change affecting traffic: a campaign, a new channel, a changed delivery partner or an expanded assortment. Last year's profile is rarely still today's, and a roster running on outdated assumptions feels exactly like a roster made on gut feel.

In many smaller companies there's no separate service team. The same people handle customer contact, process orders and help in the warehouse. Any planning model assuming agents who only handle customer queries collapses immediately there.

What does work is thinking in blocks rather than in roles. Determine per part of the day who's responsible for customer contact and make sure that person doesn't have to do anything else in that block. An hour of full attention delivers more than a whole day of half-watching, because every switch between two kinds of work costs time and concentration.

Explicitly record who handles customer queries if whoever's on duty gets called away. In teams without that agreement customer contact is always the first thing to drop, because it's the only work nobody is standing next to waiting for. A query left for half a day because someone had to unload a pallet isn't an incident but a missing agreement.

For these teams the distinction between synchronous and asynchronous channels matters even more. Email fits blocks fine, phone doesn't: it needs someone reachable at that moment. That argues for limiting phone availability to the hours you can genuinely deliver, and routing the rest of the day to an asynchronous channel.

A roster calculated exactly against expected demand only holds on a day when nothing unusual happens. Those days exist, but they're rarer than plans assume.

There's always variation around the average. One Monday is busier than another. Illness arrives unannounced. And a single event on your side can lift a day's volume: a shipment gone wrong, or a campaign landing harder than expected. A plan without margin turns each of those events into a backlog.

The practical implementation is a small buffer at the peaks rather than even overstaffing. Put someone on customer contact during the morning peak and on other work the rest of the day. That's cheaper than an extra shift and covers exactly the moment where a shortfall hits hardest.

Also agree what you deliberately let slide when things go wrong. Which tasks move, which response time may temporarily stretch, and at what point do you actively inform customers about a longer wait? A team that has agreed this in advance loses half a day to a setback. A team improvising loses a week.