An Erlang calculator estimates how many agents are needed to answer a given volume of contacts within a target time. It converts the workload (arrival rate multiplied by handling time) into a number of agents, and it adds the extra capacity needed because contacts arrive at random and queues form even when the average load looks manageable. Support leaders use it to move staffing decisions from rules of thumb to a stated service target.
In brief: staffing is a three-part problem of forecasting workload, converting it into agents using Erlang C, and checking the result against a service-level agreement. The same data supports a cost per ticket figure, which is the number management usually wants in the end. Automation changes that figure mainly by changing how many contacts reach a person.
What does an Erlang calculator do, and who needs one?
Agner Erlang, a Danish engineer, developed the queueing mathematics in the early twentieth century to size telephone exchanges. The Erlang C model, a refinement for systems where callers wait for service, is still the standard method for staffing contact centers. It answers a specific question: given a number of contacts per hour, an average handling time and a number of agents, what is the probability that a contact waits, and how long will the wait be?
It is useful to any team with a service target. A phone-oriented call center staffing calculator applies the same mathematics as one used for chat or email, with one difference in assumptions, discussed below. The Erlang calculator on this site accepts the arrival rate, handling time, agent count and target answer time, and returns the expected service level and utilization.
Smaller teams sometimes assume the method is only for large operations. In practice the effect of random arrivals is larger for small teams, because a few agents have little spare capacity to absorb a burst, so the model is arguably more important for them.
How do you forecast workload before staffing?
Workload is the starting point. It equals the number of contacts in an interval multiplied by the average handling time, and it is expressed in Erlangs, which are hours of work per hour. As a worked example, a team receives 30 emails per hour with an average handling time of 10 minutes. The workload is 30 multiplied by 10 divided by 60, which is 5 Erlangs. In plain terms, five agents working without a break would be fully occupied.
Several inputs need care. Volume should be forecast by interval, because contacts cluster at certain hours and days, and using a daily average hides the peak that determines service quality. Handling time should include the follow-up work after the conversation, not only the live portion. Seasonal events and campaigns should be added explicitly, since a launch or sale can multiply volume for a short period. The relationship between volume peaks and capacity is discussed in our guide to managing high-volume customer inquiries.
How is Erlang C explained in plain terms?
The intuition is that agents need to exceed the workload, not match it. With a workload of 5 Erlangs and exactly 5 agents, utilization is 100 percent, and because arrivals are random the queue grows without limit, as periods of slack cannot be stored for later. Adding a sixth agent brings utilization to about 83 percent, and a seventh to about 71 percent. As utilization falls, the probability of a wait falls sharply.
Erlang C expresses this precisely. It takes the workload and the number of agents and returns the probability that an arriving contact has to wait. Combined with the average handling time, that probability yields the expected wait and the percentage of contacts answered within a chosen time. The result is not linear: the first agent added above the workload produces the largest improvement, and later additions give diminishing returns. Exact outputs depend on the inputs entered, so this article does not reproduce a table of values and recommends running the actual figures through a calculator.
Two further adjustments follow. The model gives the number of agents needed at their desks, so it must be divided by one minus the expected shrinkage to give the number scheduled. If shrinkage from breaks, training and absence is 30 percent, seven agents at their desks require 7 divided by 0.7, which is 10 scheduled. The second adjustment is occupancy: very high occupancy sustained across a shift tends to affect quality and retention, so many teams set an upper limit.
How does staffing differ for chat and email?
Email and chat differ in two respects that change the model. Chat is interactive, so waits are felt immediately and answer-time targets are measured in seconds or a few minutes. Email tolerates a longer wait, so targets are measured in hours, which permits more flexible scheduling and batching.
Chat also allows concurrency. An agent may handle two or three conversations at once, which reduces the agents needed but lengthens each conversation, because attention is divided. The common approach is to use an effective handling time per chat that reflects concurrency, and to check it against measured data. Concurrency assumptions that are too optimistic show up quickly as slower replies and lower satisfaction. For an overview of the practices that affect those outcomes, see our guide to live chat best practices, and for building the team itself, see how to build a customer support team.
What SLA targets should a support team set?
A service-level agreement states a target for responsiveness, such as answering a stated percentage of contacts within a stated time. The traditional contact-center convention of answering 80 percent of calls within 20 seconds is a widely known example, but it describes a convention for telephone queues and not a standard to adopt for chat or email. The right target depends on channel, customer expectation and what the organization can afford.
Targets should be set by contact type as well as by channel. A billing dispute or an outage report deserves a faster commitment than a general question. They should also separate first response from resolution, because a quick acknowledgement does not mean the issue has been solved. The SLA calculator helps compute attainment against a target, and the connection between speed and customer outcomes is covered in our articles on first response time and reducing customer response time.
Customer perception should be checked alongside the operational target. Meeting an SLA while effort and satisfaction deteriorate suggests the target measures the wrong thing, a pattern explained in our comparison of customer satisfaction metrics and in the discussion of customer effort score.
How is cost per ticket calculated?
Cost per ticket equals total support cost in a period divided by the number of tickets handled in that period. Total cost should include agent salaries and benefits, management, software, training and an allocation of overhead. Leaving out any of these produces a flattering figure that does not stand up to finance scrutiny.
As a worked example, a team spends $42,000 in a month on all support costs and handles 3,000 tickets. Cost per ticket is $14.00. The cost per ticket calculator accepts the same inputs, and the AI support cost calculator compares scenarios with automation. Our guide to reducing customer support costs examines the wider levers, and the return on investment of customer support explains how to relate cost to value.
The metric needs interpretation. A falling cost per ticket is not necessarily good if resolution quality falls or customers contact the company again, so it should be read with repeat-contact and satisfaction data. Channel mix also matters, since email and chat tickets differ in handling time and cost.
How does AI change the cost per ticket denominator?
Automation changes both parts of the fraction, and the definition of the denominator must be stated. If an AI agent resolves conversations without a person, a team must decide whether those count as tickets. Counting them lowers the average cost, because the work is cheap, but it can also hide the cost of the contacts that reach humans. Reporting two figures, the cost per human-handled ticket and the blended cost per contact, avoids confusion.
An illustrative example follows. Suppose the same team receives 3,000 contacts in a month, and an AI agent resolves 1,200 of them, allowing human support costs to fall from $42,000 to $28,000 through reduced overtime and fewer hires. Adding a $99 monthly plan gives a total of $28,099, and dividing by 3,000 contacts gives a blended cost of about $9.37 per contact, against $14.00 before. The figures are hypothetical, and an actual result depends on resolution rate, which varies by business.
Bund AI is an AI agent for sales and customer support working through a web widget and a real email inbox. Its plans are flat-priced, with Growth at $99 per month for 5,000 AI replies, and an AI reply is every message the agent sends, so one conversation often takes two to three replies. That makes monthly cost predictable in the model above, because it does not rise per resolution. In early rollouts, 86.7 percent of tickets were resolved with no human touch, though results differ by knowledge quality and request type. The support automation and email support pages describe how the agent handles contacts, and the pricing page lists every plan.
When is an AI agent not the right answer to a staffing problem?
Automation does not remove the need for the forecasting discipline described above. Contacts that need judgment, empathy or authority, such as complaints and complex account problems, still need people, and those contacts may be the ones with the highest value. Organizations with very low volume may find that the gain does not justify the effort of maintaining knowledge sources. Where an AI agent is introduced, staffing models should be rerun using the lower human volume and the longer average handling time that often follows, since the easy contacts disappear and the remaining ones are harder.
Frequently asked questions
What is an Erlang calculator used for? An Erlang calculator estimates the number of agents required to answer a forecast volume of contacts within a target time. It uses the arrival rate, average handling time and service target, and it accounts for the queueing that occurs because contacts arrive at random.
How does Erlang C work in simple terms? Erlang C takes the workload in Erlangs, which is contacts per hour multiplied by handling time in hours, and the number of agents. It returns the probability that a contact has to wait, and from that the expected wait and service level. Agents must exceed the workload, because at equal capacity the queue grows without limit.
Can a call center staffing calculator be used for chat and email? Yes, with adjustments. Email permits longer answer targets and chat permits concurrency, so effective handling time and the target time should reflect the channel. The underlying mathematics is the same.
What is a good SLA for customer support? There is no universal figure. Set the target by channel and contact type, separate first response from resolution, and use an SLA calculator to check attainment. Confirm that meeting the SLA is not coming at the expense of satisfaction.
How do you calculate cost per ticket? Divide total support cost for the period, including salaries, software, training and overhead, by the number of tickets handled. A team spending $42,000 on 3,000 tickets has a cost per ticket of $14.00, which the cost per ticket calculator reproduces.
How does AI affect cost per ticket? AI reduces the number of contacts that need a person and can lower human labor cost, but the result depends on how tickets are counted. Report the cost per human-handled ticket and the blended cost per contact together so that the effect is visible.