SLA rule changes: what goes into the next report?

A new calendar from an agreed date

Suppose a client and service provider agree to extend support hours starting in the next reporting period. This changes the calendar used to measure the agreed service level, or SLA. The person preparing the report edits a shared calendar in their reporting spreadsheet. When they return to the previous month, they have to find the old settings to reproduce the earlier result.

In the proposed application, the service owner prepares a new rule version under that client's agreement. They record the revised calendar and the date it should take effect. The current version remains available. The reviewer can see what is proposed and which agreed change it is meant to implement.

Before approving it, the reviewer can compare the same sample of tickets under the current and proposed rules. Where results differ, they can open an explanation showing that the new calendar counts support time previously outside working hours. That preview helps them spot a change assigned to the wrong client or period before it is used in reporting.

The person responsible for the rules approves the version for use from the agreed date. Earlier reports retain a reference to the definitions used to produce them. The service manager can explain a previous result even after the team has moved to the new calendar.

Separate rules for each client

A shared template makes it easier to prepare another configuration. The service owner still needs to know which clients a change affects and who reviewed it. Extending one client's support hours should not accidentally change the rules applied to others.

The application can bring proposed changes together with their effective dates and assigned reviewers. The manager can see which version is a draft, which has been approved, and which applies to a particular period. A colleague taking over the client can read the reason for a change instead of trying to infer it from today's settings.

Your team translates client agreements into explicit measurement rules. If the date or scope needs clarification, the question goes back to the person responsible for those agreements. The application developer needs confirmed rules to implement the calculations and comparison preview.

What to check in your current helpdesk

Jira Service Management lets teams edit SLA goals, including the time target, priority, calendar, and conditions selecting the tickets covered. Start with those capabilities in your existing product and how your administrator uses them.

Use the last rule change to establish how your current tool retains earlier definitions, shows a proposed difference, and associates rules with a client and period. If its features support the review and approval you need, configuration may be enough.

An integration is worth considering when the helpdesk measures service performance well, but changes are prepared and approved in email or spreadsheets. It can connect an approved rule version to the system that applies it. The scope depends on what information the existing product makes available and how the team can confirm that the correct version was applied.

A custom application could cover preparing changes for several clients, comparing old and new versions, and approving them for use. The helpdesk would continue to manage tickets. This purchase makes sense when the team regularly reconstructs configuration decisions and existing features or extensions do not provide a convenient workflow for that work.

If your rules are already organized and the difficulty is collecting ticket histories every month, see our article on automating customer SLA reporting.

Rule history needs to move with the work

Launching the application requires current rules, pending changes, and references to definitions used in older reports. The team should identify which versions it can confirm from the available records. Today's calendar alone cannot reconstruct missing history. Older reports can remain in their existing archive if the necessary connections are preserved.

After launch, service owners still prepare and approve business rule changes. Agree with the developer who maintains the integrations and handles an approved version that was not applied in the reporting system.

When comparing a custom application with a packaged product, include ownership of the code and data, along with the access another company would need to take over maintenance. An export should contain rule versions with their dates, approval decisions, and references to the reports that used them.

How Syntalith can organize SLA rule changes

Through its custom software and integration services, Syntalith can build a workflow from a draft rule version and results comparison through approval and transfer to the system you use. Service owners have a place to prepare changes, and the manager can check their scope before activation. Your team supplies confirmed measurement definitions and identifies who approves them.

Tell us about the last report you corrected by hand after a client's agreement changed. What did you have to find: the previous calendar, the effective date, or approval to apply the change? That example can help us determine whether you need better use of your helpdesk, an integration, or a separate application for managing rule changes. See Syntalith pricing for information on how work is billed.