Home · Solutions · Other solutions
Solution · Other solutionsAn account manager gets a factual card in seconds instead of interrupting the engineer
Who is on call and what is down, answered in Teams
Monitoring alerts arrive in Microsoft Teams already carrying the service, the on-call engineer, the affected customers and the open tickets, and anyone can ask the same questions in a channel.
Executive summary
During an outage the person fixing it is also the only one who can say which customers are affected.
We connect facts that already exist to the channel where they are asked for.
The on-call engineer stops being the switchboard, so time to restore improves by the minutes that went into answering questions.
Microsoft Teams channels; the public status page; Jira Service Management
Business problem
Engineering
An engineering organisation usually has every fact it needs and no way to serve them. On-call schedules live in the paging tool, which only engineers open. Service health lives in Azure Monitor and Application Insights, which show metrics rather than customer names. The mapping from a service to the customers who depend on it lives in a spreadsheet maintained by one solutions architect. Customer tickets sit in the service desk, unlinked to the incident.
So every outage produces a second incident: the flood of questions aimed at the people fixing the first one. Account managers guess, support triages duplicates by hand, the status page lags behind reality, and the customer often learns more from their own monitoring than from their supplier. It persists because each tool belongs to a different team and none of them owns the question.
The three questions are always the same. Who is on call for this service, what is currently down, and which customers are affected. Nobody has decided that answering them is a job, so it is done by whoever is closest to the keyboard, which during an outage is the person who should not be interrupted at all.
How it works today
The sequence below is what an outage looks like before anything is connected.
- PersonAn alert fires in Azure Monitor and the paging tool calls the on-call engineer, who starts diagnosing
- PersonAn account manager hears from a customer and asks in three channels at once
- WaitingSomebody guesses who is on call; the correct answer arrives after the second or third message
- PersonSupport logs duplicate tickets one at a time, each describing the same symptom differently
- PersonCustomer success asks engineering which customers are affected; the solutions architect opens her spreadsheet
- Risk of errorThe status page is updated late and by hand, so the customer's own monitoring is faster than the supplier
- WaitingThe uptime report is assembled after the quarter from alert history rather than from a record
Why the current process costs more than it appears
The most expensive part of this process has no cost line.
- Every question put to the on-call engineer lengthens the outage. The interruption is charged to the customer in minutes of downtime, not to a cost centre in hours.
- Duplicate tickets cost support time twice: once to triage nine descriptions of one fault, and once again when nine customers receive nine slightly different answers.
- Slow or wrong customer communication is what turns an outage into a credit claim or a renewal conversation. The technical fix rarely does that on its own.
- One architect holds the service-to-customer map, so when she is on holiday nobody can say who is affected, and the answer during an incident becomes a guess with a customer name attached.
- Uptime assembled after the fact from alert history is not evidence. When a customer disputes a service level, both sides argue from memory and the supplier usually concedes.
Cost of inaction
Customer count is what moves these rows. Every new customer widens the blast radius of the same incident: more people ask, more duplicate tickets arrive, and the same engineer answers all of them while trying to fix the fault. New services multiply the mappings nobody maintains, and support headcount then grows with duplicates rather than with customers.
The costs outside the table are the ones a customer service director looks at first. An outage lasts longer because the person fixing it was answering questions; a service credit is claimed under a contract that specifies communication times; a customer learns about the incident from their own monitoring. The architect who keeps the map in a spreadsheet is the same risk in a different shape, and she is promoted or leaves like anyone else.
A plausible organisation with realistic proportions. The figures are there to be recalculated on your data; they are not a client result.
An illustrative logistics-software provider, 210 employees of whom 60 are engineers, serving 1,400 business customers from a platform on Azure with Azure Monitor and Application Insights. On-call runs in a paging tool, customer tickets in Jira Service Management, the customer base in a CRM.
About 320 operational questions a month asked in Microsoft Teams, and around 9 customer-affecting incidents a month, each producing a wave of duplicate tickets. Contractual uptime reports for the largest customers are assembled by hand every quarter.
The paging tool posts the raw alert, everyone else asks in a channel, and the spreadsheet decides who is affected. Nothing links the customer tickets to the incident they describe.
The on-call engineer is the switchboard and the fixer at the same time, and the only person who can map a service to a customer is one solutions architect.
Alerts arrive enriched: service, on-call engineer, affected customers, open tickets, all on one card in Microsoft Teams. The same lookups answer questions posted in an ask channel, duplicate tickets are linked, and uptime becomes a record instead of a reconstruction.
In the modelled case most operational questions are answered without an engineer, the customer-impact card exists within minutes of the alert, and the quarterly uptime report needs no assembly. Illustrative throughout; the arithmetic is ours, not a client's.
Proposed solution
We connect facts that already exist to the channel where they are asked for. An Azure Monitor alert rule fires, its action group calls an Azure Logic App, and the Logic App starts a job through a UiPath Orchestrator API trigger. A UiPath Robot then does the work a person does today: it resolves the service, reads the customers that depend on it from a service-to-customer map held in UiPath Data Fabric, looks up the on-call engineer in the paging tool through a Connector Builder connector, and pulls the open tickets with the same symptom from Jira Service Management.
What comes out is one card, not a raw alert. The operations channel gets service, engineer, ticket count and current state; customer success gets the same incident expressed as customer names and contract tiers. Adaptive Cards update in place, so the card in the channel keeps pace with the incident instead of becoming a fossil three messages up. When something must be said publicly, customer success confirms the wording in Teams and the robot does the typing on the status page and links the duplicate tickets to the incident.
The second half is quieter and answers more questions than the alerts do. In a dedicated ask channel, anyone can post a short request, on-call for a service, status of a service, impact for a customer, ticket status, and the Microsoft Teams connector's message trigger runs the same lookups and returns a factual card. Nothing is generated: every answer is a lookup, which is what people on an incident bridge are prepared to trust. Power BI then reports uptime per service and per customer from the incident record, and UiPath Insights shows how many questions were answered without an engineer.
Azure Monitor alert rules, action groups and Application Insights availability tests; Microsoft Teams channels and Adaptive Cards with Universal Actions; UiPath Orchestrator API triggers, queues and audit log; the Microsoft Teams connector's Message Posted trigger
The service-to-customer map and the robot that keeps it honest, the enrichment and card logic, the ask-channel command handling, the incident record and the uptime report
Connector Builder connectors for the paging tool, the status page and the CRM; UiPath Integration Service connectors for Microsoft Teams, Jira and Microsoft Azure
How the automated process works
- AutomationAn Azure Monitor alert fires and its action group starts the enrichment through a Logic App and an Orchestrator API trigger
- SystemA robot resolves the service, reads the on-call engineer from the paging tool and pulls the open tickets with the same symptom
- AutomationCards land in the operations and customer-success channels: service, engineer, affected customers, open tickets, one view
- PersonCustomer success confirms the customer-facing wording before anything leaves the building
- AutomationThe robot updates the status page, links the duplicate tickets to the incident, and refreshes the cards as the state changes
- AutomationAnyone posting a question in the ask channel gets a factual card back from the same lookups
- SystemThe incident record closes, uptime per service and customer is updated, and the quarterly report needs no assembly
Human-in-the-loop model
Automation handles
- Enriching every alert with service, affected customers, on-call engineer and open tickets
- Posting and refreshing cards in the operations and customer-success channels
- Answering the standing questions in the ask channel from the same lookups
- Linking duplicate tickets to the incident and maintaining the uptime record
People decide
- The on-call engineer diagnoses and fixes; nothing in the flow touches that work
- Customer success approves the wording before the status page changes
- The platform team owns the service-to-customer map and every change to it
- Engineering management decides what counts as an incident for contractual purposes
Before and after
Systems and integrations
Where a rule suffices we do not use a model. Where judgement is needed, a person decides.
Inputs
- Azure Monitor alert rules
- Application Insights availability tests
- the paging tool schedule
- Jira Service Management tickets
- CRM subscription data
Automation layer
- UiPath Orchestrator
- UiPath Robots
- UiPath Integration Service and Connector Builder
- UiPath Data Fabric
Target systems
- Microsoft Teams channels
- the public status page
- Jira Service Management
- Power BI
Human touchpoints: confirmation of customer-facing wording in Microsoft Teams; the ask channel; the platform team's monthly map review
Technologies used
alert rules and availability tests produce the signal; action groups start the enrichment
Athe action-group target that calls the Orchestrator API trigger
Aenrich the alert, run the lookups, post and refresh cards, link duplicate tickets, log every action
AMicrosoft Teams, Jira and Microsoft Azure connectors; custom connectors for the paging tool and status page
Awhere the cards land and the questions are asked; the Message Posted trigger answers them
Athe service-to-customer map and the incident record, with an owner and a change history
Auptime per service and per customer, built from the record rather than from alert history
Aquestions answered without an engineer, time from alert to customer-impact card
AIllustrative economic model
Start by questioning the assumptions.
Fifteen minutes is not one person's time; it is the asker's and the answerer's added together, which is why it looks generous for a question with a one-line answer. The 80 % share the assistant can settle is folded into the volume, so the calculator runs on 256 questions a month rather than 320, and €73 is a fully loaded engineering hourly cost. Two pools stay outside the calculator: incident coordination of 108 incidents a year at 40 minutes for three people, about €15,768, and 22 duplicate tickets per incident at five minutes of support triage, about €7,326. 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
- The on-call engineer stops being the switchboard, so time to restore improves by the minutes that went into answering questions
- Account managers get a factual card in seconds instead of guessing, so customers hear the truth from their supplier first
- Support triages one incident rather than nine symptoms, because duplicate tickets are linked as they arrive
- The status page reflects reality within minutes, since a person only has to say yes to wording somebody else prepared
- Uptime per customer becomes a record, so a contractual report is produced rather than reconstructed under pressure
- The service-to-customer map turns into a maintained asset with an owner, instead of one architect's spreadsheet
The management view
- Every active incident is visible with its customer impact and its owner on a single card, without a call to find out
- Interruptions to engineering become measurable, because questions go to a channel that logs them
- Support and engineering share one incident record, which ends the argument about how many tickets an outage produced
- The board's question about last month's uptime is answered from data rather than from a meeting
Board-level KPIs
Security and governance
An auditor should be able to reconstruct every decision.
- The robot reads monitoring, schedules and tickets with read-only credentials; its only write actions are posting cards, linking tickets and updating the status page
- Nothing reaches the public status page without a named person confirming the wording in Microsoft Teams, and that confirmation is part of the incident record
- Customer names appear in internal channels restricted to operations and customer success, and are never written to a public surface by the automation
- Credentials are held in Azure Key Vault and reached through the Orchestrator credential store; the service map is a governed Data Fabric entity with an owner and a change history
- The incident record is retained under a Microsoft Purview label for the length of a contractual dispute, and processing stays in your Microsoft 365 tenant and the EU region of UiPath Automation Cloud
Why now
Enterprise contracts increasingly write down how quickly a customer must be told about an incident, which turns status communication from a courtesy into a term with a credit attached to it
Azure Monitor and Application Insights already carry the health signal, and their action groups start an automation directly, so the enrichment layer is configuration plus a small build rather than a platform project
The modelled €4,672 a month is engineering time spent answering instead of fixing, and those are precisely the hours that cannot be bought back once an outage has started
Relevant executive roles
Engineers fix instead of answering, and the platform's health becomes visible to the business without translation
On-call load drops, and interruption becomes a measured number rather than a recurring complaint
Customer impact is known in minutes, so operational decisions during an incident are made on facts
Support handles one incident instead of nine tickets, and customers hear from the supplier first
Common questions and objections
It posts the alert. It does not say which customers depend on the service, which tickets already describe it, or who else is asking the same thing. The enrichment is the product, not the notification.
It is the channel they already use, and what changes is that answers replace questions. The people who gain most are the account managers who stop asking engineers anything.
Agreed, and they do. The card proposes wording and impact, a named person confirms, and the robot does the typing so nobody retypes under pressure.
When this is not the right solution
- No monitoring with service-tagged alert rules; the signal has to exist and be attributable before it can be enriched
- A single product with a handful of customers, where the on-call engineer can simply tell everybody in one message
- Fewer than about twenty engineers, where a pinned schedule and one channel already do most of this
A question for the next management meeting
During last month's outages, who could answer the question "which customers are affected" without interrupting the engineer who was fixing the fault?
Implementation approach
We start with one slice of the process and extend only once it is proven.
We deliver
- A month of Teams questions and the last ten incidents, categorised into what a card must contain to be useful
- The service-to-customer map built from CRM and subscription data, with a named owner
- The enrichment robot, the cards, the ask-channel commands and the status-page step
- The incident record and a Power BI uptime report per service and per customer
- Testing on replayed incidents before live ones, plus a short guide for account managers and support
We need from you
- Alert rules tagged by service, and API access to the paging tool and the service desk
- CRM or subscription data that says which customer uses which service
- A named owner for the map and one person in customer success who confirms wording
Stages
Discovery
One month of questions and ten incidents; the contents of each card agreed with the people who ask
Design
Card layouts, command set, escalation rules, the map model and its ownership
Build
Enrichment robot, connectors, Teams cards, incident record and the uptime report
Validation
Replayed incidents first, then live alerts for one product with the old habits alongside
Go-live
Full alert coverage, the ask channel opened to account managers and support, hypercare
Quick win. Effort is driven by how well alert rules are tagged by service, whether the paging tool and status page expose usable APIs, and how much work the first version of the service map needs.
Twenty people ask three questions; one of them is also fixing the fault.
List the ten questions your engineers are asked most during an outage and send us one month of incident and ticket history. You get back which of those a card can answer on its own, and an estimate of the interruption time it removes.
Send your top ten outage questionsThe neighbouring process usually has the same problem
Monthly SLA reports are rebuilt in Excel from ticket exports, and the customer finds the service credits first.
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 solution Other solutionsStatus, outage and change news that reaches people firstThe outage email leaves after the outage, and one ticket comment in five is the same two words.
View solutionIndustries we deliver this in most oftenServices & ITFinance & insurance