Home → Users Manual → Filters → Example: SLA Compliance Across Tiers

6.25. Example: SLA Compliance Across Tiers

Updated: 3 Sep 2026, 10:05 PM EDT

Scenario

Three support tiers with different first-response targets. Tier 1 (General Inquiries) 24 hours. Tier 2 (Technical Support and Billing) 8 business hours. Tier 3 (anything tagged Critical) 1 hour. The operations director wants to review how often each tier missed its target over the past month.

Why this is an audit, not a live queue

The condition these filters are built on — Minutes since first response (all hours) — only matches requests that have already received a first staff reply. A request still sitting unanswered is excluded by design: the query drops rows with no response time, because otherwise every unanswered request would match every threshold.

That makes this a look-back report. It answers "which requests did we answer too slowly?", not "which requests are about to breach?" 

For the live version — requests still waiting, before anyone has replied — use Customer wait time (minutes), paired with Last public reply from → Customer. On a request nobody has answered, Customer wait time measures the time since the customer wrote, which is the first-response clock.

The pairing matters. Customer wait time only measures a live wait while the customer's message is the most recent thing on the request; if a staff member has replied since, it returns the gap between the customer's message and that reply instead — a historical figure that never changes. On its own it would also match requests nobody is waiting on. Example: Escalation Dashboard is built that way.

Why this is three filters, not one

Two product constraints decide the shape:

Condition groups cannot nest. Three tiers each with their own AND-ed rules, OR-ed together, needs two levels.

There is no business-hours condition. First Response Speed (biz hours) exists as a display column and a sort option, but not as something you can filter on. Tier 2's target cannot be selected for at all.

One filter per tier is clearer to read anyway, and it lets each tier keep its own target in its own name.

One thing to know before you start: reporting tags belong to categories

A reporting tag is not a free-floating label. Every tag is defined inside one category, and the condition takes a single Category / Tag pair. "Critical" under Technical Support and "Critical" under Billing are two different tags that happen to share a name.

So a tier defined by a tag — like Tier 3 here — needs one condition per category that has that tag, grouped together. This catches people out, because the tier sounds like one idea and the product needs it spelled out three times.

This example assumes a Critical tag exists in all three categories. Drop the pairs you do not have.

Setup

Create three filters, all sharing an SLA audit folder, all with Display count in Workspace ticked, and all with these display columns: Request ID, Customer, Email Subject, Category, Reporting Tags, Assigned To, First Response Speed (all hours), First Response Speed (biz hours), Date Opened.

Three things are the same across all three:

SLA audit — Tier 1 late

Match all:

SLA audit — Tier 2 late

Match all:

The two categories need a group because a Category condition holds one category. To build it: add a condition row with the + below the condition box, choose ANY of the following are true from under the Advanced heading in its dropdown, set the blank condition that appears inside to Category Is Technical Support, then use the group's own + to add Category Is Billing beside it. See Sub-Condition Groups.

The two Without reporting tags conditions stay at the top level. Each excludes its tag outright, and in a Match all filter that is exactly what you want — a request has to clear both.

SLA audit — Tier 3 late

Match all:

Built the same way as Tier 2's category group — one group, three conditions inside it, added with the group's own +. No category condition is needed here: the tag pairs already say which categories are in scope.

Order each by First Response Speed (all hours), Descending, so the worst misses are at the top.

Category, status and reporting tag names in this example are placeholders — substitute the ones your installation actually uses.

To review near misses alongside breaches, lower the threshold: 1080 on Tier 1 shows everything that used more than three quarters of the 24-hour target, and the First Response Speed column tells you which of those actually went over.

Resulting logic

Tier 1:  Category = General Inquiries
                   AND NOT tagged General Inquiries / Critical
                   AND opened in the past 30 days
                   AND minutes to first response > 1440

Tier 2:  (Category = Technical Support OR Category = Billing)
                   AND NOT tagged Technical Support / Critical
                   AND NOT tagged Billing / Critical
                   AND opened in the past 30 days
                   AND minutes to first response > 480

Tier 3:  (tagged General Inquiries / Critical
          OR tagged Technical Support / Critical
          OR tagged Billing / Critical)
                   AND opened in the past 30 days
                   AND minutes to first response > 60

In all three, "minutes to first response" exists only for requests that were answered, so unanswered requests appear in none of them.

Why the tiers exclude each other

Tier 3 cuts across categories, while Tiers 1 and 2 are defined by category. Without the Without reporting tags conditions, a Critical request in Billing answered in 90 minutes would count as a Tier 3 miss (over 60) and, later, could count again as a Tier 2 miss — appearing on two reports against two different targets, and inflating both counts.

The assumption being made: a Critical tag outranks the request's category tier. A Critical Billing request is judged against the 1-hour target, not the 8-hour one, so it belongs to Tier 3 and nowhere else. That is what the scenario implies, but it is a policy decision, not a product behavior — check it against how your own tiers are meant to work before copying this.

If your Critical tag is meant to be an additional flag rather than a tier of its own, leave the exclusions out and accept that the counts overlap.

The Tier 2 caveat

Tier 2's target is 8 business hours; this filter measures 8 calendar hours. Calendar time runs continuously, while a business-hours clock only advances while the team is working — so a request arriving at 5pm on Friday has piled up more than 60 calendar hours by Monday morning without using a single business hour, and crosses the filter's line before anyone could reasonably have answered it.

The error only runs one way: calendar time can overstate but never understate, so the filter cannot miss a real breach — it just includes some requests that were answered well inside their target. That is why First Response Speed (biz hours) is in the display columns. The filter finds the candidates; you read the column to see which ones genuinely missed. Treat the Tier 2 count as a shortlist, not a breach total.

Knowledge Tags
examples  /  SLAs  / 

This page was: Helpful | Not Helpful
← Example: Monitoring SLA Response Times