Role
IT support
Which kind of ticket comes back most often? If you do not have that list, you also do not know how much of the first line's time goes on solving the same thing for the hundredth time.
Intro call
Four questions we would start with
Which kind of ticket repeats most often?
Usually three or four categories account for most of the traffic. If you do not know them, the improvements land in random places.
How quickly do you find out that an outage affects many users?
If it is after the fifth ticket, you handled the first four as separate cases.
Where does the knowledge of how an unusual problem was solved go?
If it stays in the ticket, the next person will solve it from scratch.
What do you drop first when the queue grows?
Usually writing up the solution - exactly what would shorten the queue next month.
We take over the triage and the searching, you keep the solving
Taking in tickets, triage, finding known solutions and maintaining the knowledge base can be taken off the desk. Diagnosis and the decision to escalate stay with the agent.
- A ticket arrives described. - The category, the system, the user, the workstation and similar earlier cases - before the agent starts reading.
- A known solution is suggested, not sent automatically. - The agent decides whether it fits, because sending a user to the wrong article costs more than a conversation.
- Many tickets about the same thing are visible as one. - A mass outage is recognised earlier than after the fifth phone call.
Scope
What can be taken off IT support
Eighteen example tasks. Each one has a human approval point. Below is a selection, and the scope we fit to your environment.
Taking in a ticket
- One route in for tickets from several channels
- Pulling the system, the symptom and the context out of the description
- An initial category and priority (correction: the agent)
- Adding the data about the reporter's workstation and permissions
- A follow-up question to the user when the description is incomplete
Initial diagnosis
- Linking the ticket to similar ones from the past
- Pointing out changes in the environment from the last hours
- Recognising several tickets with the same cause
- A signal about an outage affecting many users
Known solutions
- A suggested solution from the knowledge base (choice: the agent)
- A step-by-step procedure for typical matters
- Pointing out whether the first line can resolve the case
Escalation
- Assembling the information the second line requires
- A signal when a ticket is escalated without the full data
- Escalations summarised by cause
The knowledge base
- A proposed entry after an unusual case is solved (content: the agent)
- Pointing out articles that are out of date or unused
- A summary of topics with no cover in the base
A day's work
Today
- Tickets arrive by email, by phone and by chat
- The user's description needs a follow-up question in half the cases
- You find similar earlier cases if you remember they happened
- You learn about a mass outage from the number of calls
- An escalation comes back because one piece of information was missing
- You write up the solution when things are calmer - which is rarely
With AI assistance
- Tickets come in by one route, with the system and the symptom pulled out
- An incomplete description triggers a follow-up question without you
- Similar earlier cases are pointed out with the ticket
- Several tickets with the same cause are recognised as one
- An escalation goes with the full data the second line requires
- A knowledge base entry has a draft, you supply the content
- Resolved on the first line
fewer cases escalated unnecessarily
known solutions are suggested with the ticket
- Time to resolution
a shorter road from ticket to answer
the description is completed without manual chasing
- The quality of escalations
fewer tickets coming back from the second line
the full data is gathered before escalation
- A living knowledge base
fewer out-of-date and unused articles
entries are created after a case, and dead ones are pointed out
We start with the intake of tickets, because that is where most time is lost to follow-up questions.
- Step 1
One route and a described ticket
The channels brought together, the system and the symptom pulled out of the text.
- Step 2
Links and recognising a mass outage
Similar cases and several tickets with a single cause.
- Step 3
Solution suggestions and escalation quality
Known solutions and the full data before passing a case on.
- Step 4
The knowledge base
Draft entries and pointing out dead content. Last, because it needs a history of tickets.
Common questions
Questions that come up at the first meeting
How is this different from customer service?
There the matter concerns an order, an entitlement or a complaint and the other party is a client. Here the matter concerns a technical fault and the reporter is usually an employee. The aim is different too: in customer service what counts is a resolution for the relationship, here it is getting things working again.
Will the first line be replaced by a bot?
We do not propose that a bot answers the user - sending somebody to the wrong article costs more trust than the minutes saved are worth. The suggestion goes to the agent, not to the reporter. What changes is how many cases the first line closes itself, not how many people staff it. If you ever want to handle some cases without a person, that is a separate decision taken on data about accuracy rather than in advance.
Does this fall under the AI Act?
IT support is not a high-risk use. The only point needing care is that ticket statistics concern systems and categories rather than agents' productivity - otherwise a support tool turns into an employee assessment tool.
Still have a question that is not here? Book a call
Next step
Which three kinds of ticket account for most of your queue?
We will show you what IT support looks like when a ticket arrives described and a mass outage is recognised early.