|
Support Swarming is not new. I was, literally, doing it at the turn of the century. (I’ve always wanted to say that! After all, I did start working in IT way back in the 1900’s…) That said, it has changed significantly since then. One of the most impactful changes was ushered in by advances in linguistic analysis and machine learning capabilities; enter Intelligent Routing. Some call it smart routing, smart ticket routing, automated incident assignment… the list goes on. At Dell EMC, we refer to it internally as “Intelligent Matching and Swarming” (IMS). We decided that “Intelligent Matching” was a more suitable name, because the intention was to go beyond simply automatic routing of Service Requests (incidents) to the right engineer – it was about matching people to challenges, matching knowledge to work, matching engineers to other engineers to form a Support Swarm, and more… Our vision was to radically transform our entire customer service experience – with IMS at its core. This customer service experience transformation program was built with the understanding that Knowledge Management was central to a successful and positive customer experience. In fact, the Knowledge Management team was responsible for defining the overall vision and strategy for the entire program. Our executive leadership team understood the immense transformational power of Knowledge Management, and I wanted to be a part of a team that really got that. When I saw there was an open role in this team, I dove for it. At the time, I had a fantastic job as the owner of the IT Knowledge Management process, and was just on the cusp of realizing the culmination of a year’s worth of intense planning and hard work. I had what I thought was my dream job – the role I planned my entire career around for the better part of a decade. It was excruciating to leave that position and transfer to our Services organization, but I knew I couldn’t let this opportunity pass me by. This new job was to design our Dynamic Profiling framework, and lead the effort to design how our Intelligent Matching would work. How cool is THAT?!? (Yes, I know I’m a total nerd. I’m OK with that.) In a recent blog post (The Evolution of Knowledge Management: From Document Capture to Digital Experience Management) I covered the philosophical ideal behind our Intelligent Matching program. In this one, I want to pull back the covers a bit, and talk about how it works. I’m also going to take a look at a few of the extraordinary peripheral benefits of the approach we took. The Building BlocksOur IMS implementation was built upon the foundation of a Dynamic Profiling framework. We based our Dynamic Profiling Framework on high-level, general guidance around a potential profiling approach provided by CSI (Consortium for Service Innovation – the publisher of KCS). My primary responsibility for my first year with the team was to take that general guidance and make something real from it. CSI suggested five profile types:
The basic idea was that analyzing this robust profiling framework would allow us to understand the work coming in, factor in the customers and their environments, and use that insight to find the “Best Available Resource” (BAR) to manage the incoming work demand. Long-term, our goal was to use this extended context to drive further automation into knowledge delivery, customer risk analysis, predictive service analytics, auto-pushing patches, and so on. The first four profile types turned out to be fairly straight-forward. I won’t bore you, spending too much time dwelling on them. The intention was to evolve them to be more dynamic in nature, particularly around the People Profiles. Individual skills, experience, consumption preferences, work environments… these should all automatically influence their profiles. With Solution Profiles, the idea was to understand the solutions from the perspective of our customers’ view of their service offerings. We didn’t want to see a deployed solution in a vacuum, we wanted to know that it was part of our customer’s online banking system – and we wanted to understand what SLA’s, downstream impacts, and other potential risks they could face. Ideally, we would also know what other infrastructure components (including ones we didn’t sell or service) were a part of this service offering. Knowledge Profiling, as I interpreted it, would simply be an index of knowledge assets from across (and some from outside) the enterprise. The better we were at using linguistic analysis to ingest and dynamically index knowledge, the better we could integrate that into our customer service experience processes. Perhaps there’s value in exploring that in a future blog post, but not today. I had enough difficulty fitting all this into a (relatively) consumable size. What I really want to open up for you is how the fully dynamic Work Profiles make IMS a reality… Problems Cause IncidentsTo build Work Profiles, we started by clustering incidents… Work Profiles, as I saw it, should allow us to understand the type of work coming in, how to best resolve it, and how to set customer expectations. What better way to do that than look at the outcomes of what had been done before? Group all the incidents that are as similar in nature as possible, then look at averages, trends and performance factors within and across each cluster. The Information Technology Infrastructure Library (ITIL) certainly has its blind spots and shortcomings, but it does also contain some real value. In this case, it’s ITIL’s distinction between “Incidents” and “Problems” we must start with to solve this particular… er… problem. In ITIL terms, an incident is a customer-impacting (or potentially customer-impacting) event. A problem, much like a math problem, is something that needs a solution. A problem is often the underlying cause of an incident. For example: If a customer can’t print a file, that’s an incident. The problem that caused that incident (the root cause) may be a bug in the printer driver software. That one problem can cause a multitude of customer-impacting incidents. This distinction is critical when building Work Profiles. The ideal when attempting to cluster incidents, is to group them into singular problem statements. Extract as much information as you can from past incident records and combine it with as much context as you can from the rest of the profiling framework (and whatever other information you can). You know the size of the customer, the scale of the implementation, and hopefully other vendors’ products that are part of the infrastructure of this particular service offering. You know what recent failures they’ve had, what codebase they’re currently on, and hopefully any generated error messages. The more context you can nail down and correlate against, the more confidence you can have in the similarity of the distinct incidents within each cluster. I also want to suggest here that you may want to consider expanding what defines an incident record in your organization. Step outside the box of your CRM/ITSM ticketing system. If a customer posts a question to your support forum, that’s an incident. If someone searches your knowledge base for a solution to the problem they’re experiencing, that’s an incident. If someone Tweets a question at your support handle… You get the picture. Every indication that a customer is being impacted is the record of an incident – and most of them will point to one problem or another. When it comes to incidents, most of the most valuable information is in unstructured free-text fields. Linguistic analysis is a crucial capability for extracting a meaningful level of information from these sources. (This is where I pull out my favorite soapbox: Natural Language Processing.) Explaining exactly how to suss out the problems that bind your incidents together is beyond the scope of this blog post – plus, the details will vary widely from one organization to the next. I will say, however, that Text Mining/Analytics will simply not suffice. Analyzing information in such a broad range of formats requires the full depth and breadth of linguistic analysis capabilities provided by Natural Language Processing.
Have a talented Data Scientist build the models, and have experienced domain subject matter experts train, validate and refine the models. Once you’ve clustered past incidents into common problem statements, simply summarize them as Work Profiles. When a new incident comes in, run it through your linguistics analysis engine to see which Work Profile it best fits into. From this Work Profile, you can glean how much of an impact it may be, how long it should take to resolve, what knowledge articles should be helpful to troubleshoot and resolve it, and a host of other critical insights. Perhaps the most important bit of insight you now have is the performance of the engineers who have worked these incidents in the past. Obviously, to automatically route work to a BAR (or Swarm) based on analysis of historical information, you need to have historical information available to analyze. This is the case with the vast majority of our incoming SR’s, and this is what I’m focusing on for this blog post. In those minority situations with limited historical information (such as a new employee or new solution) and other one-off situations (such as cross-training opt-in opportunities) we fall back on tried-and-true skills-based routing and other more static techniques to match engineers to opportunities. Our Dynamic Profiling framework vastly improved our capabilities here, but I don’t see much value in my rehashing decades of development on improving these methods.
Now you can see everything you need to know to properly assign the incident, what has been done in the past to resolve similar incidents, and what kind of impact your customer can expect. But it goes much deeper than that. The Dynamic Profiling framework allows us to push well beyond our previous Customer Experience insight depth horizon. For example, Work Profile analysis shows us that John and Cindy are both high performers across most of the disciplines in their domain, but when they’re on a Swarm together, team performance suffers. Either the apparent conflict should be addressed, or maybe they just shouldn’t be on a Swarm together. Karthik is a valuable networking subject matter expert, but his performance reveals that he’s less effective when it comes to devices from a specific vendor. It’s time to send him to training, and maybe he should opt-in to join Swarms, as an observer, for new incidents involving this vendor. Maybe the Work Profiles will reveal an apparent personality clash between one of our engineers and the weekend night shift at a major customer’s Command Center. We should make sure those incidents get routed to an engineer with a better track record of working with that customer. An extraordinarily valuable benefit in such an approach is that it allows us to reveal patterns and dynamics that we wouldn’t otherwise even be able to measure if we had thought of it. The more context you introduce, the deeper the insight. Who knew that Tyrone’s performance drops precipitously every time the Red Sox lose? (Good luck resolving THAT one!) But Wait… There’s More!People in Customer Service often speak of “Moments of Truth” in customer relationships. Jan Carlzon popularized the term in the mid-eighties, when he was the President and CEO of Scandinavian Airlines. (Contrary to popular belief, apparently the term was coined by Jan’s consultant, Richard Norman, in 1981. Something I learned while writing this blog post. Thanks, Jeff!) Broadly speaking, a Moment of Truth is an instance that can change a customer relationship (for better or worse). Every interaction with a customer is a potential Moment of Truth (or interaction with a potential customer – or even a potential potential customer, if you choose to include the “Less than Zero Moment of Truth” as defined by eventricity Ltd). Frankly, I don’t like to get into the machinations of categorizing “Moments of Truth” into the proposed five recognized types. The simple reality is: EVERY interaction someone has with your brand, regardless whether or not you’re present for it – or even aware of it – is a potential “Moment of Truth.” The implication of this is that Customer Experience Management relies heavily on uncovering and understanding those interactions – otherwise, how could you hope to manage them? Picture it: Sicily, 1913. The days were hot and the long nights were filled with dance halls, Sambuca and lonely sailors. Marco was off on a six-month– Oh wait… That’s the story for my other blog… Picture it: You’re a Service Owner, singularly focused on improving your service offering to your customers. You log onto your service health & wellness dashboard and see your current top 10 problems – each displayed, along with your customers’ “Moments of Truth,” on their own timeline. On each problem timeline, you can see:
This information, once it’s categorized by problems, provides a staggering wealth of insight and opportunity. At a glance, you can see:
(Just think about never having to be asked to qualify and quantify deflection again!!)
I haven’t even gotten into what a shot of adrenalin this would be to struggling Proactive Problem Management, Predictive Service Analytics, and KCS Evolve Loop programs! Clustering incidents by their underlying problems opens extraordinary possibilities for better visibility into the Customer Experience and more effective resource management – allowing us to craft a far more Effortless Experience for our customers. Knowledge Management is not just central to Customer Experience Management – Knowledge Management is Customer Experience Management. The best way to manage either is to measure them both together. The best way to do that is to Follow the Problem. The post Enabling Intelligent Routing and Support Swarming (and then some): Follow the Problem appeared first on InFocus Blog | Dell EMC Services. |
