Customer Experience #
When designing the Customer experience, we highly recommend using the following principles:
- Allow the Customer to access your data dip after hours. For example, allow Customers to access order lookup after hours. This allows you to deflect incoming emails and text messages that Agents will need to deal with when they get into the office.
- Give the Customer unambiguous instructions about what input you need and get out of the submenu if needed (e.g., “Please enter your 8 digit order ID. Your order ID can be found in the subject line of your confirmation email or your packing slip on the upper right-hand side. If you don’t have your order ID, please press 0, and we’ll connect you with an agent”).
- Validate the Customer’s input as much as possible before making your API call (e.g., “That is not a valid order ID. To enter another order ID, press 1. To speak with an agent, press 2”).
- Before the data dip occurs, clearly tell the Customer what you are going to do (e.g., “Thanks, I’m looking up that order right now!”).
- When the data dip finishes, give clear messaging to the Customer about whether or not the data dip was successful (e.g., “I found it!” or “I’m sorry, I couldn’t find your order”).
- If the data dip fails, give the Customer the options to try again or gracefully connect to an agent during business hours and avoid the Customer going through data dip loops! During off-hours, let the Customer know that the data dip was unsuccessful and give them alternative contact methods.
Agent Experience #
We highly recommend syncing Customer behavior to the Gladly Conversation Timeline using a Data Dip. This allows Agents to have context about what inputs a Customer chose in the IVR! For example, you can log the order ID the Customers attempted to find, and the response received your API regarding the order status.
We recommend using the Gladly Create Item API to log this interaction: https://developer.gladly.com/rest/#operation/createItem. You can use the Data Dip node to call the Gladly API and configure customer.phoneNumber in the request body with the {{._customerNumber}}
variable. Doing this has the added benefit of auto-converting the customerNumber to a MOBILE number on Gladly, ensuring that all subsequent calls and texts this Customer makes go to the same Profile.
Testing and Monitoring #
To develop and test the IVR reliably, we recommend:
- Coming up with the IVR design and test cases (e.g., bad Customers input, API times out) prior to IVR development.
- Ensuring that your APIs can match Gladly’s requirements prior to IVR development.
- Load testing your API to ensure it can sustain lookup volume prior to IVR development.
- Utilizing a test number to test on vs. your live number.
- Having access to your own API logs to monitor Gladly requests and debug.
We also highly recommend monitoring the following and alerting your development team (or partners) when an unusually high volume of errors occur:
- Any API timeouts or errors when calling your API.
Improve Your IVR #
Gladly highly recommends implementing the following at a regular cadence to improve your IVR:
- NPS rating post data-dip deployment (available via your NPS provider; you’d ideally like to see NPS increase or stay the same and ensure data dips are not hurting your Customer experience).
- Agent anecdotal feedback (you can ask Agents to use a Topic on Gladly to tag any Customers complaining about the IVR, then use the Topics report in the Gladly UI to monitor).
- How long Customers are staying in the IVR (available via IVR report in Gladly reporting UI).
- How many Customers abandon in the IVR, and what node they abandon on (you’d ideally like to see Customers abandon after a data dip as this indicates their request was satisfied).
- Voice Topics report (you can analyze what calls are about and whether you believe the introduction of new data dips will help deflect these calls).
The above will help give you more information on how the IVR is performing and which areas could potentially be improved upon.