Home · Solutions · Other solutions
Solution · Other solutionsCategory, priority, owner and a two-line summary set on arrival; escalations run on a clock
Tickets triaged and routed before an analyst reads them
Every ticket, email and Teams message is read on arrival, given a category, a priority and an owner from your own matrix and escalated on timers; dispatchers decide only the uncertain cases.
Executive summary
Priority follows the requester's capital letters, and a P1 waits in the queue until a dispatcher has time to read it.
The portal, the two shared mailboxes and the Teams channel feed UiPath Communications Mining, trained on the centre's own ticket history.
Tickets reach the right group within minutes of arrival rather than after the dispatcher's next free moment, whatever the shift.
ServiceNow (tickets, assignment groups, CMDB); Power BI dashboard
Business problem
IT service desk
Triage is a judgement task done under time pressure by whoever is free, with the requester's own priority as the starting point. Categories differ between dispatchers, so routing differs too, and a ticket sent to the wrong group loses a day while two groups pass it back. Priority reflects tone rather than business impact, which is how capital letters come to outrank an outage.
Escalation rules exist in a policy document that relies on somebody noticing an unacknowledged P1, and on a shift with 300 new tickets nobody is looking. Tickets that arrive by email or in the Teams channel have no category, priority or group until a person fills the fields in, so the desk's response time is really the dispatcher's reading time.
The problem survives because triage looks cheap per ticket and invisible in aggregate: six minutes on one ticket is nothing; six minutes on 6,400 tickets is a full-time job that resolves nothing. The tooling gave dispatchers a form to fill, not something that reads for them, so every new channel arrives as more reading for the same people.
How it works today
- SystemA ticket arrives through the portal, one of two shared mailboxes or the Teams channel; portal tickets carry the requester's own priority, the others carry empty fields
- WaitingNew tickets sit unassigned until the dispatcher on shift reaches them, after the meeting and the rest of the queue
- PersonThe dispatcher opens each ticket, reads it, guesses the category, sets a priority and picks an assignment group
- PersonThe group lead reassigns to an engineer; a ticket that landed in the wrong group goes back and is read again by the next dispatcher
- Risk of errorA P1 nobody has acknowledged is noticed only when the requester adds "any update?" or telephones the desk
- PersonEscalation happens by phone or Teams chat to whichever lead answers, and the priority is corrected after the fact
- Risk of errorThe monthly SLA report is compiled from corrected priorities, so it measures the tidy version, not the one requesters lived through
Why the current process costs more than it appears
The budget shows headcount, not what it is spent on.
- Every misrouted ticket is read twice, by two groups, and the requester loses a day while it travels back; none of that appears in a timesheet.
- Priority set by tone means an outage can wait behind a monitor request, and the expensive part is not the dispatcher's minutes but the fifty minutes of 300 people in payroll.
- SLA figures built on corrected priorities show green while requesters see delay, and capacity is planned on categories that record dispatcher habits rather than demand.
- When the dispatcher is out, the whole desk's response time moves with them: a key-person dependency disguised as a role; a second intake channel or business unit means a second reader.
Cost of inaction
Volume rises with each business unit and intake channel, and each rise lands on the same dispatch shift, so time to assignment lengthens and the escalation policy is honoured less often. SLA reporting keeps measuring corrected priorities, so management sees green while requesters see delay, and rework grows with volume.
Experienced dispatchers tire of reading and leave, and the desk hires readers instead of resolvers. Broker escalations get the same lottery as internal tickets, now with reputational stakes. Within a year the centre has more tickets, the same latency and a queue nobody can describe in consistent categories.
A plausible organisation with realistic proportions. The figures are there to be recalculated on your data; they are not a client result.
An insurance group's shared-service centre in Poland handling IT and internal-service tickets for 2,100 employees, plus broker escalations in the same ServiceNow instance; Microsoft 365 E3.
About 6,400 tickets a month through the self-service portal, two shared mailboxes and one Teams channel; the centre's own sample shows one ticket in eight misrouted at first assignment and priorities corrected afterwards on a third of incidents.
One dispatcher per shift reads the queue serially and assigns by opinion; escalation happens by phone; the SLA report is compiled monthly from corrected priorities; a second business unit joins next year with the same dispatch team.
Around six minutes of dispatcher time per ticket before anyone starts to work on it, and a queue whose latency is one person's availability.
UiPath Communications Mining reads every ticket on arrival and predicts category, urgency, affected service and the key fields; a robot applies the centre's routing and priority matrix and updates ServiceNow through UiPath Integration Service; uncertain cases reach the dispatcher as a UiPath Action Center task in Microsoft Teams; Orchestrator timers escalate unacknowledged P1s to group leads in Teams.
In the modelled case about 85 tickets in 100 are categorised, prioritised and assigned without a dispatcher decision once the model has learned from the centre's history, first-route accuracy rises because the matrix is applied the same way on every shift, and a P1 is escalated by the clock; the figures describe a model, not a measurement.
Proposed solution
The portal, the two shared mailboxes and the Teams channel feed UiPath Communications Mining, trained on the centre's own ticket history. For every new item it predicts intent, urgency, affected service and sentiment, and extracts what an engineer needs (location, asset tag, affected users, business unit), each with a confidence score. It recognises and extracts; it does not decide.
The decision is deterministic and belongs to the centre. A robot applies the routing and priority matrix, owned by the service manager: affected service and user count set the priority, category and business unit set the assignment group. It writes those fields into ServiceNow through the Integration Service connector and adds a two-line summary produced by UiPath GenAI Activities from the ticket text, shown above the original message, never in place of it. Below the agreed confidence threshold, the ticket becomes an Action Center task for the dispatcher in Microsoft Teams, prediction pre-filled, and the dispatcher's choice joins the next training round.
Escalation runs on timers rather than on attention: Orchestrator time triggers compare acknowledgement and resolution with the SLA for each priority, and an unacknowledged P1 goes to the group lead in Teams, then to the service manager. This solution resolves nothing: it decides what each ticket is, how urgent it is and who owns it, then watches the clock. Resolving tier-1 requests before a ticket exists and running an incident to closure are separate solutions.
UiPath Communications Mining intent, urgency and field predictions with confidence scores; UiPath GenAI Activities (Summarize Text) under AI Trust Layer policies; UiPath Orchestrator queues, time triggers and audit; UiPath Integration Service connectors for ServiceNow, Microsoft Outlook 365 and Microsoft Teams; UiPath Action Center tasks completed in Microsoft Teams; Power BI
The routing and priority matrix as versioned rules, the ticket-update robot, the confidence threshold and the dispatcher task, the escalation timers and their Teams messages, the correction loop back into training, and the Power BI dashboard
Mapping of the affected-service label to CMDB configuration items and their SLA definitions in ServiceNow; requester attributes (business unit, site) read from Microsoft Entra ID through Microsoft Graph
How the automated process works
- AutomationA new ticket, mailbox message or Teams post is picked up by an Integration Service event trigger and queued in Orchestrator
- AutomationCommunications Mining predicts category, urgency, affected service and sentiment, and extracts the key fields, each with a confidence score
- SystemA robot applies the routing and priority matrix and writes category, priority, assignment group, the extracted fields and the two-line summary into the ticket
- PersonA prediction below the confidence threshold becomes an Action Center task in Microsoft Teams; the dispatcher confirms or corrects it in seconds and the correction joins the next training set
- AutomationOrchestrator time triggers check acknowledgement and resolution against the SLA; a P1 unacknowledged in time is escalated to the group lead in Teams, then to the service manager
- PersonGroup leads act on escalations; the service manager owns the matrix and reviews accuracy and corrections monthly
- AutomationEvery prediction, rule and human decision is logged, and the Power BI dashboard shows accuracy, corrections and SLA attainment by group
Human-in-the-loop model
Automation handles
- Reading every ticket, email and chat message at arrival, on any channel
- Predicting category, urgency, affected service and sentiment, and extracting the fields the engineer needs
- Applying the routing and priority matrix, updating the ticket and writing the summary
- Timed escalation when acknowledgement or resolution passes the SLA threshold
People decide
- Low-confidence tickets, with the prediction shown and one click to confirm or change it
- The routing matrix and the priority definitions, owned by a named service manager
- What happens once an escalation reaches a group lead
- The monthly review of accuracy, corrections and model drift, and when a retrained model goes live
Before and after
Systems and integrations
Every entry can be checked in vendor documentation. The evidence class is stated next to each one.
Inputs
- ServiceNow self-service portal
- two Outlook shared mailboxes
- the IT support channel in Microsoft Teams
Automation layer
- UiPath Communications Mining
- UiPath Orchestrator
- UiPath Robots
- UiPath Integration Service
- UiPath Action Center
- UiPath GenAI Activities
Target systems
- ServiceNow (tickets, assignment groups, CMDB)
- Power BI dashboard
Human touchpoints: Action Center tasks in Microsoft Teams for uncertain tickets; escalation messages to group leads in Teams; the engineer's queue in ServiceNow with the summary on top
Technologies used
predicts category, urgency, affected service and sentiment; extracts fields with confidence scores
Aapply the matrix, update tickets, run the SLA time triggers, retry, log and audit
Aevent triggers on new tickets and mail, field updates, escalation messages in Teams
Adispatcher decisions on uncertain tickets without leaving Teams
Athe two-line summary an engineer reads first, under AI Trust Layer policies
Arequester attributes and group membership used by the routing rules
Arouting accuracy, corrections, time to assignment and SLA attainment by group
AIllustrative economic model
The arithmetic is open, so it can be argued with.
Reading, deciding and dragging: that is all the six minutes cover; the engineer's work stays outside this table. The calculator prices only the share the model handles without a dispatcher decision, 85 tickets in 100, so the volume below is 5,440 rather than 6,400; that share is reached after training on the centre's own tickets and starts lower. €39 is a fully loaded hourly cost in a Central European shared-service centre. Rework behind misrouted tickets sits in the cost-of-inaction table instead: 768 tickets a month × 15 minutes across two groups = 192 h, or €7,488 a month. Nothing here was measured at a client.
Run the numbers on your data
An illustrative estimate from your own inputs. It models released capacity; it is not a promise of savings.
Business benefits
- Tickets reach the right group within minutes of arrival rather than after the dispatcher's next free moment, whatever the shift
- Priority reflects business impact, because the rules read the affected service and the number of users rather than the subject line
- Misrouting falls, and with it the day a ticket loses while two groups pass it back
- A P1 is escalated by the clock, so nobody discovers an unacknowledged outage from an "any update?" comment
- Dispatchers move from reading everything to deciding the hard cases and owning the matrix, the part that needed their experience
- A second business unit or intake channel is added by training the model and extending the matrix, not by hiring another reader
The management view
- Triage becomes a measured step: routing accuracy, correction rate, time to assignment and SLA attainment by group, taken from ticket data rather than anecdote
- Escalation turns from a policy someone remembers into a control that executes, with a log of every alert and who acted on it
- Capacity is planned on categories that mean the same thing on every shift, so a trend in the numbers is a trend in demand
- The dispatcher's queue holds only the cases the model was unsure about, and its size shows how well the matrix fits reality
Board-level KPIs
Security and governance
Trust in automation is built on the audit trail, not on a promise.
- Ticket text often carries personal data, so AI Trust Layer policies mask personal identifiers before any model call, restrict models to your allow-list and pin LLM region routing; Communications Mining runs in the EU region of UiPath Automation Cloud and the ticketing data stays in your tenant
- The robot's service account may change category, priority, group and summary fields on the defined queues and nothing else: it cannot close, delete or assign to a person, and its secret sits in a credential store, not in a workflow
- Every prediction, confidence score, rule fired and human correction is written to the audit log, so an auditor can reconstruct how any ticket was prioritised and by whom
- The routing matrix and the priority definitions are versioned and changed only by their named owner; a retrained model goes live only after the monthly review of corrections; broker escalations are tagged at intake and kept under your Microsoft Purview retention policies
Why now
The trigger is usually a consolidation: a second business unit, a merged desk or a new intake channel that the current dispatch team cannot read; here the second unit arrives next year, on top of the modelled €21,216 a month of dispatcher reading
Communications Mining reads emails, tickets and chats in one model, and the Integration Service connectors for ServiceNow and Jira carry events both ways, so triage runs beside the ticketing tool without a migration
Broker and partner escalations now share the queue with internal tickets, and a partner who waits fifty minutes for an acknowledgement tells others
Relevant executive roles
SLA attainment becomes a real figure rather than a report built on corrected priorities, and the desk absorbs a second business unit without a second dispatch shift
engineers receive tickets that are correctly routed and summarised, so their first touch is work rather than reading
the same triage layer serves HR, finance and facilities queues once IT has proven it on its own tickets
broker and partner escalations are prioritised on impact and never lost behind internal noise
Common questions and objections
Variety is the reason to use a model rather than keyword rules. Shadow mode shows the accuracy on your own tickets before anything is written, and below the threshold a ticket goes to a person with the prediction attached.
Some of them classify tickets that arrive through the portal. Few read two shared mailboxes and a Teams channel, apply your matrix rather than their own, escalate on timers and hand uncertain cases to a person with the evidence attached; where the platform's own feature covers a step, we use it.
They stop reading 6,400 tickets and start deciding the ones the model is unsure about, owning the matrix and reviewing accuracy, the part that needed them; here the released capacity is what the second business unit requires.
When this is not the right solution
- Fewer than about a thousand tickets a month, or tickets arriving only through a portal whose mandatory fields are actually filled in: a few rules cost less than a model
- No usable ticket history to train on, or a ticketing migration due within months; build after the migration
- Nobody can be named as owner of the routing matrix; without an owner the model learns yesterday's inconsistency and keeps it
A question for the next management meeting
Ten P1 tickets, the most recent ones: which of them was a P1 before a person read it, and how long had the clock been running when somebody decided?
Implementation approach
Delivery runs in stages, so it can be stopped at any point.
We deliver
- Analysis of one quarter of tickets: routing accuracy, time to assignment, the matrix as actually applied
- Communications Mining training on your ticket history, with labelling sessions for your dispatchers
- The priority and routing rules, the confidence threshold and the exception design for uncertain tickets
- Integration with ServiceNow or Jira Service Management, the shared mailboxes and the Teams channel
- Escalation timers, the dispatcher task in Teams, shadow-mode testing and deployment group by group
- The Power BI dashboard, documentation, dispatcher training and ongoing monitoring
We need from you
- A ticket export covering at least a quarter, with categories, groups, priorities and reassignment history
- A dispatcher as product owner and an agreed priority matrix
- A ServiceNow service account limited to field updates on the relevant queues, plus access to the mailboxes and the Teams channel
Stages
Discovery
Baseline from the ticket export: routing accuracy, time to assignment, the matrix as applied today
Design
Label set, priority and routing rules, confidence threshold, escalation timings, security model
Train
Model training on historical tickets, dispatcher labelling of a calibration sample, threshold tuning
Shadow mode
The model predicts on live tickets while dispatchers still assign, until the pilot group meets the agreed accuracy
Go-live
The robot starts writing fields for the pilot group, then further groups and channels, with hypercare
Optimisation
Monthly review of corrections, retraining, matrix changes, the second business unit onboarded
Departmental. Effort depends on the number of assignment groups and genuinely distinct categories, how usable the ticket history is as training material, and how many intake channels carry free text.
The ticket marked URGENT asks for a monitor. The outage is filed under "question".
Send us 500 anonymised tickets from last quarter with the group each one ended in. You get back the share the model categorises correctly, the cases where a dispatcher would still decide, and a short read-out call on the numbers.
Test the model on 500 of your ticketsThe neighbouring process usually has the same problem
Your best agents spend their morning sorting mail instead of answering it.
View solution Other solutionsThe service desk request that never becomes a ticketFour IT tickets in ten follow a known procedure, and every one of them still queues for an analyst.
View solution Other solutionsIncidents staffed, communicated and closed by one flowThe tool records what happened. Finding owners, chasing updates and reading nothing on Friday is done by people.
View solutionIndustries we deliver this in most oftenManufacturing & industryTransport & logisticsServices & ITShared services