Time tracking rules and SLA targets under Settings > Service Levels

What you will have

• Turn Auto-Start Timer on or off, and see the separate Activity-Resume variant and its morning window.
• Read Idle Threshold and IDLE Hard-Stop, the two different lengths that flip a slice to IDLE and then force-stop it.
• Pick a Finalize Day Mode and see its three choices.
• Pick a Re-attribution Window and see how long past time stays editable.
• See what SLA Policies actually holds: Response Quality Bands and Timer Color Thresholds, not business hours or per-priority targets.
• Read a priority's Response Time and its optional Resolution Time on SLA Display.
• Give one client its own SLA targets that override the global default.

Why it works this way

Steps

1. 1

   Open Settings, then Service Levels, then Time Tracking, and check Auto-Start Timer.

   Auto-Start Timer starts a timer the moment a tech opens a ticket and stops it the moment they leave, so billable time is captured without anyone remembering to hit Start. It is on by default. Auto-Start Timer at Activity Resume is a separate toggle, off by default: when a tech stops being idle inside a set morning window, it starts the clock from real activity-resume time instead, with no explicit sign-in needed. Auto-Start Window Start and Auto-Start Window End set that morning window, 6:00 AM to 9:00 AM by default.

   

2. 2

   Scroll to Idle & Reaper to see when a timer goes idle, and when it gets force-stopped.

   Idle Threshold is how long a tech can go without mouse or keyboard activity in the portal tab before the current time slice flips to IDLE, 30 minutes by default. Activity in another window, such as RDP, PowerShell, or a vendor console, does not count, so this needs to be long enough to cover a normal stretch of off-portal work on a ticket. No time is ever lost when a slice goes IDLE, it can be reassigned later. IDLE Hard-Stop is the second, longer threshold: after an IDLE or BREAK slice runs past this many minutes, 120 by default, the reaper force-stops it and notifies the tech, protecting against a forgotten browser tab running all day.

   

3. 3

   Scroll to Day Close & Confirmation and open Finalize Day Mode.

   Finalize Day Mode controls what happens when a tech has ADMIN time, unattributed minutes, left over from a day. Off - no nagging runs no check at all. Soft nag - warn but allow, the default, warns the tech but lets them keep working, with a Discard option. Hard block - must reassign first blocks starting new work, clocking in, allocating time, or discarding, until that leftover time is attributed. There is no clock-out action to leave open: the idle reaper and the midnight cron close out a day on their own, so a tech is never stuck waiting to sign off. Large Entry Threshold, just below it, requires manual confirmation on any single time entry over this many minutes, 480 by default.

   

