Planning support for quarterly spikes starts with one realisation: a spike you can predict isn’t a surprise, it’s a calendar. At Q4, our busiest periods followed public companies’ earnings seasons, and that meant I could staff, train and communicate months ahead, if I treated the earnings calendar as the forecast it was.
I’ve been running Client Support at Q4 for a few months now, and the pattern I mentioned in my first weeks learning the industry has become the organising idea of my planning. Our customers are the investor relations teams of public companies. Public companies report results every quarter, on dates that are announced in advance. Around each of those dates, the volume and the urgency of what lands on my team rise together, and between them it falls back. Coming from live entertainment, where on-sale demand arrived on a schedule I could guess but not control, a published calendar feels like a luxury.
Why do earnings seasons create support spikes?
Because everything an IR team does is organised around a release. Before an earnings date, they update their sites, prepare documents, check presentations, schedule events and make sure the information that goes live matches the information that goes to the market. Each of those tasks can generate a request to the support team, and they all have the same deadline. The result isn’t a smooth curve. It’s a rush that builds before the date and drops sharply after it.
Many customers report in the same weeks. That’s the part that makes capacity planning difficult. If your customers’ deadlines were spread evenly through the year, you’d staff for the average and be fine. When a large share of them cluster into a few weeks, the average is useless. You can have a team that looks over-resourced for ten weeks and badly short for three, and a manager who looks at annual headcount against annual volume will draw the wrong conclusion in both directions.
I’d met a version of this before. At AudienceView, I launched a capacity planning initiative and staffing model for high-volume on-sale events, where a single event could bring a rush of contacts in a very short window. The shape was different. The principle was identical: peaks are a design input, not an emergency.
How do you build a forecast around a published calendar?
Start with the history you already have. Pull your ticket volumes by day for the last several quarters and lay them against the dates that mattered. You’ll usually find the shape in an afternoon. The ramp-up begins before the date, the peak sits around it and there’s a tail afterwards while customers finish what they started. Once you can see the shape for the past, you can lay it over the dates in the coming quarter.
Then adjust for what’s changed. A customer who’s grown, a new product, a new type of request: each shifts the baseline. Ask the account managers what they know about the customers’ plans. They often have information that never reaches a ticket queue, such as a company planning an investor day or changing its reporting approach. That conversation takes an hour and saves weeks of surprise.
The staffing arithmetic is the same arithmetic I wrote about in Erlang C scheduling for call centres, applied to a different kind of work. You estimate how much work arrives in each period, how long it takes and how quickly you want to respond, and you work out how many people that needs. For technical support requests that take developers time to complete, the unit isn’t a phone call. It’s an hour of skilled work. But the question is identical: how many hours of capacity do I need in this window, and how many do I have?
Don’t expect the forecast to be right to the hour. Its job is to be wrong in a useful direction. A forecast that’s a little high gives you spare capacity to spend on improvement work. A forecast that’s low gives you a crisis. When you’re unsure, lean towards the first, and say so openly, so nobody mistakes the extra capacity for slack.
What can you do beyond hiring more people?
Quite a lot, and it’s cheaper. Hiring for a peak you’ll only see four times a year leaves you with people to pay for in the quiet weeks, and new hires take time to become useful. Flex is the better answer, in several forms.
First, move the work that doesn’t have to happen in the peak. Project work, training, documentation and improvement tasks can wait for the quiet weeks, and the team should know that’s the deal. A team that understands “we’ll be flat out in these three weeks and we’ll use the rest to fix things” works differently from one that’s simply always busy.
Second, cross-train. If Tier 1 can handle a wider range of requests in peak weeks, Tier 2 and Tier 3 can concentrate on the hard cases. That needs a skills matrix and honest assessments of who can do what, the kind of structure I built at AudienceView and describe in the AudienceView University case study.
Third, spread the load geographically. A team across several time zones can cover a longer working day, and a peak that falls on one deadline can be handed from region to region. I’ve used the same idea before, in the follow-the-sun model at Tyco, and I’ll write separately about how it shaped my thinking on nearshore staffing.
Fourth, talk to customers early. If you know a company reports in two weeks, you can ask what they’ll need and when. Requests that arrive a week before the deadline are easier than ones that arrive on the day. A short message to your key customers a few weeks ahead of the season, asking them to send known work early, moves a surprising amount of demand out of the peak.
How do you protect the team during the peak?
By being honest about what the peak is and giving it a boundary. A team that’s told “this is three weeks, here’s the plan and here’s what happens afterwards” can sustain a hard stretch. A team with no end date can’t. I make a point of marking the end of every peak: a short note of thanks, a look at what we learned and a visible pause in the work before the next quarter’s planning starts.
Watch for overtime that becomes the default. If the same people are stretched every season, the pattern is a staffing problem hiding behind goodwill. Track hours, not just tickets, and look at who is carrying the load. And make sure nobody’s calendar is so packed in the run-up that they can’t take a day off. The people who work hardest in peak weeks are the ones most at risk of leaving afterwards.
Keep the communication tight. During a peak, short, regular updates to the team and to the account managers beat long ones. Everyone should know the queue status, the biggest risks and who to go to when something is stuck. It’s the same principle as the daily check-ins I use with remote teams, and I covered it in managing remote support staff.
What do you do with the quiet weeks?
Use them on purpose. The quiet weeks between peaks are where the next peak is made easier. That’s when you retrain, fix the recurring problems that caused extra work last quarter, update documentation, test new tooling and talk to customers about what they need. A team that treats the quiet weeks as downtime will meet the next peak unprepared. One that treats them as preparation will find the same peak a bit less hard each time.
It also helps to measure the cycle, not just the quarter. Compare one peak with the last, in terms of volume, response time and how often work needed to be redone. A series of peaks gives you the closest thing to a controlled experiment you’ll get in operations. If response time in the third peak is better than in the first, you can look at what changed. If it isn’t, you know where to look next.
A final practical point: write the calendar down and share it. A simple page listing the expected peak windows for the next two quarters, which customers are likely to drive them and what the team will and won’t be working on, answers a surprising number of questions before they’re asked. It also turns the forecast into a commitment the business can see, which makes it easier to ask for help when a peak looks larger than expected.
A predictable spike is a gift if you plan for it. A published calendar is the closest a support manager gets to knowing the future.
Hutch Morzaria is a Director-level CX and Support Leadership professional with 19 years of experience building global support organizations across SaaS, Fintech, and enterprise technology. He has hired dozens of support and CX leaders across his career and holds ITIL Expert certification across V3 and V4.
