Self-service or Full service
Self-service or Full service by Jason Andersson
Most of us have seen the signs at the gas station. Asking us, as customers, if we want the full service treatment or the self-service treatment, i.e. do it yourself. Service design is a model to define services that feel like full service, even if they are self-service systems.
Many years ago as a product manager, I was part of developing an Interactive Voice Response (IVR) solution. Self-service in a call center became the automation solution for many services that traditionally were performed by live agents in the call center.
In the 1970’s many call centers installed IVR technology with the sole purpose of automating rudimentary tasks in the call center, but it was very expensive and complicated to use. A decade later a number of companies entered the market, thus increasing the availability and uptake of IVR features. Speech recognition software went from DSP based technology to client-server architecture. Another one or two decades later these companies invested in Computer Telephony Integration (CTI) with IVR systems making the IVR fundamental by collecting customer information that would enable routing for call centers with universal queues.
Wrongfully applied, an IVR can become a customer repellant, where customers choose to go elsewhere due to the aggravation of a poorly applied IVR application. But truthfully, an IVR is in many companies an unused resource and unrealized call handling efficiency factor. The best examples of IVR applications give flexibility and options to a customer without crowding him or her. More innovative organizations use IVR applications to get to know a customer before they enter into a conversation. An IVR can be used to identify, qualify, and understand your customers’ needs before they reach an agent. A really well designed application will lower the actual time in a call, not only conversations with the agent, but the total call time for the customer. IVR applications are best used when both customer and organization can lower the total transaction time consequently both parties benefit from the use of the technology.
Frost and Sullivan released data earlier this year on high growth channels in the contact center. The report had many interesting conclusions, one of which was that the use of IVR has not changed between 2009 and 2010. Many organizations use this technology that was developed many years ago and in it’s basic form has not changed much. We have seen improvements and new features, such as text-to-speech, natural speech recognition and XML based programming languages. But it is still used as an automation engine. Modern IVRs are now multimedia engines that can handle video communication, email, mobile text messages and web to voice solutions. Such engines have become core in an enterprise’s business process automation effort.
Dynamic scripts use historic records of usage in combination with data from other sources to present new or simplified options to customers contacting a service. This could be an adaptable menu that removes options that for one customer is irrelevant based on previous customer choices, or prompt languages based on from where the customer is contacting.
Recently I worked with Verint (www.verint.com) that provides analytics for contact centers and other parts of enterprises. Their software analyzes data from many different sources, including interactive voice response systems.
IVR systems provide graphical environments where one develops applications, or scripts that perform automated features. These scripts used to be hard-coded in the early days, now they employ graphical and XML based code that are easier to understand and that are adaptable. When we combine analytical software capabilities with adaptable scripts it could be possible to create applications that learn from user experience inside the IVR.
Business process automation can benefit from these adaptable scripts or use information from sources such as presence services to locate expertise that would be needed to solve an issue. Instead of hard coding a destination for a specific issue, the system can find the most appropriate destination based on performance data, real time information as well as skill and competence definitions.
Today IVR functionality is built into any respectable contact center system. But the IVR can be used for many more areas than the contact center. Combining IVR systems with graphical renderings for mobile devices with systems such as Fonolo (www.fonolo.com) can simplify how end users get access to your system. By combining voice or mobile menus with websites, enterprises can take an additional step in improving the customer experience.
IVR’s are no longer only about self-service but a tool to improve the full service experience. But they need to be developed correctly. They need to be developed with both your organizations benefits and your customers’ experience in mind.
In This is Service Design Thinking, a book by Marc Stickdorn, Jakob Schneider and other co-authors, they demonstrate a model for “[…] entrepreneurs and innovators in the field of services.” (Stickdorn, Schneider, & etc, 2011) They look at service design as an inter-disciplinary approach, which is a user centric, co-creative and dynamic process that can be measured, proven, and has a holistic viewpoint.
I want to end with some general recommendations for a “full-service” experience development process:
Invite members of organizations that will be impacted or rely on your script.
Who will use the script, externally and internally? Developing great IVR applications should have a holistic approach where the customer, the user is in focus. But there are many users. It is the customer, the department which relies on its service, it is the department that handles any complaints or mistakes, it is those who need statistics from the system. It is IS/IT. And possibly more.
- Define a service timeline.
The rhythm of the service you intend to provide will impact the mood of the customer. If the customer is expecting fast service, a slow IVR prompt with many choices will upset the customer. But a service that is targeting customers who don’t exactly know your organization might want carefully worded explanations and slowly work through multiple options.
Don’t limit your input. Get as much information from as many as you feel necessary to really understand the needs behind the script.
Service is not something you develop and put in storage to bring out whenever it is needed. It is a now-experience. Service is created when there is interaction between your company and your customer. Define a common platform, a code, to make everyone understand each other.
Finally you need to find evidence that supports your claim of improved or worsened customer service. Most organizations know how many customer interactions that pass through an IVR application. But we need ways to measure their satisfaction with that service. Too often services are unnoticed in companies that depend on them. This is where analytic software comes in. Find out how you can use and benefit from analytical feedback in your service processes.
Works cited
Stickdorn, M., Schneider, J., & etc. (2011). This is Service Design Thinking. The Netherlands: BIS Publishers.