What is an SLA and how do I set one up?
Customer Portal, Service Level Agreements
Service Level Agreements (SLAs) allow flexibility in the amount of support provided to your customers. When you create an SLA, you can define the duration of the service agreement or the number of incidents that can be submitted by the contact or organization.
In addition, granting privileged access to contacts or organizations is accomplished with an SLA. The bottom section of the SLA allows you to define which access levels the contact or organization can view.
When an SLA is actually issued to a contact or organization, the specific item associated with the contact or organization record is called an SLA Instance. Therefore, several SLA instances can be generated from the same SLA that is defined in the Service Level Agreements table. For more information on applying SLA instances to contacts and organizations, refer to Answer ID 1944: Applying SLAs to Contacts or Organizations.
Note: The SLA field can be removed from specific workspaces or set to a read-only mode to prevent staff groups from accessing and editing the SLA field.
Additional Considerations: When working with SLAs, once you apply the SLA to a contact or organization, it is a best practice to not edit that SLA in the future. When an SLA is edited in the Service Level Agreements table, it is not automatically re-applied to the contact and organization records. As a result, changes made to the SLA are not automatically carried forward to your contacts and organizations. Instead, you must remove the older SLA instance and save the record. Then, you can apply the updated SLA to the record.
When an SLA has been applied to a contact or organization, you can set incidents for that contact to be counted towards a specific SLA. When you open the incident, you can set the SLA field in the sidebar so that the incident counts towards the number of incidents allowed by that SLA. If the contact or organization record does not have an SLA applied to it, the SLA field is not accessible when editing or responding to incidents that are associated with that contact or organization.
Configuring an SLA
To add a Service Level Agreement, use the steps below:
- From the Configuration items, select Service > Service Level Agreements > Service Level Agreements.
- On the ribbon, click the "New" button to add a new Service Level Agreement.
- Complete the fields per the table below and click Add.
The fields to define when creating an SLA are:
|Service Level Name: The name of the SLA as it appears on the interface
|Active: Enable or disable the SLA for activation. When enabled, the SLA can be applied to contacts or organizations manually or via rules.
|Chat Incidents: Define the maximum number of incidents that can be submitted from a chat session. To allow unlimited incidents for the sources listed, leave the source field blank.
|CSR Incidents: Define the maximum number of incidents that can be created by an agent from the administration pages. To allow unlimited incidents for the sources listed, leave the source field blank.
|Email Incidents: Define the maximum number of incidents that can be submitted via an email sent to a service mailbox. To allow unlimited incidents for the sources listed, leave the source field blank.
|Self-Service Incidents: Define the maximum number of incidents that can be submitted from the Ask a Question page. To allow unlimited incidents for the sources listed, leave the source field blank.
|Total Incidents: Enter the total number of allowed incidents. The Total Incidents field must be greater than or equal to any other incident field.
Note: If any of the incident source fields are blank, the Total Incidents field must also be blank.
|Term (Duration): If the SLA is time-based, enter the number of days, weeks, months or years. If Length is left blank, the SLA is for an unlimited length of time. If non-blank, the start date is the date that the SLA instance is issued.
|Self-Service: If enabled, contacts or organizations can access the public knowledgebase (the Answers tab).
|Access: If using privileged access, highlight the access level(s) to be granted by the SLA.
|Response Requirements: You can specify response requirements, work hours, and holidays that are specific to the SLA. The response requirements of the SLA override the default response requirements. This allows you to define more stringent response requirements based on the level of service being provided by the SLA.
Click the interface name to configure response requirements, work hours, and holidays to be used for incidents submitted through that interface. If you do not set up response requirements, the default response requirements will be used.
Select the day and work hours along with the Response and Resolution times (in minutes) to be associated with the SLA. Then multi-select from the list of Holidays (you have already created) and click Update.
Restrictions to End-User Features
For Customer Portal enabled pages:
- Open the ask.php file in the /views/pages folder.
- Locate the following line of code at the top of the file.
<rn:meta title="#rn:msg:ASK_QUESTION_HDG#" template="standard.php" clickstream="incident_create"/>
- Edit the code to change the login_required page meta tag to "true" and add the sla_required_type and sla_failed_page meta tags.
<rn:meta title="#rn:msg:ASK_QUESTION_HDG#" template="standard.php" login_required="true" clickstream="incident_create" sla_required_type="incident" sla_failed_page="/app/error/error_id/2" />
- Save ask.php.
For additional information, refer to the 'Require an SLA on the Ask a Question page' section in online documentation for the version your site is currently running. To access Oracle B2C Service manuals and documentation online, refer to the Documentation for Oracle B2C Service Products.