Manage SLA response and closure commitments across B2B support

Updated Wednesday, October 28, 2026 · Marcel Gravelle

An SLA target gives the support team a deadline for a specific service action. In B2B support, that deadline needs to reflect the customer’s service commitment, the kind of case and the hours during which the commitment runs. Supportbench combines case context, workflow target rules and the applicable calendar so the team can manage a concrete response or closure deadline. The most useful outcome is an agent knowing what is due, who owns it and what to do before the commitment is missed.

At a glance

For: support operations leads, supervisors, agents and workflow administrators. Applies to: Supportbench Core.

Start here: Case View for case deadlines; Settings → Configuration → Workflows for SLA target rules

Start with the service action you actually promise · Choose the target and clock together · Understand where the case gets its SLA calendar · Prepare a rule that operations can explain · Configure an SLA target rule · Find and interpret the actual case deadline · Work the commitment into the daily support routine · Verify more than the happy path · Troubleshoot the deadline, then the underlying decision

Start with the service action you actually promise

A service agreement is your organization’s commitment to its customer. A configured SLA target is the operational timer used to help manage a particular part of that commitment. Agree the service terms with the appropriate business owner, then translate the supported actions into rules. Setting a timer does not create a legal agreement, calculate compensation or guarantee an uptime or satisfaction result.

Target event in Workflows	Operational question it addresses
SLA target response	When is the applicable response due? Use the case’s actual current response deadline when prioritizing work.
SLA first owner	How quickly should responsibility first be established? Distinguish this from a substantive response to the customer.
SLA first response	How quickly should the initial response occur? Do not assume every internal activity is a customer response.
SLA closure	What closure target applies? Closing the support record still requires the team’s agreed resolution and customer-communication process.

Document what your team counts as a meaningful response or resolution, then verify representative activities against the actual case results. An internal note, saved draft, scheduled email, task and sent customer reply have different purposes. Neither composing a message nor scheduling one proves that the customer received a response.

Choose the target and clock together

Choice	Meaning	Use it when
SLA target (minutes)	The number of minutes for the selected target event. For example, 120 means two counted hours.	The policy has an explicit, agreed target for this case situation.
24/7	Counts elapsed time across the whole week.	The commitment genuinely runs continuously, including nights and weekends.
Business Hours	Counts the applicable SLA business-hours calendar.	The commitment runs only during the supported coverage windows.
Sticky SLA target	Retained configuration preference with no current effect on SLA timing.	Do not rely on it to freeze or preserve a deadline.

Example: two hours does not always mean two clock hours

Assume the effective calendar is Monday–Friday, 09:00–17:00 in its configured time zone, with no holiday or off-day coverage. A two-hour target starting Friday at 16:00 has one counted hour left after Friday. A Business Hours target reaches the remaining hour on Monday at 10:00; a 24/7 target reaches it on Friday at 18:00. This is an illustration under those explicit assumptions, not a default schedule.

The selected clock is only half the configuration. Confirm which calendar the actual case uses. Choosing Business Hours while the case has no effective business-hour intervals can result in continuous counting. Do not infer coverage from the owner’s visible working hours alone.

Understand where the case gets its SLA calendar

Case context	Calendar selection to verify
Case has a queue	Queue availability and its parent queue chain. If that path supplies no hours, it does not fall through to the owner’s team; an empty Business Hours result can normalize to 24/7.
Case has no queue and its owner has a primary team	The owner’s primary team and parent-team chain.
Case has no queue and its owner is not in a team	The applicable owner profile schedule.
Holiday or calendar exception	The effective holiday/calendar resolution and events marked to stop SLA timers. An ordinary calendar appointment is not automatically an SLA pause.

This matters when an urgent case moves from a specialist queue to another team or when a queue’s hours are incomplete. Inspect the actual queue, owner, inherited schedule and deadline after the relevant operation. Do not use a customer’s time zone, the viewer’s time zone or an agent’s absence as a substitute for verifying the effective SLA calendar. See the related availability guide for setup and boundary tests.

Prepare a rule that operations can explain

Identify the supported target event and the business decision behind it. Keep first ownership, first response, ongoing response and closure expectations distinct.
Define which cases qualify using maintained case/customer facts available in Workflows. For example, an agreed priority or service category can be more reliable than interpreting urgency from a subject line.
Agree the target minutes and clock. Identify the actual queue/team schedule and holiday behavior before entering the rule.
Identify exceptions and overlaps with existing workflows. Decide the required priority and Stop processing behavior rather than adding a second broad rule without reviewing the first.
Prepare matching, nonmatching and boundary cases, including an after-hours case. Use approved test records and recipients; do not send customer notifications solely to test a timer.
Confirm workflow-administration access. Agents who only work cases may be able to view the result without permission to change the policy.

Configure an SLA target rule

