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 will enable you to deflect incoming emails and text messages that Agents must deal with when they get into the office.
- Give the Customer unambiguous instructions about what input you need and exit the submenu if necessary (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 will 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 option 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 gives Agents context about what inputs a Customer chose in the IVR! For example, you can log the order ID the Customer attempted to find and the response received by your API regarding the order status.
We recommend using the Create Item API 
to log this interaction. 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 before IVR development.
- Load testing your API ensures it can sustain lookup volume before IVR development.
- Utilizing a test number to test on vs. your live number.
- Having access to your 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 introducing 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 be improved.
