Home · Solutions · Other solutions
Solution · Other solutionsEvery ticket, incident and change sends its own message to the people it affects
Status, outage and change news that reaches people first
Ticket state changes, declared incidents and approved changes produce an approved message to a resolved audience in Microsoft Teams, with one approval tap for anything company-wide.
Executive summary
The outage email leaves after the outage, and one ticket comment in five is the same two words.
The events already exist.
Status questions fall away, because every state change reaches the requester in Teams with the next step attached.
Microsoft Teams; Outlook and Exchange Online; the SharePoint status page
Business problem
IT communications
Communication about IT events is manual, late and untargeted. Ticket status lives in the ticketing tool, where requesters do not look, so they ask instead. An outage message needs somebody to notice it, somebody to write it and somebody senior to approve it, and each step waits for the one before.
Audiences are guessed. The message goes to all staff because nobody knows who uses the affected application, and the CMDB entry mapping it to sites and user groups has never been used for distribution. Change notices go out once, a week ahead, and are forgotten by the day of the change.
The desk absorbs the consequence: status calls, duplicate incident tickets for one outage, complaints about changes nobody remembers being told about. The problem survives because the information sits in three systems and the audience in a fourth, and nobody has joined them. Sending is a person's task, so it happens when that person is free.
How it works today
- SystemA ticket changes state in ServiceNow and nobody outside the tool sees it happen
- PersonThe requester adds "any update?" as a comment, or telephones the desk to ask it
- PersonAn analyst types a reply that repeats what the record already says
- PersonAn outage is recognised from the volume of calls; the incident manager opens Word and starts drafting
- WaitingThe draft waits for a wording check from the IT director in a Teams chat
- Risk of errorThe email leaves after the service is back, addressed to all staff, so fewer people read the next one
- Risk of errorA change notice goes out once, a week ahead; the plants hear about it on the day, from the shop floor
Why the current process costs more than it appears
The bill that never reaches the budget.
- Duplicate incident tickets during an outage distort the record and the SLA report, so capacity is planned on numbers that describe the confusion rather than the demand.
- Untargeted all-staff email teaches people to ignore IT messages, so the important one is missed as well; credibility spent on a routine notice is not available for a real one.
- Plant managers lose planning time when they hear about a change from the shop floor, and the shift plan made a week earlier is what pays for it.
- During a live incident the incident manager's attention is the scarcest resource in the room, and drafting prose consumes it at the worst moment.
- Messages sent by hand leave no evidence: after an incident nobody can show who was told what and when, so the review argues from recollection.
Cost of inaction
Each acquired site and each new plant adds an audience nobody has mapped, so messages get broader and less read, and the broader they get the less the important one is noticed. Status contacts grow with ticket volume, ticket volume grows with headcount and systems, and the drafting keeps happening in the middle of an incident. Twelve months on, the reviews still cannot show who was informed when, the plants still say nobody told them, and IT still answers that a notice was sent. A small tax, collected daily, that never appears as a line in any budget.
A plausible organisation with realistic proportions. The figures are there to be recalculated on your data; they are not a client result.
A manufacturing company, 4,500 employees across three plants and a head office; ServiceNow for tickets, incidents and changes; Microsoft 365; a CMDB whose mapping of applications to sites exists but is not used for distribution.
About 840 status-related contacts a month (comments, calls, Teams messages) and 24 incidents and change windows needing a communication, each about 50 minutes of incident-manager time to draft, approve and distribute.
Status is asked for rather than sent; outage messages are written in Word, reviewed in a chat and mailed to all staff; change notices go out once. Plant managers have asked twice for earlier and narrower notice.
Every message waits for a person to notice an event and write text, and every audience is guessed, so messages are at once too broad and incomplete.
Orchestrator event triggers on the ServiceNow records; a robot that picks the approved template, resolves the audience from the CMDB and Microsoft Entra ID groups and sends an Adaptive Card in Microsoft Teams; one approval tap for anything company-wide; a SharePoint status page and a delivery record on the event.
In the modelled case three status contacts in four never reach the desk, an outage message leaves within minutes of the declaration rather than after it, and every change window carries three notices to the affected sites. Illustrative, not a client result.
Proposed solution
The events already exist. A ticket changes state, an incident is declared, a change is approved for a date: each is a record in ServiceNow, and each is a message somebody should have received. Orchestrator event triggers read those records through UiPath Integration Service, so the message follows the event, not somebody's availability.
For each event a UiPath Robot selects the approved template and resolves the audience: the requester for a ticket update, and for an outage or a change the users of the affected application, from the CMDB relationship and the matching Microsoft Entra ID groups by plant and role, evaluated at send time rather than from a hand-kept list. Ticket updates go out as Adaptive Cards in Microsoft Teams carrying the state, the next step and the expected date; people without Teams open get the same text by email.
Anything company-wide, and every major incident message, stops at the incident manager, who approves or edits it as a UiPath Action Center task completed inside Microsoft Teams. Routine updates on an incident already declared go without approval, and a SharePoint status page carries the same facts. Change notices run on dates the change record sets: five days ahead, the day before and on completion, to the affected groups. Everything sent is written back against the event, which is what the post-incident review reads.
UiPath Orchestrator event triggers, time triggers, queues and audit log; UiPath Action Center tasks completed in Microsoft Teams; Adaptive Cards in Teams; Microsoft Entra ID groups; a SharePoint page for status
The template library and its versioning, the audience rules against the CMDB and directory groups, the sending robot and its fallback when a mapping is missing, the reminder schedule, the approval step and the delivery record
ServiceNow ticket, incident, change and CMDB reads and the delivery write-back through the UiPath Integration Service connector; Microsoft Teams and Microsoft Outlook 365 connectors for delivery; groups read through the Integration Service connector still named 'Microsoft Azure Active Directory'
How the automated process works
- AutomationAn event in ServiceNow, a state change, a declared incident or an approved change, fires an Orchestrator trigger
- AutomationA robot picks the approved template and resolves the audience from the CMDB relationship and the matching Entra ID groups
- PersonCompany-wide and major incident messages reach the incident manager as an approval task in Teams, text pre-filled and editable
- AutomationThe message goes out as an Adaptive Card in Microsoft Teams, and by email to people not in Teams at that moment
- AutomationThe SharePoint status page carries the same facts and the time of the next update
- AutomationChange notices follow the change record: five days ahead, the day before and on completion, to the affected groups
- AutomationWho was told what and when is written back against the event; a missing audience mapping or a failed send goes to the desk
Human-in-the-loop model
Automation handles
- Detecting the events: ticket state changes, incident declarations, approved change windows
- Resolving the audience from the CMDB and directory groups at the moment of sending
- Composing the message from the approved template and the event's own facts
- Sending, updating the status page, running the reminders and recording the delivery
People decide
- Declaring the incident, and approving or editing anything that goes company-wide
- Owning the templates, the tone and the audience rules
- Deciding when an unusual event needs a message the templates do not cover
Before and after
Systems and integrations
Where a rule suffices we do not use a model. Where judgement is needed, a person decides.
Inputs
- ServiceNow ticket, incident and change records
- the CMDB mapping of applications to sites and user groups
- Microsoft Entra ID groups by plant and role
Automation layer
- UiPath Orchestrator
- UiPath Robots
- UiPath Integration Service
- UiPath Action Center
Target systems
- Microsoft Teams
- Outlook and Exchange Online
- the SharePoint status page
- ServiceNow, which holds the delivery record
Human touchpoints: the incident manager's approval task in Teams; the template library owned by internal communications; the audience-rule review; the monthly communications report
Technologies used
event triggers on the ServiceNow records, time triggers for the reminders, queues and audit
Aresolve the audience, fill the template, send, update the status page and write the delivery record
AServiceNow events and reads; Microsoft Teams, Microsoft Outlook 365 and identity connectors
Athe incident manager's approval task, completed inside Microsoft Teams, approver recorded
Astatus, outage and change messages with the state, the next step and a button
Athe plant, site and role groups that decide who counts as affected
Athe same message by email for people not in Teams
Athe status page that stays current through an incident
AIllustrative economic model
Start by questioning the assumptions.
Productive time lost in the plants during an outage is the largest number in this case and the one we refuse to invent; it belongs in a conversation with the COO, not in these rows. The calculator prices the desk alone: of 840 status contacts a month, three in four become avoidable once status is pushed, which is the 630 the volume starts from, at 8 minutes each and €42 an hour fully loaded. The second pool sits in section 14: 24 communications a month at 50 minutes of incident-manager time, €71 an hour, is 20 hours and €1,420 a month; both together come to €4,948 a month. Licensing and implementation are outside the model, and nothing 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
- Status questions fall away, because every state change reaches the requester in Teams with the next step attached
- Duplicate incident tickets drop during an outage, since the people affected are told before they call
- Outage messages leave within minutes of the declaration: drafting is a template and approval is one tap
- Messages reach the sites and roles actually affected, which is what makes people read IT messages again
- Every communication carries a delivery record, so the post-incident review reads evidence instead of recollection
The management view
- Communication stops depending on who is free; the event sends the message, and the message leaves a record
- Status contacts become a measurable number, and their decline is direct evidence that requesters are being kept informed
- Plants get notice they can plan around, which turns an IT change from an interruption into a scheduled item
Board-level KPIs
Security and governance
Security is designed with the process, not after it.
- The robot sends under a dedicated service identity permitted to post to named Teams channels and to send from one IT communications mailbox, nothing more; its secret sits in the Orchestrator credential store
- Audiences are resolved from group membership and CMDB relationships at the moment of sending, never from hand-kept distribution lists, so leavers and movers drop out on their own
- Company-wide and major incident messages cannot leave without a recorded approval from the incident manager, captured in Microsoft Teams with the approver's identity and auditable in Microsoft Purview
- Templates are versioned and owned by internal communications; a change of tone is a change in one place, and the version sent stays attached to the event
- Message content carries no personal data beyond the requester's own ticket; processing runs in the EU region of UiPath Automation Cloud, with Microsoft 365 inside the EU Data Boundary
Why now
Employees read Teams, not the intranet, and an Adaptive Card carries the state, the next step and a button; in a plant that plans shifts a week ahead, an all-staff email no longer counts as having communicated
The webhook posting path many companies used for automated messages inside Microsoft Teams was retired in May 2026, so that route has to be rebuilt anyway; rebuilding it on event triggers rather than on a person noticing costs the same project
Desk minutes and incident-manager minutes together are €4,948 a month in the modelled case, spent on messages the systems involved already hold the facts to send
Relevant executive roles
IT's reputation in the business is set by how it communicates during an incident, and this makes that fast and evidenced
The desk stops answering questions the ticketing system already knows the answer to
Plants receive targeted, timely notice of outages and changes they can plan around
Tone and templates stay under their control without the team being on call for every outage
Common questions and objections
It sends email on state changes, which is not the same thing. What this adds is targeting from the CMDB, cards in Teams carrying the next step, an approval gate for major messages, and reminders that run on the change record's own dates.
They get fewer. Targeted messages replace all-staff email, and a status card replaces the reply an agent would otherwise type; what disappears is the volume nobody wanted.
Then the pilot starts with the two applications whose users you do know, and the gaps it exposes become the CMDB clean-up list, ordered by how many people each affects.
When this is not the right solution
- The organisation is small enough that one channel post reaches everyone who matters
- There is no CMDB and no group structure to resolve audiences from, and no appetite to build either
- The ticketing tool is being replaced within the year; build after the migration, not before it
A question for the next management meeting
Why did the plants hear about our last change from the shop floor, when the record with the date, the service and the affected sites had been sitting in ServiceNow since the approval?
Implementation approach
We start with one slice of the process and extend only once it is proven.
We deliver
- The target process for status, incident and change communications, drawn from last quarter's outage emails and the change calendar
- A template library agreed with internal communications, versioned and left in their ownership
- Audience rules against the CMDB and Microsoft Entra ID groups, with a defined fallback when a mapping is missing
- Event and time triggers, the sending robot, the approval task in Teams, the status page and the delivery record
- Testing beside the manual process, deployment, a short guide for incident managers and a monthly report
We need from you
- The CMDB mapping of applications to sites and user groups, in whatever state it is
- The Microsoft Entra ID group structure by plant and role
- An incident manager as owner of the flow, and internal communications as owner of the templates
- Last quarter's outage emails, the change calendar and a sample of status comments
Stages
Discovery
A week of reading: outage emails, the change calendar, status comments and the CMDB mapping as it stands
Design
Templates, audience rules, approval thresholds and the reminder cadence, each agreed with its owner
Build
Event triggers, the sending robot, the Teams approval task, the status page and the delivery record
Pilot
Status cards for one assignment group and outage messages for two applications with known user groups, run beside the manual process
Scale
More applications as their CMDB mapping is confirmed, then the reminders across the change calendar
Optimisation
A monthly report on status contacts, duplicate incidents and time to first message; rules tuned on what it shows
Quick win. The effort follows the state of the CMDB mapping and the number of distinct audiences, not the automation itself; the ticketing tool makes little difference.
One comment in five in your ticket queue is the same two words.
Send us last quarter's outage emails and one week of ticket comments. You get back an audience map for your five busiest applications and a written assessment of which messages could have sent themselves.
Send last quarter's outage emailsThe neighbouring process usually has the same problem
Every third customer contact asks where an order is; the answer already sits in SAP and the carrier portal.
View solution Other solutionsTickets triaged and routed before an analyst reads themPriority follows the requester's capital letters, and a P1 waits in the queue until a dispatcher has time to read it.
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