Open Settings → Configuration → Workflows and create or open the intended rule.
In Details, use a name that states the commitment and qualifying situation, then review active state and priority.
On Trigger, choose the Case scope and the appropriate event: SLA target response, SLA first owner, SLA first response or SLA closure. These are target-calculation events; selecting an unrelated Created or Updated event does not mean the same thing.
Set the displayed SLA target (minutes) and SLA clock controls for the selected event. Confirm units before converting hours to minutes.
Use Requirements for conditions that must all pass, Conditionals for the appropriate at-least-one group and Exclusions for explicit exceptions. Review all existing rows, not only the one just added.
Review competing rules, priority and Stop processing. Save the workflow and reopen it to confirm the event, conditions, minutes and clock.
Exercise the intended target-calculation path on an approved case. Verify the actual deadline and calendar context. Saving the rule does not by itself prove that every existing case was recalculated.
Test the nonmatching case and each boundary condition below. Record observed dates and the rule decision so another administrator can repeat the check.

Find and interpret the actual case deadline

Open the intended Case View and review the configured summary fields SLA response and SLA closure. Available fields depend on the case layout and stored targets; there is no universal separate SLA panel.
Compare the displayed deadline with the latest customer activity and the case’s current queue/owner. SLA closure is display-only here.
In a case list, inspect the SLA target column where included. Its countdown or overdue label summarizes the target; use the tooltip to check the exact date/time.
For an authorized manual response-target change on an open case, select the response value to open Alter SLA Date, review the date and time, then use Save or deliberately Clear SLA. The case list also offers Set SLA for an open case without a target.
Recheck the saved deadline. The permission to alter the case SLA is separate from workflow administration, and the dialog warns that Case updates can reset altered dates according to SLA workflows.

A manual alteration changes this case’s concrete response date. It does not change the Workflow target minutes or clock for other cases. Activity timeline values labelled SLA target or SLA response time describe activity timing and should not be confused with the current case deadline.

Work the commitment into the daily support routine

When taking a case, confirm the Company, Contact, impact, owner and current response/closure commitments. Check the latest customer activity before sending another update.
Use an appropriate case view to find work approaching its deadline. Include ownership and customer context so the list supports an action, not just a count.
If the investigation needs another team, retain an accountable support owner and a clear next customer-update plan. Engineering work or a supplier dependency does not communicate progress to the customer by itself.
Escalate early enough for someone to act. Explain the customer impact, the approaching commitment, work already completed and the specific help needed.
If an authorized exception requires a manual response-target change, use the supported adjustment procedure and record why. Do not repeatedly move targets merely to make a report look healthy.
After responding or resolving, verify the saved case outcome. Review failures for a process improvement such as incomplete schedules, unclear ownership, missing information or an unrealistic commitment.

Scheduled views can deliver a recurring operational review, and KPIs can help supervisors spot trends. Keep their filters, date meaning and audience explicit. A weekly report is useful for management; it is not a replacement for acting on a case due this morning.

Verify more than the happy path

Test situation	What to confirm
During ordinary coverage	The selected rule, minutes and resulting due time agree with the intended commitment.
Just before coverage ends	Business Hours carries remaining time into the next valid interval; 24/7 continues counting.
Weekend or configured off-day	The effective off-day hours, if enabled, are actually the intended coverage.
Holiday	The intended holiday schedule/event is effective and its category stops SLA timers where required.
Queued case with no queue hours	Verify the actual resulting clock; do not assume the owner’s team fills the gap.
Different priority or excluded customer situation	The specific target does not incorrectly apply outside its intended conditions.
Ownership/queue change or another relevant event	Inspect the resulting deadline and effective context instead of assuming the old calendar continues unchanged.
Draft or scheduled customer message	Distinguish stored activity state, actual send outcome and the current response deadline.

Troubleshoot the deadline, then the underlying decision

Problem	Likely checks and corrective action
Deadline falls outside expected working hours	Check 24/7 versus Business Hours, actual queue/owner path, inherited intervals and schedule time zone.
Weekend is counted unexpectedly	Check queue hours before owner/team hours, enabled off-day coverage and empty-calendar fallback.
Holiday did not pause time	Check the effective holiday schedule and event category’s Stop SLA timers setting; an event title alone does not pause a timer.
New workflow did not change an existing case	Confirm the selected target-calculation event, matching conditions, competing rules and whether that case underwent the relevant calculation.
Target changes unexpectedly	Review manual changes, later workflow events and context changes. Sticky SLA target currently does not prevent a timing change.
Report and agent disagree	Compare the same case IDs, date/filter definitions and time-zone display. Recorded work effort and SLA duration are different measures.
Target was met but customer is still dissatisfied	Review response usefulness, ownership and actual resolution. A timely empty update is not the same as solving the problem.

When asking an administrator to investigate, provide the case ID, observed deadline, expected result, relevant event/time zone and matching rule/schedule context. Avoid sending unnecessary private customer content. A reproducible timing example is more useful than “the SLA is wrong.”

Was this article helpful?