As I’ve noted in earlier blogs in this series, this week, one technology option for customer experience management stands out…AI. OK, maybe it stands out because AI stands out of most everything these days. Maybe it’s because AI is at least one reason why HPE wants to buy Juniper, and Cisco wants Splunk. But there’s another reason that’s more fundamental, and that’s the fact that AI actually has a lot of potential in the area of CEM. Potential, but there’s a lot more involved than just slapping an AI label on a product.
Service providers and both enterprises as users and enterprises as providers agree that there are three primary customer experience management issues that AI could reasonably be expected to help address. The obvious one is primary customer chat support, which could be a problem report or simply a need for information. The next-most-obvious is diagnostic and remedial assessment of a product or service, based on information entered or received as telemetry, and the final one is proactive assessment of operating conditions, an augmentation of the monitoring/management functions we already have. Each of these has great potential, and each presents a mixture of specific needs and issues.
Chat support is usually seen as a simple AI augmentation of the chatbot concept, and is most useful as a means of answering questions rather than analyzing things. The information source for this particular mission is most likely something like a product reference or perhaps a call center script. Most people with any technical bend have, at this point, tried out one or more of the public generative AI models, and so are familiar with conversational interaction with AI. Some have experienced generative AI’s ability to produce images. This experience makes the notion of having generative AI support chats seem very logical. It is, and it isn’t.
A support chatbot actually has two dimensions. One is the ability to sustain a contextual, conversational, interaction with the customer. That requires a generative AI technology that has been trained in conversations, which is necessarily language-specific and idiom-sensitive even to versions of a language; US English, UK English, and Australian English are examples of the latter. The second dimension is the ability to provide highly accurate answers to questions that are not likely to be answered properly on the Internet. Customer support responses should be generated based on product/service information specific to the chat target.
Data I’ve gotten from 47 companies who have tried AI chatbots suggests that getting both of these dimensions right isn’t an easy proposition. While it might be tempting to say that you could train an AI model from a large collection of support chats, that would presuppose that the product/service elements were static through the collection and would be static once live operations began. Only 9 companies said that was the case for them. In addition, only 12 of the 47 said they actually had a large collection of chats they could work with. Nobody admitted to having truly satisfactory results at this point, though I think three or four probably are close but are working with an AI provider under NDA.
The diagnostic and remedial assessment mission is an expansion of the question/answer chatbot mission, but requires a much more focused dialog. About a third of the companies who expressed interest in this mission saw it as something that was invoked by an automated attendant or perhaps by a generative AI chatbot that handled primary customer contact. This mission actually has the same two dimensions as the first one, but because the dialog is more focused the training needed for a conversational exchange is simpler and the core data to be used in framing a response is focused specifically on troubleshooting. That almost surely means simpler conversation training for the first dimension and a specialized database for the second dimension.
Both consumers and suppliers think this particular mission also introduces an opportunity for image/video interpretation as an input or prompt. Live customer support people tell me that they often request (or wish they could request) that a caller provide a picture of their situation, particularly where cabling or panel settings are involved. Enterprises also tell me that they would like to be able to get plant workers to send an image of what they see at a particular valve or switchbox, and to send them an image of what should be there. AI has both image recognition and image generation capability, but everyone involved is wary of the use of either because a mistake (an AI “hallucination”) would be difficult to catch and potentially catastrophic.
It may seem a small step from this mission to the last, the proactive diagnostic and remedial assessment mission. The difference here is that this mission does not respond to a user request, but to a generated condition or perhaps even to nothing more than the results of continuous assessment. Users think this is the holy grail of AI use in operations, and so do vendors and service providers, because without this proactivity, customer experience management practices accept problems and try to resolve them. With proactivity, the problems are prevented.
Technology generates logs, sometimes a minimal set and sometimes a lot of them. It also exposes APIs through which status information can be gathered, and the combination of the two has long been used to “monitor” and “manage” the technology. Specialists with proper training can learn a lot from either source, but these specialists agree almost 100% that there are conditions that could be inferred from these sources but are likely to be missed because the analysis is too complex, too time-consuming. One of the persistent hopes of these specialists is that AI could step in and do the heavy lifting, the high-level correlation of minor things that might add up to a major thing. If this could be done, it might prevent that major thing from ever happening.
There are three challenges these specialists list for this mission. The first is that making all that information accessible to AI can be very difficult, the second is that the analysis might actually create significant load on critical infrastructure elements (almost like a denial of service attack), and the third that once you find something via AI, you have to decide what to do with it.
Technology products and services expose a variety of different APIs and logs, often different depending on vendor, age, and other factors. To build an AI tool that can interpret any random set of formats for any given deployment would be a chore. There are standards that apply in some areas, but most of them can be “extended” and most vendors will extend them. Without some way of harmonizing the formats from all the sources, and without coverage of sources that are largely opaque, AI can’t efficiently gather what it needs.
Another factor that came along a couple decades ago is the risk of overloading management APIs with requests. Applications that want information on resource state are proliferating, and AI would add to that growth. At some point, the number of requests made could actually create a performance problem for the devices getting hit with the requests. The now-obsolete IETF RFC “Infrastructure to Application Exposure” or i2aex, came about to address this issue by creating a repository of management data populated by a daemon that polled at a suitable interval, and having applications query the repository and not the resource.
The final point is the most complicated. I got data from 524 NOC types in almost 40 verticals, and well over 90% said that they would have a problem with letting AI act on analysis; they preferred to have AI tell them what it thought was going on or recommend something. In all, they were more interested in getting AI to generate a complete picture of the situation than even making a recommendation, because if a recommendation was made, they wanted to know what was behind it.
There are a lot of challenges associated with realizing any of the AI missions I’ve outlined here, and a lot of interest in each of them. Right now, it’s my view that all too much AI attention is focused on generating a quick flip or IPO rather than on building an enduring value. I’ve always believed that Juniper’s Mist/Marvis AI stuff, and IBM’s watsonx, were different because they were practical. We need practicality here, in the application of AI to customer experience management, or we risk a failure to address key points and realize the benefits we could and should be seeing.
