A team that runs on-site visits and remote recovery jobs handles two different kinds of work, but a single SLA policy treats them as one. The on-site dispatcher needs a 2-hour first-response window during local business hours. The remote team works 24/7 but resolves most issues within 4 hours. If the policy sets a 2-hour target, remote jobs look like they are perpetually behind. If it sets a 4-hour target, on-site delays go unmeasured. The configuration guide that follows shows how to stop measuring both with the same yardstick.
What you need before you start
A default SLA policy must already be active. The general policy serves as the fallback for any case that does not carry a matching tag. This is where you define the baseline attainment percentages, first-response and resolution minute thresholds for each priority, and the default working-hours configuration. The general policy stays in place; tag-specific policies layer on top of it.
Step 1: Define a tag that identifies the class of work
Create or select a case tag that maps directly to the work category. For on-site dispatch, name the tag on-site-visit. For remote recovery, remote-recovery. The tag name becomes the selection key, so use a label the team will apply consistently during triage. A policy selects only when the case carries the exact tag. No tag on the case - no selection.
Step 2: Build the policy for that tag
Inside the SLA configuration, create a new tag-specific policy and attach it to the tag. Then specify the complete commitment:
- Overall attainment target - the percentage objective for the policy as a whole.
- First-response attainment and minute threshold - the percentage objective and time-to-first-touch target.
- Resolution attainment and minute threshold per priority - separate percentage and time targets for Critical, High, Medium, and Low.
- Working hours - the clock window for this class of work. On-site visits track the customer's local 9-to-5. Remote recovery runs on a 24/7 clock.
Repeat the process for each work category. Each policy is independent: editing the on-site policy does not touch the remote policy or the general default.
Step 3: Understand deterministic selection
A case can hold multiple tags. When more than one tag maps to an SLA policy, Latch applies the policy with the strictest resolution target for that case priority and records the selected source. Equal targets use a stable tie-break. If the team wants the simplest explanation during rollout, assign one SLA-relevant tag per case; if multiple policy tags are allowed, test the strictest-target rule with each priority.
Step 4: Test before you trust the numbers
Before applying the new policies to live cases, run a short test. Create a few test cases manually. Apply the on-site-visit tag to one, remote-recovery to another, and leave a third untagged. Confirm that each case picks up the intended policy, that the working-hours clock starts correctly, and that the first-response and resolution timers align with the policy's minute thresholds. Check that the default policy applies to the untagged case. If a test case selects the wrong policy, review the direct tags and compare the applicable resolution targets for that priority.
After the policies are live, the snapshot on each case preserves the exact policy parameters - target percentages, response minutes, resolution minutes, and working-hours basis - that governed the case. This is the mechanism that makes later reporting trustworthy (see SLA policy history and reporting).
What the team sees during triage
An operator opening a case tagged on-site-visit sees the corresponding SLA commitment displayed on the case, not the general policy. The displayed targets tell them what the clock is counting toward. If a case arrives without a tag, the general policy appears, and the operator knows that applying the right tag will bring the correct commitment into view.
Where to go next
The release overview in the tag-specific SLA release overview explains the reporting layer and policy history. For an explanation of how working-hours windows affect the clock, start with how working hours change SLA calculations. And if the team wants to measure more than first-response time, queue health measures beyond first response covers the metrics that matter beyond the initial touch.
Tag-specific SLA policies do not add a new metric. They make the existing metrics honest by separating commitments that were never actually the same.