Monday, May 18, 2020

Advantages of “Parallel Capacity Agents" for the post Covid WFM world



Advantages of “Parallel Capacity Agents" for the post Covid WFM world 


                        ***Disclaimer for follow up questions… I cannot share in specific info about my current or previous employers ****


Parallel capacity agents

In a nutshell Parallel capacity agents can be created by letting all your agents keep their work from home hardware/kits, even if let’s say the majority come back to at site desks. The basic concept is to move to UBER style scheduling AKA flex scheduling, many orgs have had an issue doing this as most of us are used to that camel hump style scheduling. Typically, all agents want (7am-3pm,8am-4pm and 9am-5pm) and we know there is less of an appetite for EVE and weekends shifts. So, if they became “Parallel Capacity Agents” they could jump on during peak periods from home and get paid a set premium as supposed to things like 2X OT, 3X OT ect. The advantage to the agents of course is they can pick up hours, shifts and save on transportations costs, parking, daycare costs etc...

Pro’s of “Parallel Capacity Agents

Less office space rental/lease fee’s


More employee satisfaction (Less cost to agents getting to work) to do 2-3 hours of OT


Can literally get up to double your FTE amounts during peak periods and weekends if a premium if offered or doing a product launch / Media issue/ or peak sales periods like Black Friday or Cyber Monday

Works well in a FLEX schedule model

Work well in an OMNI Channel model

Camel hump be gone! 🐫 you can flex in agents in those AM and EVE spikes or on weekends

FTE OT requests for special events and launches can be made well in advance and planned via the FLEX uber style (We tell you what we need) you just pick it up type shifts


If you had 1000 FTE as an example and 70% came back onsite (30% will be WFH) but the 100% will have WFH kits… making them “Parallel Capacity Agents” and instead of have only 30% flex staffing you have 100%


Info-structure is already in place (as we can see with this WFH pandemic issue), and you can subsidize your agent’s internet costs as well


No need to contract 3rd party/outsourcers to meet EVE or weekends demands
No need or a reduced amount of seasonal hiring (Less training cost/ Less seasonal attrition)


You can handle volumes easily in excess of your  (YOY) year over year base. YOY contact volume would be based on contact rate % and your customer base and scrubbed out anomalies and events non-reoccurring , ect.


Less load issues, less absenteeism, and also can help agents stay at home when sick (Reduce virus/cold spread)


WFH kits investment has already been made. You can assign each unit to each employee ID and make it part of the IT intake process/Have mobile techs come to agent’s home to fix any issue that cannot be fixed remotely

Saturday, January 18, 2020

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 :


***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.


 Good article on Chat Mix/Pushes Vs. Customer Experience




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.