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 :
***Disclaimer for follow up questions… I cannot share in specific info about my current or previous employers ****
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.
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 session
"Agent_ChatTime"
Engaged time = total hours agent is engaged in chats
with customers
Notes
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.
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 ... 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.
MORE TIPS
1.
For
WEB chat. Effective concurrency comes from ensuring your agents have the right
systems to access information and complete ** multiple transactions **
a.
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.
b.
(Concurrency rate)
explained simply is how many multiple chats sessions an agent can handle
simultaneously each interval.
c.
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.
d.
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.
