Metric Definition
When contacts concentrate
Track from
Peak support hours analysis
Peak support hours analysis is the practice of measuring how inbound support contacts distribute across the hours of the day so you can find the windows where volume concentrates and queues build. It converts a flat daily contact total into an hourly arrival profile. That profile drives shift planning, service level forecasts, and agent coverage in a way a daily total never can.
7 min read
What is peak support hours analysis?
Peak support hours analysis is the practice of breaking the daily contact total down by hour to find when support demand concentrates and how steep that concentration is. Instead of knowing a desk took 800 contacts in a day, you learn that 160 of them landed between ten and eleven in the morning. The headline figure is the peak hour contact share, the proportion of a typical day that arrives in its single busiest hour.
The analysis matters because support is a queueing problem, and queues are driven by the peak, not the average. A desk open for ten hours that takes 800 contacts averages 80 an hour. A peak hour carrying 160 is double that. If staffing is set to the average, the peak hour produces long waits, breached service levels, and rising first response time, even though the day as a whole looks comfortably resourced.
Arrival patterns in support are rarely random. Contacts cluster after a product release ships, after a marketing email goes out, at the start of the business day across each time zone, and on Mondays after a quiet weekend. Peak support hours analysis surfaces these patterns so coverage can be planned against the hours that actually strain the team rather than against a flat daily figure.
Measure arrivals, not handled contacts, when building the peak profile. Handled volume is capped by how many agents are on shift, so it flattens the real peak and hides the gap between demand and coverage. The arrival curve, when contacts came in, is what staffing has to be planned against.
How to calculate peak support hours analysis
The core figure is the peak hour contact share: contacts in the busiest hour divided by total daily contacts. A desk that takes 600 contacts with 96 of them between nine and ten has a peak hour share of 16 per cent. That number tells you how front-loaded or lumpy the day is.
The share alone does not tell you whether you are covered. You also need the peak to average ratio, which compares the busiest hour to the typical hour, and the analysis has to be split by channel and day of week, because phone peaks, chat peaks, and email backlogs rarely sit at the same time. Build the hourly arrival profile first, then read these figures from it.
- 1
Hourly contact arrivals
Group every inbound contact by the hour it arrived, not the hour it was answered. This raw arrival profile is the foundation for every other figure.
- 2
Total daily contacts
Sum the hourly buckets across the operating day. This is the denominator for the peak hour share and the basis for the average hour.
- 3
Busiest hour contacts
Identify the single highest arrival bucket. This is the demand the team must be staffed to absorb without the queue running away.
- 4
Average hour contacts
Divide total daily contacts by operating hours. The busiest hour compared to this average gives the peak to average ratio, the truest measure of how concentrated demand is and how much extra cover the peak window needs.
Peak support hours analysis in a metric tree
A peak in contacts is a symptom of upstream events and a constraint set by coverage. A metric tree separates what causes the contacts to arrive from what determines whether the team can absorb them, so a sharpening peak points to a specific branch rather than a vague staffing worry.
Metric tree insight
The tree splits two questions support leaders constantly merge: are too many contacts arriving in the hour, or are too few agents covering it. A predictable post-release peak belongs on the arrival drivers branch and is best solved by deflection, while a recurring under-staffed peak belongs on the coverage branch and is solved by shift design. KPI Tree assigns RACI ownership to each branch, so the email send schedule sits with marketing and the shift coverage node sits with support operations, and a peak that breaches service level pushes the alert to the owner who can act.
Peak support hours analysis benchmarks
There is no single correct peak hour contact share, because it depends on how concentrated your customer base is in time. A desk serving one country and one time zone peaks far harder than a global desk whose arrivals are spread across the clock. The ranges below give realistic peak hour shares for common support models, measured against a typical operating day.
| Support model | Spread profile | Typical peak share | Sharp peak |
|---|---|---|---|
| Single time zone B2B desk | 11 to 14 per cent | 15 to 20 per cent | 24+ per cent |
| Consumer phone support | 12 to 15 per cent | 17 to 22 per cent | 28+ per cent |
| Global multi-region desk | 7 to 9 per cent | 10 to 13 per cent | 16+ per cent |
| Async ticket and email | 9 to 12 per cent | 13 to 17 per cent | 20+ per cent |
Benchmark the peak per channel, not as a blended figure. Phone arrivals cluster tightly into business hours while email and tickets spread and form backlogs. A blended peak averages two different shapes into one that matches neither, and staffs the team to a curve that does not exist.
How to improve peak support hours analysis
Improving peak support hours analysis means sharpening the arrival profile so it reflects real demand, then using it to either cover the peak or shrink it. The cards below cover both the measurement discipline and the operational response that keeps service levels intact through the busy window.
Schedule shifts to the arrival curve
Build rosters from the hourly arrival profile rather than a flat headcount. Concentrate cover in the hour that carries a fifth of the day and trim it in the quiet windows. The peak to average ratio tells you precisely how much extra cover the busy hour needs to hold service levels.
Deflect predictable spikes
When a peak follows a known event, a release, a billing run, an email send, get ahead of it. Publish a knowledge base article, post a status note, or trigger proactive messaging before the contacts arrive. Deflecting the predictable portion of a peak flattens the curve the team has to staff.
Offer callback and async options
Not every contact in the peak needs a synchronous answer. Callback queues, scheduled chats, and async tickets let willing customers move out of the crush. Shifting even a tenth of peak arrivals into a smoothed queue measurably eases the busiest hour.
Normalise time zones and arrival timing
An arrival profile is only honest if every contact is timestamped consistently. Normalise to one operating time zone and count each contact at arrival, not at first response. Inconsistent timing smears the peak across two hours and hides where the queue truly forms.
Common mistakes when tracking peak support hours analysis
- 1
Profiling handled volume instead of arrivals
Handled contacts are limited by how many agents are on shift, so plotting them flattens the real peak and conceals the shortfall. Always build the profile from when contacts arrived, not when they were answered.
- 2
Blending channels into one curve
Phone, chat, and email peak at different times and with different sharpness. A single blended curve produces a peak that fits no channel, and staffs the desk to demand that never arrives in that shape.
- 3
Staffing to the average hour
Setting coverage to the daily average leaves the peak hour underwater every day. The peak hour, not the average, is what breaches service levels, so it is the figure that shift coverage has to be sized against.
- 4
Treating a one-off incident as the pattern
A single outage or viral issue can create an hour that never repeats. Build the profile from enough days to separate the recurring peak from the one-off event, and exclude known incidents before rostering to them.
Related metrics
Ticket Volume
Customer Support MetricsMetric Definition
Ticket Volume = Total New Tickets Created in Period
Ticket volume is the total number of new support tickets created within a defined period. It is the fundamental demand metric for support operations, determining staffing requirements, budget allocation, and the urgency of self-service and product quality investments.
First Response Time
Customer Support MetricsMetric Definition
FRT = Total First Response Times / Total Tickets With a First Response
First response time measures the elapsed time between a customer creating a support ticket and receiving the first substantive response from a human agent. It is the metric that shapes the customer's initial impression of the support experience and sets the tone for the entire interaction.
Average Resolution Time
Customer Support MetricsMetric Definition
Average Resolution Time = Total Resolution Time Across All Tickets / Total Tickets Resolved
Average resolution time measures the mean elapsed time from when a support ticket is created to when it is fully resolved and closed. It captures the end-to-end customer experience of getting an issue fixed, encompassing wait times, agent work time, escalations, and any back-and-forth exchanges required to reach a solution.
Escalation Rate
Customer Support MetricsMetric Definition
Escalation Rate = (Escalated Tickets / Total Tickets Handled) x 100
Escalation rate measures the percentage of support tickets that are transferred from one tier or team to a higher tier or specialist group for resolution. It reflects the gap between the issues customers raise and the ability of frontline agents to resolve them, making it a key indicator of agent readiness, process maturity, and product complexity.
How to build a metric tree
Metric Definition
Build a metric tree so that peak support hours analysis connects to staffing levels, response times and the support outcomes it influences.
Metric trees for customer success
Metric Definition
See where peak support hours analysis fits alongside the other measures a customer support team tracks day to day.
Plan coverage around the arrival curve, not the daily total
Build a support metric tree that decomposes the peak hour contact share into arrival drivers, customer time patterns, and coverage. Give each branch a RACI owner so a peak that threatens service level reaches the person who can add cover or deflect the spike.