Home · Solutions · Customer service
Solution · Customer serviceEvery service level measured the way its contract says, and reported before month end
Service levels reported before the customer disputes them
Each contract's service levels, clock rules and credit formula are held once; robots calculate attainment, raise breaches while the month is running and build every customer pack.
Executive summary
Monthly SLA reports are rebuilt in Excel from ticket exports, and the customer finds the service credits first.
The design starts with a register rather than a robot.
The monthly pack stops being a construction job: the figures already exist, and the reporting date closes them.
SharePoint report library and evidence archive; Power BI semantic model; the customer's portal or the service mailbox
Business problem
Service level management
A service level agreement is a price for reliability, written down: what fast means for this customer, what counts as an interruption, when the clock runs and what the provider gives back when the promise does not hold. The measurement it implies is rarely simple. One customer's P1 clock runs around the clock, another's stops at six in the evening and over public holidays, a third pauses whenever a ticket sits with the customer's own network team.
The provider's tools measure one standard, because that is how they were configured. Everything a negotiation added afterwards lives outside them: the exclusion for planned maintenance in the third annex, the pause an account director conceded by email, the credit formula that steps up after a second breach. Reconciling platform with contract is the monthly work, and it happens in a spreadsheet.
Who feels it is specific. The service delivery manager loses days each month to assembly rather than service, the account manager defends a number they cannot reconstruct, finance accrues credits from an estimate until procurement issues a claim. The customer has meanwhile built a shadow measurement of their own, because a report landing on the fifteenth working day is not something anyone can act on. The rules themselves live in the heads of three or four managers, so when one leaves, a measurement rule is reconstructed from the PDF mid-dispute.
How it works today
- PersonA service delivery manager exports last month's tickets from the ITSM platform, one workbook per customer, then strips out hold periods, maintenance windows and third-party waits by hand against the status history and the annex
- SystemResponse and resolution clocks are recalculated in Excel against each customer's coverage calendar, because the platform measures only its configured standard
- Risk of errorService levels whose measurement rule was agreed in a side letter are calculated from memory, and two managers reach two different figures
- PersonThe Word pack is assembled: attainment table, incident narratives, last month's commentary edited over
- WaitingPacks wait for the account manager to read them and leave between working day ten and working day twenty
- Risk of errorCredit exposure is worked out only when a customer asks, or when procurement raises it at the quarterly review
Why the current process costs more than it appears
The cost grows where nobody is looking.
- Assembly time is the part that can be counted, and it is not where the money is. A service level failing structurally, in the same week of every month, stays invisible until a customer names it, because nobody holds the trend.
- Credits discovered by the customer are negotiated, not calculated. Once procurement arrives with a number of its own, the conversation is about the gap between two spreadsheets, and the provider concedes to protect the relationship rather than because the contract says so.
- Exclusions never applied are money given away quietly. A pause the contract allows only reduces a breach if somebody remembers it as the report is built.
- Late reporting removes the one month in which anything could have been done: a breach described four weeks after the incident is history, while the same breach flagged on day eight is a staffing decision.
Cost of inaction
Renewal is where the invisible cost lands. A customer who spent two years building an SLA spreadsheet of their own arrives trusting their numbers more than yours, and the discussion starts from theirs. Every credit conceded to close it is a discount granted without a decision, and it never appears in a budget line called reporting.
The second cost is concentration. Three or four managers hold the measurement rules for forty-five contracts, and each is one resignation away from figures nobody can reproduce. A customer audit asks the same question eventually: show us how you reached this number, and that you reached it the same way last year.
A plausible organisation with realistic proportions. The figures are there to be recalculated on your data; they are not a client result.
A managed services provider in Central Europe, about 600 people, running application and infrastructure support for corporate customers in several countries; ServiceNow as the ITSM platform, Microsoft 365 E3 with Teams as the daily environment.
45 customer contracts carrying 210 service levels and roughly 14,000 tickets a month; 45 packs leave monthly, each covering two to nine service levels, with coverage windows from office hours in one country to genuine 24/7.
Every pack starts as a ticket export into a workbook. Hold periods and maintenance windows are removed by hand against the annex, clocks are recalculated in Excel, and a Word template takes the attainment table and last month's commentary edited over.
Roughly 70 minutes of assembly per pack, concentrated into the first two weeks, plus the rework after every challenge. Nothing in the routine produces a credit figure until somebody claims one.
Each contract's service levels, coverage windows, pause events, exclusions and credit formula are entered once into a versioned register. Robots read ticket data nightly, apply each contract's own clock, calculate attainment and credit exposure daily, raise breaches in Teams during the month and build each pack for sign-off.
In the modelled case the pack becomes a review instead of a build, a breach is known within a day rather than four weeks later, and the credit figure the customer receives is the one finance already accrued. None of this is a client result; it is what the assumptions of the illustrative model produce.
Proposed solution
The design starts with a register rather than a robot. Every service level in every contract is entered once as data: metric, target, priorities covered, coverage calendar, the events that start and pause the clock, the exclusions allowed and the credit formula. It is a versioned SharePoint list with a named owner, so changing a measurement rule is an approved edit with a date on it rather than a new understanding in somebody's head.
Against that register the calculation is deterministic. Robots read tickets, incidents and status history from the ITSM platform nightly, replay each ticket against the service level governing it, and produce attainment, breach counts and credit exposure. The month-end figure is a confirmation rather than a discovery: a service level crossing its warning threshold on day nine raises a card in the service delivery channel in Teams while a month remains to influence.
On the reporting date the pack builds itself: the Word report in the layout that customer agreed, an Excel annex listing every ticket that entered the calculation with its clock events, and links to the evidence. The service delivery manager writes the commentary and signs it off in the Microsoft Teams Approvals app, the only mandatory human step. Mientha runs 24/7 support under service levels of its own, so the uncomfortable cases are familiar: the clock running at three in the morning, the pause a customer disputes, the maintenance window that overran.
UiPath Orchestrator queues, time triggers, credential stores and audit log; UiPath Integration Service connectors for ServiceNow, Jira, Microsoft Teams and Microsoft OneDrive & SharePoint with its Excel Online activities; SharePoint lists with version history; Microsoft Teams Approvals app; Power BI semantic models in a Teams tab
The register and its schema, the clock engine (coverage calendars, priority scope, pause events, exclusions), attainment and credit calculation per contract, warning thresholds and alerting, pack generation in your templates, the sign-off route, the trend model
Extraction from an ITSM platform outside the connector catalogue, built with UiPath Integration Service Connector Builder against its REST API; a read of monthly service charges from billing where credits are a percentage of them
How the automated process works
- AutomationA nightly job reads tickets, incidents, status history and maintenance windows from the ITSM platform and files each record against its contract
- SystemRobots apply each service level's own clock: coverage window, priority scope, pause events and the exclusions the register holds
- AutomationAttainment, breach counts and credit exposure are recalculated daily, so the month-end number is closed rather than assembled
- PersonA service level crossing its warning threshold raises a Teams card to the service delivery manager, with the tickets and the rule behind it
- AutomationOn the reporting date the pack is generated per contract: Word report, Excel annex, evidence links and a draft commentary carried forward from the alerts raised
- PersonThe manager finishes the commentary and signs the pack off in Teams; a figure they dispute goes back with the clock events behind it
- AutomationSigned packs go to the customer's SharePoint area or the service mailbox, and the register records what was reported, when and by whom
Human-in-the-loop model
Automation handles
- Collection of tickets, incidents and status history from the ITSM platform, filed against the contract and service level that govern them, then measured with the clock rules the register holds for each: coverage calendar, priority scope, pause events, maintenance windows and exclusions
- Calculation of attainment, breach counts and the credit exposure each breach implies under the contract's formula and cap
- Generation, versioning and distribution of the pack, with the evidence behind every figure attached
People decide
- Whether an exclusion applies where the contract is ambiguous, with the reasoning recorded against the service level
- The commentary: what caused a breach, what has been changed, what the customer should expect next month
- Whether a credit is claimed, waived or negotiated, and every change to the register itself: new contracts, renegotiated targets, amended credit formulas
Before and after
Systems and integrations
Everything below runs on licences and systems you already hold, or would need anyway.
Inputs
- ITSM tickets, incidents and status history
- the service level register on SharePoint
- coverage calendars and maintenance windows
- monthly service charges from billing
Automation layer
- UiPath Orchestrator
- UiPath Robots
- UiPath Integration Service
Target systems
- SharePoint report library and evidence archive
- Power BI semantic model
- the customer's portal or the service mailbox
Human touchpoints: Teams breach alerts; Teams Approvals sign-off per pack; the Power BI trend tab in the delivery channel
Technologies used
run the nightly extraction and monthly pack generation on time triggers, queue every contract, keep the audit trail
Aread tickets, incidents, status history and maintenance windows through the API, not the screens
Apost breach alerts, write packs and evidence to the library, maintain the register
Aholds the versioned service level register and the evidence archive, one area per customer
Abreach alerts during the month, sign-off of every pack before it leaves
Athe customer-facing report and the annex behind it: every ticket that entered the calculation
Aattainment and credit exposure by contract, service level and month, as a Teams tab
AIllustrative economic model
A model, not a promise.
Seventy minutes is what one pack costs end to end: the export, the clock corrections made by hand, the template, the commentary and one read before it is sent. It is an assumption for this illustrative provider, not a stopwatch reading at a client, and €36 is a fully loaded hourly cost for a service delivery role in Central Europe. Only assembly is priced; credits paid, disputes and the revenue effect at renewal are left out.
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 monthly pack stops being a construction job: the figures already exist, and the reporting date closes them
- Breaches reach the service delivery manager while the month can still be influenced, not four weeks later
- Credit exposure follows the rule the contract states, so the report's number is the one finance accrued, and review meetings begin from a figure both sides can trace to individual tickets
- A new contract means adding its service levels to the register rather than a customer to somebody's monthly routine, and packs leave on the same day each month whoever is on holiday
The management view
- Attainment and credit exposure across the contract base become one number the board can see, split by customer and service level
- Structural weakness becomes visible: the service levels failing in the same week every month, or only inside one customer's coverage window
- Renewal and pricing conversations are prepared with the provider's own evidence, and the measurement rule survives the departure of whoever negotiated it because it is written down, versioned and owned
Board-level KPIs
Security and governance
The automation holds exactly the rights it needs, and not one more.
- Robots read the ITSM platform through a dedicated service account with rights on ticket and incident data only, and change nothing in the system they measure
- Every figure keeps its inputs: ticket identifiers, clock events applied and the register version in force that month, so it can be reproduced a year later
- Each pack sits in the customer area on SharePoint in your tenant, under the access model already there, holding that customer's data only; robots work from an EU-region tenant of UiPath Automation Cloud, with their secrets in the Orchestrator credential store or Azure Key Vault
- Changes to a target, an exclusion or a credit formula are made by the named owner, approved and versioned; a robot never edits the terms it measures against
Why now
Customers measure their providers themselves now. Procurement teams pull data from the portal they were given and arrive at the quarterly review with a figure of their own; a provider whose number is late and hand-built negotiates from the weaker side of the table
The modelled €1,890 a month is the smaller argument. The larger one is that a month without a trend view is a month in which a structurally failing service level is renegotiated instead of fixed
The mechanics have stopped being a project: ticket data comes out of ServiceNow and Jira through catalogue connectors, scheduled runs and audit are standard Orchestrator features, and the pack, sign-off and trend view live in the Microsoft 365 tenant you already pay for
Relevant executive roles
Service performance stops being a monthly assertion and becomes a figure with evidence, ready before the customer's version arrives
Managers spend the month on the service, not the first fortnight on paperwork, and a failing service level is visible while it can still be corrected
Credit exposure is accrued from a calculation rather than an estimate, and what is conceded at renewal stops being an argument about whose spreadsheet is right
Common questions and objections
It reports the standard it was configured with, usually one clock for everyone. What it rarely holds is contract-specific coverage windows, negotiated exclusions and credit formulas, which is where disputes start. We take its raw data and apply your contracts.
You will see more of them, which is not the same thing. Providers usually find credits were conceded where an exclusion applied, and the ones genuinely owed arrive with evidence and a month's warning rather than as a renewal-call surprise.
That is the reason for a register, not an obstacle to one. Each contract's rules are entered once and versioned, the engine is common to all, and a new contract becomes a data entry task for the service delivery lead, not a development request.
When this is not the right solution
- A handful of contracts sharing one service level definition, where the report takes an hour and no negotiation turns on it
- The ITSM platform records no status history, hold periods or maintenance windows, so the clock rules have nothing to work with; ticket discipline comes first
- Service levels written loosely enough that attainment is a judgement, not a calculation; those contracts need renegotiating before anything can measure them
A question for the next management meeting
If a customer disputed last month's attainment this afternoon, could we reproduce every stopped clock behind the figure, and would the second calculation match the first?
Implementation approach
The first week looks the same at every client: we look at the data.
We deliver
- Your contracts, annexes and side letters read into a structured register: metric, target, coverage window, pause events, exclusions, credit formula and cap
- The clock engine, per contract rather than per platform default, fed by extraction from your ITSM platform through its API, with a parallel run across three closed months so both sides see where the rules and the old workbook disagree
- Pack generation in your own templates: Word report, Excel annex and evidence links, one set per customer
- Breach alerting and pack sign-off in Microsoft Teams, plus the Power BI model for attainment, credit exposure and weak service levels
We need from you
- Contracts and annexes for a representative set of customers, including side letters that changed a rule
- Read access to ticket, incident and status-history data, and three closed months of the packs you actually sent
- A named owner for the register, usually the service delivery lead, and a finance contact for the credit formulas
Stages
Discovery
Contracts, annexes and side letters read into one register, with the exceptions your managers carry in their heads written down
Design
Clock rules, exclusion logic, credit formulas, thresholds, pack layouts and the sign-off route
Build
ITSM extraction, calculation engine, pack generation, Teams touchpoints and the Power BI model
Parallel run
Three closed months recalculated and compared line by line with the packs you issued
Go-live and tuning
One segment first, then the rest of the base; new contracts added by the register owner and thresholds tuned as cycles run
Departmental. Effort is driven by how many measurement rules genuinely differ between contracts, how completely the ITSM platform records hold periods, and whether credit formulas live in the contract or a spreadsheet.
Your customer's procurement team should not reach the credit number first.
Give us one contract, its service level annex and a month of ticket data. We return the attainment we calculate, the credit exposure it implies, and a written note wherever our reading of the clock rules differs from yours.
Recompute one customer's SLA monthThe neighbouring process usually has the same problem
Your agents are rated on five calls out of five hundred, and the other 495 are never opened.
View solution IT & servicesAccess requests and quarterly access reviewsManagers sign off on entitlements they cannot read, and nobody withdraws what nobody uses.
View solution Management & planningFrom project hours to the invoiceConsultants log hours late, finance rebuilds the billing in Excel, and invoices leave three weeks after the work.
View solution IT & servicesEvery laptop accounted for, from order to wipe certificateHardware ordered by email, handed over without a record, and written off when the auditor asks.
View solution Case study24/7 application supportWe provide round-the-clock support (24/7/365) for any business-critical application — in factories and companies of any industry.
View case study Case studyThe IT helpdesk agentPasswords, access, VPN, folder permissions.
View case studyIndustries we deliver this in most oftenTransport & logisticsServices & IT