Service Level Agreement
A Service Level Agreement (SLA) in ERPNext is an official agreement among a service provider (internal or external) and the customer or end user, specifying the expected response and resolution times for support-related incidents. This creates a standard support experience, increases accountability and helps organizations to meet customer expectation in an efficient and standardized way.
SLAs in ERPNext are result-oriented, i.e., they don't dictate how the services are to be delivered but define what is the expected response or resolution time once an Issue is raised by the customer.
To view the list of SLAs in ERPNext:
1. Prerequisites
Prior to creating and making use of SLAs in your system, ensure the following have been done:
Holiday List: Set up or edit your company's holiday list. SLA timers will ignore holidays, so issue deadlines will take into account only working time.
Enable SLA Tracking: In Support Settings check the Track Service Level Agreement option is enabled. This enables SLA capabilities in all support workflows and allows SLA fields in the Issue doctype.
These steps help ensure that SLA tracking is in sync with actual operating schedules and that your system is prepared to record SLA metrics correctly.
2. Creating a Service Level Agreement
To make a new SLA record in ERPNext:
- Get to the list of the Service Level Agreement and choose New.
- Give a name to your SLA policy. It has to be descriptive (e.g. Gold Tier SLA, Standard SLA- North Region).
- Select an Employee Group to work the tickets within this SLA. This enables good workload distribution and escalation.
- Define a Holiday List: Select the holiday list that is applicable to this SLA. ERPNext will not consider the holidays listed when determining response and resolution due dates.
- The "Enable" check box determines whether the SLA is enabled or disabled temporarily.
- If this SLA would be applied by default to customers who don't have an assigned specific SLA, check the Default Service Level Agreement box.
- You may assign SLAs according to:
- Customer
- Customer Group
- Territory
- You can select either one of the above as an Entity Type drop-down and then the associated entity. This allows for the capability of having various SLA policies for VIP customers, specific regions, or segments of customers.
- Establish the validity period of the SLA by entering the Start Date and End Date. This enables version control and accommodates time-limited or temporary agreements.
- In the Priorities table, you can establish SLA behavior per issue priority. On a per level basis (e.g., Low, Medium, High, Critical), specify:
- Time to Respond (hours and minutes)
- Time to Resolve (hours and minutes)
These are the areas that guarantee ERPNext can accurately track SLA compliance during both the initial response and final resolution levels.
- You can set a Default Priority which will be automatically applied to issues under this SLA if no priority is specifically picked upon creating the issue.
- The Support Hours area enables you to specify your working support schedule. You can set:
- Working days of the week upon which the support is available (e.g., Monday through Friday)
- Start Time and End Time for every working day
ERPNext will stop SLA timers during these specified working hours, so issue response/resolution expectations are calculated only when support is actually available.
- Once all Fields are established based on your need in business, you need to Save so as to enable Service Level Agreement.
ERPNext will automatically map the right SLA to Issues based on the customer, group or territory and observe SLA adherence through integrated alerts, metrics, and reports.
3. Features
3.1 Applies to New Issues
After a Service Level Agreement (SLA) has been created and saved in ERPNext, it will automatically be assigned to newly created Issues depending on the setup in the Entity Type field of the SLA. This implies, based on whether you've associated the SLA to a Customer, Customer Group, or Territory, the system will automatically use the appropriate SLA when an Issue is created. This will help track support response and resolution times correctly and consistently from the time the issue is created.
3.2 Resetting an SLA
ERPNext enables you to reset an SLA prior to the specified service window closing. For example, if an SLA specifies a 3-day resolution time for a Critical problem, you can restart the SLA timer at any point within the 3 days. But after the deadline passes, the system will automatically tag the SLA as failed, and you will not be able to restart it. This keeps SLA accountable and does not let you extend the timeline by unauthorized persons when the service promise has already been violated.
3.3 Response / Resolution Time in Issues
Every Issue in ERPNext shows Time to Respond and Time to Resolve fields explicitly depending on the SLA used. These durations are automatically pulled from the Priorities table defined in the SLA. For instance, if a problem is tagged as "High Priority", the SLA would exhibit the precise time (in hours and minutes) for when the initial response should be completed, and the problem should be fixed. Having real-time visibility lets support teams track service deadlines and respond quickly to meet or exceed customer expectations.
3.4 Pause SLA on Statuses
Since ERPNext Version 13, you are able to stop SLA tracking when some conditions are met, typically when the issue is awaiting customer input, or some other outside influence.
- The "Pause SLA On" table in the SLA document lets you define custom statuses (e.g., "Waiting for Customer", "Pending Vendor Reply") on which SLA timers will be paused.
- Once a problem gets moved into a paused state, there is a temporary hold on the response and resolution timers and visual indicators on the dashboard are also labeled to reflect this.
- When the issue is brought out of the pause state, ERPNext computes the total hold time and deducts the remaining SLA time by excluding this pause time.
- This dynamic timer setting ensures equitable SLA tracking, particularly in situations where delay is not controllable by the support team.
Note: The legacy "Service Level" DocType was deprecated in ERPNext Version 13. Today, all SLA features are handled directly under the Service Level Agreement DocType, making configuration less of a redundant process.