SLA is the acronym for Service Level Agreement. It consists of an agreement between two parties: the entity willing to provide the service and the customer seeking to benefit from it. 

SLAs should be controlled using specific methods and metrics that can guarantee that the public interested in acquiring a particular service will recognize the quality of results obtained by a particular company or entity that executes them.

The SLA may be applied to the entire market section that deals with services; however, by convention, this agreement is related to companies that work in the department of Information Technology - IT. 

The main SLA points may be summarized as follows:

• Definition of the results to be obtained.
• Execution time of the activity to be developed;
• Definition of those responsible for the activities and the involvement they will have.
• Definition of the tools that will be used.
• Detailing of the amount of work to be delivered.

Play: defines the statuses in which time must be counted in the SLA. Use it for activities in normal execution of the process, with statuses such as “Being executed” and “Under analysis”.

It should be used when the process is actually being worked on.

First response: defines the status that represents the moment of the first service to the customer.

This trigger measures the time between the start of the process and the first interaction, and only one situation can be configured for it.

It should be used to control an initial execution SLA, such as support or tickets.

Pause: defines the statuses in which time should not be counted in the SLA.

This trigger is suitable for waiting moments and can have one or more statuses, such as "Waiting for customer" and "Waiting for approval".

It should be used when the process is stopped due to external factors.

Stop: defines the statuses that end the SLA.

With this trigger, the SLA stops counting, even if the process continues. It can have one or more statuses, such as “Finished”, “Service completed”, or “Satisfaction survey”.

It should be used when the objective of the SLA has already been achieved.

Practical configuration example:

Considering a service process.

With these configurations, the behavior of the process will be:

• The SLA starts at triage or execution.
• Counts normally during the execution.
• Pauses while waiting for the customer.
• Ends when the service is completed.

Comments:

• The SLA is started when enabling an activity whose status is set to the Play or First response step. The first response starts to count in the SLA when enabling the activity with the status of the First response step.
• If there are no associated statuses in the Play or First response step, the SLA starts counting immediately after the process starts.
• When executing an activity with the First response status, the respective step is closed; however, if the instance returns to the First response status, the respective step will be updated, that is, it will be counted in the SLA duration again.
• If there is no defined status in the first activity of the process, the SLA will be started at the Pause step.
• When a status is added to the process, it will be automatically added in the Play step.
• When a status is removed from the process, and said status is no longer associated with any step of the process, it will be automatically removed from the SLA.
• When any SLA trigger configuration is changed in a process without revision control, the changes will be immediately applied to in-progress instances.
• The process imports and exports will not contain the SLA configurations.
• The SLA configurations will be applied in the process copies.
• The SLA configurations are kept in process revisions.