What does the “Use Initial Responded and Initial Resolved date/time for SLA evaluation” setting do?

Question

What does the “Use Initial Responded and Initial Resolved date/time for SLA evaluation” setting do, and when should it be enabled?

Environment

  • Ticketing applicaton with Service Level Agreements (SLAs) configured

  • SLA evaluation performed by a scheduled SLA processor (runs approximately every 5 minutes)

  • Tickets that may move between statuses such as New, In Progress, On Hold, and Resolved

Answer

The “Use Initial Responded and Initial Resolved date/time for SLA evaluation” setting determines whether the SLA evaluates performance using the first recorded response/resolution or the most recent response/resolution on a ticket.

Why This Setting Exists

SLAs are evaluated by a background processor that typically runs every 5 minutes. Because of this, status changes can sometimes occur between evaluation cycles.

Additionally, when a ticket is placed On Hold:

  • The SLA timer pauses

  • The SLA is not evaluated while the ticket is On Hold

The SLA is only evaluated once the ticket returns to an active status such as In Progress. In rare cases, this timing can result in a violation even when the technician responded within the expected time.

Example Scenario

Assume the SLA has a 30-minute Respond By target.

Time Event
4:00 PM Ticket is created
4:29 PM Technician sets ticket to In Progress (initial response occurs)
4:33 PM Ticket is moved to On Hold
4:40 PM Ticket is returned to In Progress
~4:45 PM SLA processor evaluates the ticket

Key details:

  • Time spent On Hold: 7 minutes (4:33–4:40)

  • The SLA processor did not evaluate the ticket while it was On Hold.

When the ticket returns to In Progress, the system updates the Responded timestamp to 4:40 PM if the SLA is using the most recent response time.

During evaluation, the SLA calculates:

  • Created: 4:00 PM

  • Responded: 4:40 PM

  • Total elapsed: 40 minutes

  • Minus On Hold time: 7 minutes

Effective response time: 33 minutes

Because the SLA target was 30 minutes, the ticket is recorded as an SLA violation, even though the technician originally responded at 4:29 PM, which was within the SLA target.

How the Initial Timestamp Prevents This

When Use Initial Responded and Initial Resolved date/time for SLA evaluation is enabled:

  • The SLA uses the initial response time of 4:29 PM

  • Later status changes do not overwrite that timestamp

The SLA calculation would then be:

  • Created: 4:00 PM

  • Initial Responded: 4:29 PM

  • Total response time: 29 minutes

Because the response occurred within 30 minutes, the SLA is correctly recorded as met.

When to Enable This Setting

Most organizations can safely enable this option. It ensures SLAs are measured using the first response and resolution, which typically reflects the intended service performance and avoids rare edge cases caused by timing between SLA evaluation cycles.

When Not to Enable It

The main reason not to enable this setting is if you regularly reapply SLAs to tickets and want the SLA to evaluate based on the most recent response or resolution times rather than the original ones.

Cause

This behavior occurs because SLA compliance is evaluated by a scheduled process rather than in real time. Since tickets are not evaluated while On Hold, multiple status changes can occur before the next SLA evaluation cycle. If the system updates the response timestamp when the ticket returns to an active status, the calculated response time may exceed the SLA target. Enabling the Initial Responded and Initial Resolved timestamp option prevents this by always using the first qualifying response or resolution time.

Print Article