4. 4

   Below Finalize Day Mode, read Re-attribution Window.

   Re-attribution Window is one rule that governs both editing existing time entries and creating backdated ones: Unlimited (no age limit), 7 days, 30 days, Until period close (locked once the entry's calendar month ends), or Until invoiced, the default (free to change until the entry lands on an invoice). Locked entries, invoiced, consolidated, in a closed period, or manager-locked, are never editable regardless of this window. Closing an accounting period, from the actions menu on Time > My Time, hard-locks every entry dated on or before the close date no matter what this window says.

   

5. 5

   Open Settings, then Service Levels, then SLA Policies, and read Response Quality Bands.

   This is the real SLA Policies page, and it holds three things: Response Quality Bands (Excellent Response and Good Response, the minute counts that earn a green or blue checkmark on a ticket's first reply), Timer Color Thresholds (the elapsed-time marks where a ticket's live timer shifts from green toward red), and Breach Alerts, further down. It does not hold business hours, that is its own page, Business Hours & Holidays, and it does not hold the four per-priority response and resolution targets, those live one page over on SLA Display, the next step.

   

6. 6

   Open SLA Display and read the CRITICAL Priority SLA card's Response Time.

   SLA Display holds the four per-priority target cards, CRITICAL, HIGH, MEDIUM, and LOW, each with its own Response Time, Unit, and Counting fields, all four now on this one page instead of four separate ones. Response Time measures how quickly a tech must send the first reply to a ticket, tracked from the moment the ticket is created, and it is always required, the field floors at 1 minute rather than accepting a blank. Counting picks Business Hours (M-F 8a-6p) or Calendar Time (24/7): a 2 hour CRITICAL target under Business Hours means 2 working hours, not 2 wall-clock hours.

   

7. 7

   On the same card, read Resolution time (optional).

   Resolution time measures how long until a ticket is marked Resolved, also tracked from ticket creation, and it is optional: leave it at 0 and the hint beside it reads No resolution target - resolution-due stays unset, meaning no resolution breach is ever flagged for that priority. Set a number instead and Resolution time drives the resolution-due date the same way Response Time drives the first-reply due date. Every priority on this tenant ships with Resolution time at 0, only Response Time is enforced out of the box.

   

8. 8

   Scroll to the bottom of SLA Display and read Timer Color Thresholds.

   This is a read-only mirror: the real Timer Color Thresholds field, and the Excellent Response and Good Response values above it, are edited on SLA Policies, this card just echoes the current value with an Edit in Service Levels -> SLA Policies link. The value is a comma-separated list of minute marks, low to high, 5,10,15,30,60,240,480,1440,2880 by default, and a ticket's live timer shifts color, green toward red, as elapsed minutes cross each one.

   

9. 9

   Open a client's own Billing, then Plans tab, then Edit subscription, to give that one client different SLA targets.

   Per-client overrides live on the client's own Subscription, reached from Billing, then Plans, then Edit subscription on any of that client's plan cards. The SLA Response Times card there shows CRITICAL, HIGH, MEDIUM and LOW, each starting blank with a greyed 2h (default), 4h (default), 8h (default), or 16h (default) placeholder, plus its own Business Hours Start and End override. Leave a field blank and that client follows the global default set on SLA Display; type a number and it becomes that client's own contractual target, which always wins over the global default.

   

10. 10

    Back on Time Tracking, scroll to Utilization Flags.

    Expected Hours per Technician is the target billable hours per tech per day, 8 by default, and the page says what it is for in its own words: the utilization thresholds below are measured against it, and the dashboard time widgets use it as the bar. It is the denominator behind every utilization percentage. The end-of-day reminder that goes to a tech who logged under 75% of their expected hours is a separate, fixed rule; that 75% is not a field here and cannot be changed. Low Utilization Threshold (%), 50 by default, and Overload Threshold (%), 125 by default, are the two fields under it, and each one's own hint says the same thing: the end-of-day sweep flags a tech against it and feeds the automation rule builder as a trigger, but it does not send a notification by itself. Build your own alert off it in Automations if you want one.

    

11. 11

    Open SLA Policies and find Timer Color Thresholds, the field SLA Display only mirrors.

    This is where the value in step 8's read-only mirror is actually edited, and it is not a comma-separated text box: each threshold is its own chip with an x to remove it - 5m, 10m, 15m, 30m, 1h, 4h, 8h, 1d, 2d here - with an empty minutes box and an Add another button beside them for adding more. The card's own line states the rest: these are the elapsed-time marks where a ticket's live timer shifts color, green toward red, each threshold is added as a duration, and they sort themselves whatever order you add them in.

    

12. 12

    A ticket sitting in a status your team marked as pausing stops both clocks.

    Both the Response Time and Resolution Time deadlines are set from the ticket's own creation time. When a ticket moves into a status your team has flagged to pause the SLA clock, such as Waiting on Client, the clock stops for both of them; when it leaves that status, the paused stretch is credited back before either deadline resumes. Which statuses pause the clock is a setting your team controls elsewhere, not a fixed list, so a status nobody has flagged never pauses anything.

13. 13

    Saving a target on SLA Display takes effect on the next ticket, not on tickets already open.

    When a ticket is created, or its priority changes, the SLA evaluator reads that priority's current Response Time and Resolution Time from SLA Display, or the client's own override when it has one, and stamps the ticket's own due dates from them. Changing a target on SLA Display clears the cached defaults immediately, so the very next ticket created or re-prioritized picks up the new number; it does not reach back and move the due dates already stamped on tickets that already exist.

If it did not work

• If Finalize Day Mode or Re-attribution Window will not change, check that the field actually shows a different value before reloading; every field on this page waits for the page's own Save button, the toggle and the two dropdowns included.
• If a client's SLA targets do not look like they moved, check that client's own Subscription for an override first; a target set there always wins over anything changed on SLA Display.

Questions this page answers