SLA Management

Optional · Configure case handling

An SLA is a service-level agreement. Supportbench’s SLA targets help the team track specific response, ownership or closure commitments. A configured timer is not the entire customer agreement. Use this chapter when your team has a defined commitment to track.

Before you begin

An administrator needs workflow permission; an agent needs access to inspect the resulting case. Agree the target, qualifying cases and whether time counts continuously or only during business hours. Complete the service-hours review first.

Example: Northstar wants a two-business-hour response target for a defined class of support requests. 120 minutes is an example, not a Supportbench default or a recommended contractual promise.

Configure a target rule

1. Open Settings → Configuration → Workflows and inspect existing SLA rules.
2. Create or open the intended workflow. Give it a name explaining the commitment and keep an unfinished new rule inactive.
3. Choose the Case record type and the specific target event: SLA target response, SLA first owner, SLA first response, or SLA closure. These address different commitments; a normal Created event is not the same as an SLA target-calculation event.
4. On Trigger, enter SLA target (minutes). For the example, enter 120.
5. Choose SLA clock deliberately: 24/7 counts elapsed time; Business Hours uses the applicable schedule.
6. Use Requirements for conditions that must all match and Conditionals for the appropriate alternatives. Exclusions is a section farther down on the Conditionals tab, not a separate tab. Scope the example with Requirements → Company → Harbor Manufacturing, so the training rule applies only to the fictional company. Verify matching, nonmatching and excluded cases before relying on a rule.
7. Review Order against competing rules. Lower numbers run first, and SLA calculation uses the first matching target rule. Stop When Hit controls action-processing workflows; it does not change SLA target selection. Do not assume a newly added rule overrides all others.
8. Save, reopen and verify event, conditions, target and clock. Activate only when the rule is ready for the controlled test.

Saved SLA first-response target: 240 minutes on Business Hours. This is a demo example, not the 120-minute illustration.

Sticky SLA target currently has no effect on timing; do not rely on it to preserve a deadline. SLA commitments and rule configuration explains the complete target behavior.

Verification note — 29 October 2026: Do not rely on Company Not (Any) as the sole safeguard for an SLA rule. A controlled Core test found that a matching excluded company still received the target. Define eligible cases positively in Requirements, test an excluded case before activation, and leave the rule inactive if it still matches. Contact Supportbench with the case and rule details.

Find and verify the deadline

1. Use the fictional Harbor case for an SLA target response test: add an Internal note with no email recipients, then reopen the case and inspect its Audit tab for the rule name and SLA changes. This recalculates the target; it does not necessarily start a new clock. For SLA first response, use a request received through your chosen customer channel—an agent-created case may not qualify.
2. In Case View, inspect SLA response and the closure target where included by the case layout. If these rows are absent, an administrator must open Settings → Cases → Policy, inspect the matching Case View policy’s Summary Fields, and review SLA (When to respond) and Closure SLA (When to close). Save deliberate layout changes and reopen the case. There is no universal separate SLA panel.
3. Confirm the current queue and owner, then compare the due time with the applicable calendar and the event that started or reset the clock. A prior closure, reopen, SLA pause or manual change can affect the result. An internal note does not automatically grant another 120 minutes.
4. Test a matching and a nonmatching case, plus a case near the end of working hours and across a holiday.
5. After a reply, handoff or other relevant change, inspect the actual deadline again. Saving a workflow does not prove every old case was recalculated.

Case View policy Summary Fields: SLA (When to respond) is selected; Closure SLA (When to close) is available. This configures visibility, not a case deadline.

A queued case follows its queue’s schedule path. Missing queue hours do not necessarily fall back to the owner’s team. See service calendars and timing.

Handle an authorized exception

For an open case with a response target, an appropriately permitted agent can select SLA response, open Alter SLA Date, review the date/time and select Save. This changes that case’s concrete response deadline, not the workflow policy. SLA closure is display-only in this context.

Record why a manual exception was made and recheck the result. Case updates can reset altered dates according to workflows. Do not repeatedly move targets to conceal missed commitments.

If the target is wrong

• No deadline appears: check that the layout includes the field, the case has a stored target and the intended target event/rule actually ran.
• Time counts outside coverage: inspect the clock, queue/owner calendar path, timezone and empty schedule fallback.
• Wrong cases receive the target: inspect conditions, exclusions, order and competing rules.
• A draft seems to count as a response: distinguish composing, saving, scheduling and actual sending; verify the case outcome.
• Manual change is unavailable: check the separate permission to alter case SLA and that the case is open.

Completion check

• Each target corresponds to a defined service action.
• Conditions and clock are understood.
• Actual deadlines pass matching, nonmatching and boundary tests.
• Agents know who owns the next response.
• Any untested delivery or calendar behavior is explicitly recorded.

Previous: Set service hours and holiday coverage · Next: Communication Channels