Yesterday, I was in the process of building and applying transaction codes within 8×8 to facilitate call dispositions. Today, we had a soft-launch of the new feature, testing out its functions, and viewing the changes to our customer service agents’ workflow. So, I wanted to share some things we observed and learned, as well as the final decision we made regarding going live with the project.
After enabling the transaction codes to be required to be entered after a call is completed, we immediately understood how this could have adverse effects on the number of agents who are available for a call. Requiring an agent to select a transaction code after a call, before he/she has their status changed back to available, can create the possibility of having that agent merely stay unavailable (if they forget to select a transaction code). Due to the realization of the possibility of agents not remembering to use the new codes, we decided to go ahead and suspend going live with the project.
The soft-launch of the new software change for our customer service agents was filled with problems from the very start. We have four brands and most of their phone scripts are separated into two queues: sales and service. However, one of our brands has only one customer service agent managing the calls, so we chose not to separate the script between two call queues. Without two separate call queues, a different transaction code list couldn’t be applied to the brand in question; the fix to the issue is simple, merely creating a separate transaction code list for that brand, but that wasn’t plausible in the timeframe we were working with this morning.
The next problem we ran into was trying to minimize the complexity and time-taken to select a transaction code after a call. Yesterday, I tested the transaction codes without making the process mandatory (to reduce real-world problems in the testing phase); by doing this, the agent would have to manually open the Transaction Code window, select which code the call pertained to, and then click to save the code. I thought that by making the transaction codes mandatory, the agent would have the Transaction Code window appear after the call; however, this wasn’t the case.
Codes can be configured to be optional or required. If we set a code list as mandatory, as an agent processes interaction, they are required to select transaction codes; they can end processing a call only after choosing the desired codes. If we configure a code list as optional, as an agent processes interaction, they have the flexibility to skip codes selection.
In the future, we may want to activate transaction codes for sales campaigns (if we ever decide to go that route). 8×8 offers automatic dialing through an organized list to help facilitate connecting with potential customers; having transaction codes, such as Sale Completed, Invalid Phone Number, Interested, Not Interested, and Contact Again, would allow us to determine which customers were more likely to make a purchase.
For example, an agent processing a sales campaign for a new product places outbound calls to prospect customers. He/she can record the result of each interaction with predefined transaction codes. Further in the sales process, the agent can define transaction codes to identify various stages of the sales process, and apply the codes to convey the status and result of each interaction.
- Do we make it mandatory to perform a call disposition?
If we ever decide to activate transaction codes in the future, we will make them mandatory.
- What codes do we wish to add/remove?
We decided to remove the code, Sale Not Complete, and add the code Not Sales, to the sales code list.
We decided to add the codes, Not Service, Shipping Inquiry, and Issue Resolved to the service code list.
- How much time do we give them to complete it? (Post-Processing time is currently 15 seconds).
If we ever decide to activate transaction codes in the future, we will increase to 20 seconds.
- Who is going to use the information collected from each call disposition, and for what purpose?
Customer service managers and IT will use this data to determine the actual nature of each call, in the hopes of finding which areas in our customer experience need attention and helping to facilitate increased sales.
- Can the process of selecting a transaction code be simplified?
Unfortunately, at this point, the process was not easier when forcing the agents to select a code before their statuses returned to available.
- Final Thoughts?
8×8 transaction codes showed promise, as they:
- Allow agents to classify call types after a call.
- Present unique call codes specific to the queue the call entered.
- Can be set as a required step to completing a call.
Unfortunately, the transaction code process creates potential operational problems, such as:
- When not required, they are unlikely to be logged by agents.
- When required, the action step is not presented to the agent automatically, resulting in an increased likelihood of agents being placed on unavailable status and potentially unknowingly remaining in that status for extended periods of time.
In the interest of prioritizing agent availability and answering incoming calls over logging details about answered calls, a decision has been made to not move forward with this implementation for the time being.
In the future, I will ensure that I avoid launching or testing anything on Friday, the 13th (the date is scary enough by itself). Of course, while I was typing this, Zendesk’s servers went down, creating even more headaches. I am now waiting for Jason himself to walk in with his machete; honestly, I wouldn’t even be surprised.