Let's start you off with the correct way to calculate concurrent AHT from your single session times per dept at the agent level. It's not much different from voice planning ... other than coming up with concurrent AHT. It is 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 a concurrent rate ( cc rate), making 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 the 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 essential 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.
Formulas
“(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 the session
"Agent_ChatTime"
Engaged time = total hours agent is engaged in chats with customers.
Notes
Also, Concurrency is calculated 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 chats 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.
Example
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 that you may ask how you can get 5000 seconds of chat time in 1 hour ... when 1 hour is only 3600 seconds, those chats start and end times are being done in parallel... aka concurrently.
MORE TIPS
For WEB chat. Effective Concurrency comes from ensuring your agents have the suitable systems to access information and complete ** multiple transactions **
For your chat platform to work effectively and reduce the cost per contact, your agent's access systems have to be just as 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 one 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 have a multisession-capable customer database … ensure it can also handle multiple customer transactions. For example, it would serve no purpose in a chat environment if you can look up multiple customer accounts and then be able to only process one 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 customers 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 is an excellent method to curtail dead air periods and/or customers 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.
Check out the weWFM Podcast on Apple or Spotify
Spotify: https://spoti.fi/3J5gsJh
Apple: https://apple.co/3HskI58
Comments