Service Level Agreements (SLAs) define the level of service that an organization commits to its customers. You can use the SLA feature in SBM Application Administrator to define metrics for tracking these commitments. The topics in the SLA Settings section describe how to do this.
Best Practices
SLAs need to be designed to ensure that performance measurements are meaningful and accurate. If SLAs are defined too broadly, practical usage can cause measurements to be distorted or items could remain in certain states without being noticed. To prevent this, define more granular SLAs (or SLA clauses) that monitor specific phases of an item's lifetime.
The following illustration shows a workflow that tracks the progress of an item.
Use Case 1: Different Paused States
The following table describes two paths that an item could take in the workflow. Different "paused" states are defined for each path.
| Scenario | Start State | End State | Paused State(s) |
|---|---|---|---|
| Entire process (SLA 1) | Assigned | Resolved | Waiting, Researching, Deferred |
| Technician needs information before proceeding (SLA 2) | Waiting | Resolved | In Progress, Testing |
When an item is in a "paused" state, time is not counted against the time remaining before the item is in violation of or at risk of violating the SLA. If only SLA 1 monitored the item, the item could remain in the Waiting, Researching, or Deferred states indefinitely. Reports would not indicate a problem, and warning notifications would not be sent. Customer service would be poor, even though it would appear that commitments are being met.
To ensure that an item is not neglected, an SLA should also be defined for the path that starts with the Waiting state. For example, suppose a new item must be completed within three days, according to the high-level SLA (SLA 1). The technician needs critical information before work can start, and moves the item to the Waiting state.
At this point, the item is under SLA 2, which stipulates that an analyst must provide the information within four hours. Because the Waiting state is not a "paused" state in SLA 2, the item will have visibility in reports and notifications if the item stays in this state (or the Researching or Deferred states) too long.
Use Case 2: Re-Opening a Closed Item
- An employee submits a request for a software application. The technician assigned to the item installs and tests the software, and moves the item to the Resolved state. The item spends two days in this path.
- The employee cannot use key functionality in the software because of configuration problems.
- The IT manager executes the Re-Open transition on the Resolved state form, and the item moves to the New state. The manager immediately reassigns the item to the technician, moving it to the Assigned state. The technician moves the item to the In Progress state, and has been working on it for one day.
In this use case, the elapsed time for the item is three days, because the time since the item was re-opened is added to the previous time.