Chat Forecasting: Concurrent AHT

Workforce Management Tips & Tricks

This is Re-Poste from Marlon Martinez  – original post can be found here “How to plan for Web Chat in a call center 101″


Let’s start you off with the correct way to calculate concurrent AHT from your single session times per dept at agent level. It’s not much different from voice planning … other than coming up with concurrent AHT. It also important to understand your chat/dept mix as this is important for the distribution pattern at the interval level and your chat push setup! Below is the most important part of chat planning! The Concurrency Formula :


Important notes

You can not divide or multiply your volumes by a subjective concurrent target or estimated concurrent chat rate


You should not be guessing your concurrency rate! Or allow your TM’s or OP’s to guess how many concurrent chats are being handled by your agents! Below is the actual way to get concurrent rate ( cc rate) which will make your chat planning a breeze!


And YES you can still use Erlang C or X and WFM platforms that use Erlang to plan for chat.. as long as you properly use concurrent AHT and not single session AHT or do any of the above


Single session times must be divided by total logged in “ productive time engaged in chats” and all offline/load must be removed from equation


With voice lines you have lines or trunks, chats does not have this… as you can open as many sessions aka lines/trunks as your system can handle. It is important to set a chat dept. limit as this can destabilize your platform server.  In most chat platforms you can set an open session limit for each chat department to simulate (trunk/lines) required in erlang C or X. 




“  (Total chat time + total Wrap up time) aka “Agent_WorkTime” /(total engaged in chats time aka”Agent_ChatTime”)


“Agent_WorkTime” (HandleTime)

Chat time = Time spent on chat per session

Wrap up time = time spent offline wrapping up session




Engaged time = total hours agent is engaged in chats with customers



Also Concurrency is calc. by workload/WorkTime vs chat per interval .. as some chat may only take seconds to complete


Actual Formulas


.Platform_Concur =IFERROR(Agent_WorkTime/Agent_ChatTime,0) = Concurrent Rate

.Platform_ConcAHT =IFERROR(‘.Platform_AHT’/’.Platform_Concur’,0) = Concurrent AHT


Basic example of concurrency

20 chats XXX complex product @ 1000 seconds = 20000 ** 1 push

15 chats simple product @ 500 seconds = 7500 * 2 push


6.5 hours = 23400 seconds login in chAts engaged productive


27500 /23400 = 1.17 concurrent


80 % chats 1 push

20% are 2 push



Even more simple

If I was logged in for 1 hour taking chats … so 3600 seconds … but I spent 5000 seconds worth (talking/wrap) in several chats during that 1 hour of engaged / productive  time ( those 5000 seconds could be multiple chat and durations but they all total up to 5000 seconds in that 1 hour interval ).  Then my concurrency rate or how many simultaneous chat I handled in that 1 hour is 1.38 … then you can use that concurrency rate to figure out the concurrent handle time for all those chats handled within the interval by diving it by your single session times within the hour/day/week/month.  Concurrent handle time should be used for daily/monthly/interval staff plans.


10 chats at 360 seconds = 3600

5 chats at 280 seconds = 1400

15 chats = 5000 seconds / 3600 seconds (1hr)

Concurrency rate is (5000/3600) = 1.38

Then 5000/1.38 = 3623.1

3623/15 chats = 241.5 concurrent AHT


Keep in mind … you may ask how can you get 5000 seconds of chat time in 1 hour … when 1 hour is only 3600 seconds… well those chats start and end times are being done in parallel… aka concurrently.



 Good article on Chat Mix/Pushes Vs. Customer Experience



For WEB chat. Effective concurrency comes from ensuring your agents have the right systems to access information and complete ** multiple transactions **


For your chat platform to work effectively and to reduce the cost per contact… The systems your agents access have to be just a strong as the platform itself… The major hurdle to a good concurrency rate in a chat environment is multisession capable software.


(Concurrency rate) explained simply is how many multiple chats sessions an agent can handle simultaneously each interval.


So, if your agents cannot access more than 1 account at a time… then your chat platform will be useless and it will cost just as much as a voice call which is a 1:1 Ratio.


If you do have a multisession capable customer database …  ensure it can also handle multiple customer transactions. It would serve no purpose in a chat environment if you can look up multiple customer accounts and then be able to only process once actual transaction at a time.


*** window time and dear air chats***


AST (Average session time) 

AST should include the full session time from the moment a chat is accepted/active to the time it is ended. So if I don’t respond for 5 minutes, that should be in there the session time. 


As far as a solution!  You can control that AST and things like dead air chats or customer who take too long to respond by setting a standard … if you don’t respond within 2

minutes we automatically end the chat and close that session! It a good methods to curtail dead air periods and or customer who abandon the chat or take too long to respond. If we waited till a customer ended every chat….well, some sessions would last days and also you need to set a reasonable standard for your customer to respond to you based on your line of business.



Your email address will not be published.

Need Help? Chat with us

Protected by Security by CleanTalk