Artificial intelligence has become one of the most discussed topics in IT in recent years. However, most organizations are still looking for an answer to a much more practical question: How can AI help ticket resolvers today?
That is exactly what our workshop will focus on. This will not be about theory or distant future visions. You will see real AI agents designed for the day-to-day operation of a Service Desk and built to help with specific operational situations. We will demonstrate how to collect device information from the CMDB within seconds. We will show how to identify similarities between incidents that may initially appear unrelated. We will also pay close attention to data and knowledge quality. We will automatically review the quality of resolution descriptions when tickets are closed and automatically generate draft knowledge articles.
Come and see how AI agents can take over routine work, uncover hidden relationships, and transform the Service Desk from reactive support into an intelligent service driven by data and knowledge.
You know the situation: a resolver receives an issue related to a device, and the first thing they need to know is what they are dealing with — what type of device it is, who owns it, and whether it has had problems in the past. Almost every incident begins with manual investigation across different systems: opening the CMDB, checking the configuration, reviewing the history of previous issues involving the same device, and only then starting the actual troubleshooting. In critical situations, this is time you simply cannot afford to lose. We will show you how an agent can do this work for the resolver. On demand, it collects technical information about the device from the CMDB, retrieves its problem history, and presents everything directly within the incident. Instead of starting from scratch, the resolver gets an immediate overview and can focus on solving the issue rather than searching for supporting information.
Have you ever seen ten people report ten seemingly different issues, while only an experienced resolver recognizes that they all have the same root cause? Each report may look like an isolated issue that gets resolved and forgotten. Only when enough similar incidents accumulate does it become clear that they are all related to the same underlying problem. Without assistance, this connection often becomes visible only after the damage has already been done and too many incidents have accumulated for it to be a coincidence. We will show you an agent that automatically identifies similar reports, summarizes what they have in common, and suggests creating a parent Incident that links all related reports together. The final confirmation always remains with the resolver. This allows you to identify systemic issues before they grow into major incidents and prevents teams from solving the same problem repeatedly from scratch.
Have you ever seen a ticket closed with a resolution such as “resolved” or “done” — and a week later nobody knows what actually happened? Such records are useless for reporting, cannot be turned into valuable knowledge articles, and create additional work during audits. The problem is that poor-quality resolution descriptions are usually discovered only afterwards, when it is already too late to fix them easily. We will show you an agent that checks the quality of the resolution description at the moment the ticket is being closed — not afterwards. When the operator enters the resolution, the agent evaluates whether it contains sufficient detail, describes the action that was actually performed, and identifies the cause of the issue. If not, ticket closure is blocked and the operator immediately receives feedback on what needs to be added. No waiting for a supervisor and no generic error message. The result is consistent documentation across the entire team from day one, without requiring manual supervision of every ticket.
Have you ever had a resolver solve an incident, close the ticket, and keep all the knowledge about the solution in their own head? Turning that experience into a proper knowledge article takes additional time, and in day-to-day operations there is rarely enough of it. As a result, the same issue is solved from scratch again a month later, perhaps by a completely different person. We will show you an agent that automatically creates a draft knowledge article from the information contained in a resolved incident. It generates a concise summary, adds relevant keywords to make the article easy to find, and sends it into an approval workflow where the knowledge team only needs to review and publish it. This allows your knowledge base to grow continuously without requiring resolvers to actively think about writing documentation on top of their regular work.
You know the process: a new ticket arrives in a queue, and before it reaches the right person, someone has to read it, decide which group should handle it, and then determine who on the team currently has capacity. This decision is made manually for every single ticket and, in day-to-day operations, is often based more on intuition than actual workload. As a result, some people become overloaded while others have capacity available. We will show you an agent that makes this decision automatically. Based on the ticket title and description, it selects the most appropriate support group, checks how many active tickets each team member currently has, and assigns the ticket to the person with the lowest workload. Both the group and the owner are written directly into the ticket without any additional clicks. The result is more balanced team workload and a faster start to work on every new ticket.
You know the moment when an operator opens a ticket and first has to read through the entire history, understand the user’s mood, and only then start writing a response that matches both the situation and the appropriate tone. Across dozens of tickets per day, this time quickly adds up, even though many responses are similar in structure and content. We will show you an agent that prepares the response for the operator. Based on the ticket title, description, and comment history, it evaluates the user’s sentiment, determines the most appropriate communication tone, and prepares a specific draft reply that the operator only needs to review and send. The result is faster and more consistent communication with users, without forcing the operator to start every response from a blank page.
Has your team ever faced a situation where a problem resolver receives a symptom and then spends hours manually investigating related changes, incidents affecting the same service, and other historical information before they can even begin to understand what might have caused the issue? In a complex infrastructure, this can easily take an entire day, and the result still depends on whether the resolver overlooked something important. We will show you an agent that performs this research automatically. With a single action, it retrieves changes and incidents related to the same service or component, compares them with the symptoms of the current problem, and returns up to three of the most likely root-cause hypotheses. For each hypothesis, the agent also proposes specific steps that can be used to verify it. The results are written directly into the problem record, ranked by likelihood and ready for assessment by the L3 team. This can significantly reduce the time required to resolve problems because the resolver no longer starts from zero, but can immediately begin validating concrete hypotheses.