ASA-2021: a new stage in the evolution of the smart assistant

Done before

The ASA is a multifunctional solution that today can analyse the text of support requests, classify requests and assign them to the teams that are best equipped to handle them, route requests to the most competent engineer available, notify engineers of events in the ITSM system, new assignments and other events, monitor the quality of service and adherence to the SLA, as well as suggest solutions based on the history of how similar requests have been handled in the past.

How has the ASA evolved over the past year?

In the past year, we’ve continued improving the functions of the smart assistant in accordance with the approach the company had previously developed for it. Just like before, we get proposals from end users — our staff who provide services to customers. In 2021, this has allowed us to add new functionality to the assistant in the following areas:

— Automatic resolution of support requests (auto-resolve). The auto-resolve tool was designed and tested in late 2020. The platform is based on the following principles: security, efficiency and versatility of the solution at a minimal cost of deployment and subsequent support. Therefore, it was decided to implement the platform as a native Windows application. The platform has been undergoing trials since early 2021 in one of the service projects (O365 support, 2nd and 3rd lines of support): in this time, 350 support requests have been resolved automatically (the average resolution time per request is under two hours). Next, we plan to increase the number of projects that use ART as well as Azure DevOps for the development, testing and delivery of automated services and the ART platform to automate the delivery of software through MS Intune.

- Assessing the complexity of an incident. While in the past, when working with ITSM systems, we tracked the number of requests resolved by an engineer, now, the goal is to make a qualitative assessment of every support ticket resolved. There are several criteria used for that. For example, how unique the ticket was, how many comments were made about the proposed solution and the number of teams that took part in resolving it. In addition, we also analyse how the ticket was received: if it was submitted by a user, we assign it one weight, if the ticket was submitted by the monitoring system, different weight is assigned to it. Such analytical data are used to determine a complexity score for the ticket, which can be high, medium or low. This allows us to assess the performance of support engineers not only by looking at how many tickets they resolved in a given period but also by assessing the complexity of the tickets they dealt with. For example, John resolved 10 tickets and Peter only resolved 5. At first glance, it might appear that John’s performance is twice as high as that of Peter’s. But if we look at the complexity of the tickets they were dealing with, it may well turn out that all the 10 tickets that John resolved were low complexity tickets and our model assigned them a total score of 50, while Peter was dealing with high complexity tickets and our model assigned them a total score of 100. We’re already using this functionality on one project but the plan is to start testing it on other projects as well.

— Automatic demand and trend analysis on unstructured data. For example, we’ve got several teams that don’t have classifiers in the ITSM system and so users just type in some text comments. Analyzing such text comments is a very labor-intensive task: when there are a lot of events like that, it’s very difficult to assess their parameters, such as degree of recurrence, etc. So, a solution powered by machine learning has been developed which makes use of unsupervised learning and natural language processing to analyze such unstructured data. The model analyses the text of customer requests and groups them into clusters: the larger a cluster is, the more relevant and popular the problem is judged to be, and that means we need to focus on it first.

— Additional technician notification scripts (the notification bot). To build these, we considered what other events could be monitored automatically. We decided to use an escalation algorithm: if some event happened and there was no response from the assigned technician within the allotted time, the notification gets passed on to their team leader. A bot is a unit that monitors ITSM processes based on such parameters as timeframes, tasks, assignees and event triggers.

With the expanded functionality and all the innovations implemented so far, the automated smart assistant allows us to save over 5,200 work hours for our staff, coordinate more than 170,000 support requests and incidents per year and making more than 130 recommendations on how to resolve support tickets every day.

Next steps

The company plans to link up the smart assistant with the corporate knowledge base of ICL Services. The goal is not only to suggest a solution based on how identical incidents have been resolved before but also to direct the support technician to a relevant article in the knowledge base that might help them resolve the ticket better and in less time.

Furthermore, we plan to improve the ITSM interaction subsystem to manage it via the chatbot and implement automated incident resolution using machine learning. The new system will decide whether a ticket should be routed to the auto-resolve system or a human technician and classify tickets to pick an auto-resolve process that a specific incident can be routed to and the solution that should be launched for it.