Apply SLAs
To apply an SLA, create an Incident with a default SLA. CSM uses this process to initially set the timelines for the SLA and then determines whether or not the default SLA should update as more information is added to the ticket.
How SLAs are applied
- Incidents are created with a default SLA (OOTB = Corporate).
- Application is based on the SLA that wins the selection process.
- If an element is added to the ticket that has a SLA tied to it, CSM checks to see whether the default SLA should update, and change if needed (SLA Selection).
The SLA Timelines Created flowchart shows how timelines are initially set for SLA.
The SLA Selection flowchart shows how CSM determines the Incident SLA after the Incident has been created as more information is added to the ticket (example: when a customer is added).
The SLA Timelines/Stats Changed flowchart shows how SLA timelines are changed during the lifecycle of the ticket, and the associated APs that are triggered.
SLA is affected if a ticket goes to any of these statuses:
- In Progress: Marks the response-by date and time.
- Pending: Calculates total amount of time (in minutes) in this status. If Stop The Clock (STC) is allowed, this time will be added to extend the deadline to prevent the SLA from breaching.
- Closed: Marks the resolution date and time.
- Reopened: Begins monitoring for SLA breach again based on the ticket SLA deadline. Time spent in Closed status does not stop the clock.
SLA Breach
- A warning is initiated (if configured), the ticket is marked as warned, and emails are sent (if configured).
- One-Step™ Action runs (OOTB: marks the ticket as having breached, emails the technician/manager). Breached incidents display in applicable dashboards/metrics.