Configure Service Level Requirement

22 Jul 2025
7 Minutes to read

Configure Service Level Requirement

Updated on 22 Jul 2025
7 Minutes to read

Article summary

Did you find this summary helpful?

Thank you for your feedback

An SLR (Service Level Requirement) is a expected service performance between a service provider and a customer before a formal Service Level Agreement (SLA) is finalized. An SLR outlines the customer’s needs and expectations regarding a service’s quality, availability, responsiveness, and performance. It forms the basis for negotiating and creating the final SLA.

To Configure Service Level Requirement, perform the following steps:

Log in to the application as an Admin.
Navigate to SLA > User > Service Level > New Service Level Requirement.
New Service Level Requirement configuration screen is displayed.
Figure: New Service Level Requirement

To configure Service Level Requirement at the Tenant level, select and enter the required fields in the left layout of the configuration screen.

For more information, refer to the following Field Description:

Field	Description
Department	Select Department from the dropdown list. It will display a list of Departments based on the configuration under Admin > Basic > Infrastructure > Tenant for which the SLA module will be available.
Customer	Select Customer from the dropdown list. It will display the list of customers based on the configuration under Admin > Basic > Customers > Customer List.
Location	Select Location from the dropdown list. It will display the list of locations based on the configuration under Admin > Basic > Infrastructure > Common Masters > Common Master Type.
Date	Displays the system date and time. Example: 2025-07-10 12:42:25 PM
Service Name	Enter the Service Name.
Status	Displays the status of the Service Level Requirement, following are the other Statuses available after configuration. New - As a new Service Level Requirement configuration is selected, the status by default is New and grayed. Approve - This status is displayed when the Service Level Requirement is approved from the approver. Publish - This status is displayed If it is ready to publish.
Service Workgroup	Select Service Workgroup, the dropdown list displays all the workgroups under the selected Tenant.
Service Level Manager	Displays the Service Level Manager name based on the service level manager configured for the Workgroup under SLA > Configuration > Service Level Approver.
Service Handling	Select Service Handling from the drop-down list.
Description	Enter a Description about this Service Level Requirement configuration.
Services Offered	Displays the CMDB list.
Attachments	Upload the files that support Service Level Requirement configuration.

Service Availability

Performance

Maintenance

Target

Approval

The Target tab defines the operational performance goals that the source workgroup must meet for incident handling and request fulfillment. It captures measurable targets such as response and resolution times based on different priorities. This ensures that internal service levels are clearly defined and aligned with organizational or customer expectations.

Figure: Service Level Requirement Target Configuration

Incident Management Targets

This section sets the expected Response and Resolution times for different incident priorities. These targets ensure that critical incidents are addressed faster than lower-priority ones and help track internal compliance with SLA-driven commitments.

For more information, refer to the following Field Description.

Field	Description
Priority	Select Priority from the dropdown. Represents the severity level of the incident (example: Critical, High, Medium, Low).
Response Target	Enter Response Target. The value entered here is represented as % hence, it is the percentage of incidents (of a given priority) that must be responded to within the defined SLA time. Example: For P1 incidents: 95% is the Response Target, then 95% of P1 incidents must be acknowledged within SLA-defined time (example: 15 Minutes).
Resolution Target	Enter Resolution Target. The value entered here is represented as % hence, it is the percentage of incidents that must be resolved within the agreed SLA time. Example: For P2 incidents: 90% is the Resolution Target, 90% of P2 incidents must be resolved within the SLA (example: 4 Hours).
Effective Date	Select Effective Date, specifies from when the Targets become active or enforceable.
	Click Add to save the configuration in the Incident Management Target.

Request Fulfillment Targets

This section mirrors the incident targets but is focused on service requests (example: password resets, access requests, software installations). These targets help manage the delivery expectations of routine service tasks. For Field Description, refer to the Table described above.

The Performance tab in the Service Level Requirement configuration screen is designed to capture and enforce internal expectations for service quality and operational readiness. This includes how much workload a support function is expected to handle, the application's responsiveness, and how quickly incidents must be addressed and resolved.

These parameters help align internal teams with the agreed performance standards to ensure consistent delivery of services that support the overall SLA targets.

Figure: SLR Performance Configuration

Required Capacity: This defines the minimum capacity (example: resources, personnel, infrastructure) that the operational team must ensure is available to support the service.
Example: 10 agents should be available at all times to handle Level 2 support tickets.

Service Usage: Specifies the acceptable limits of usage or workload the internal team can handle over a specific time frame
Example: 500 tickets per day.

Response Time from Application: Indicates the maximum time the associated application should take to respond to an action or request initiated by the internal team.
Example: Application must respond to data retrieval requests within 2 seconds.

Response and Resolution Times:
Response Time: Time taken by the internal team to acknowledge or begin working on an issue after it is reported.
Example: Acknowledgment within 15 minutes of ticket assignment.

Resolution time: Time by which the issue should be fully resolved and service restored.
Example: Critical issues must be resolved within 4 hours.

The Performance tab ensures the internal operations team is informed about what is expected of them in terms of resource allocation, system response behavior, and turnaround times. Defining these parameters correctly supports effective service delivery, avoids SLA violations, and improves collaboration across service functions.

The Maintenance tab in the Service Level Requirement configuration screen is intended to define protocols and expectations related to planned or unplanned maintenance activities, especially those occurring during emergencies. This ensures that internal teams are aligned on how to respond and act when critical service components require urgent intervention or updates.

By capturing these details within an Operational Level Specification, organizations can maintain service continuity, minimize risk, and ensure that emergency actions are authorized and traceable.

Figure: Configure Service Level Requirement Maintenance

Maintenance Requirements (In Case of Emergency): This field captures the predefined requirements, steps, or conditions under which emergency maintenance can be carried out by the operational team or vendor.
Example: Downtime window allowed only between 10 PM–12 AM with prior 30-minute notice to all stakeholders.

Attachment Upload * : This is a required field that you must upload a supporting document outlining the emergency maintenance process, approvals, contact list, or any contingency plan related to the entry in the text field.
Example: Emergency maintenance standard operating procedure (SOP), Emergency contacts List, Risk assessment or impact analysis report, Downtime mitigation plan or rollback procedure.

The Approvals section is a critical section in the Service Level Requirement configuration process that facilitates structured review and formal agreement between the internal teams involved in service delivery. This section ensures that Service Workgroup approve the defined Service Level Requirement terms before they take effect.

Figure: Service Level Requirement Approvals Configuration

For more information, refer to the following Field Description:

Note
Once the SLR is submitted, Approval is enabled and the following Field Description is applicable.

Field	Description
Approver Name	Displays the Approver Name of based on the selected Service Workgroup.
Status	Select Status option from the dropdown list. Options displayed are as follows: Approved: To Approve the Service Level Requirement Rejected: To Reject the Service Level Requirement
Approval Date	Displays Approval Date.
Remarks	Enter Remarks, this is a field where the approver can provide comments, justifications, or feedback regarding their approval decision.

The Service Availability section is used to define and track the availability-related targets and expectations for specific infrastructure components that support a service. It captures measurable service-level requirements such as maximum interruptions allowed, acceptable downtime, utilization benchmarks, and notification methods.

By mapping these parameters to specific entities like servers or network components, this ensures that service uptime and reliability are properly governed as per business needs.

Figure: Service Availability

For more information, refer to the following Field Description:

Field	Description
Entity	Select the type of infrastructure entity for which availability is being measured. Dropdown options include Server, Network Device, Network Link. Example: Choose Server to configure availability for application or database servers.
Service Catalog	Select Service Catalog, it is the associated service from the Service Catalog that this entity supports.
Period	Select Period for service availability measurement from the options: Monthly, Quarterly, Semi-Annually, and Annually. Defines the evaluation frequency for availability measurement. Example: Choose “Monthly” if you want to measure uptime and interruptions on a monthly basis
No. of Interruptions	Enter a value for No. of Interruptions, this specifies the maximum number of acceptable service interruptions during the selected period. Example: Enter "2" if only two unplanned interruptions are acceptable per quarter.
Availability Threshold Target	Enter value for Availability Threshold Target, this is the minimum acceptable percentage of uptime for the selected entity within the defined period. Example: 99.9% monthly uptime means only ~43 minutes of downtime is acceptable per month
Scheduled No. of Downtime	Enter a value for Scheduled No. of Downtime, this is the expected or planned number of downtime events (example: maintenance) within the evaluation period. Example: Enter "1" if monthly maintenance is expected and allowed without impacting SLA compliance.
Utilization Target	Indicates target usage levels of the selected entity, such as CPU, bandwidth, or memory utilization.
Notification Methodology	Describe the Notification Methodology, how and when notifications should be triggered when availability drops below target. Example: Notify IT Ops via email immediately after 2 consecutive failed ping checks.” “Trigger auto-escalation after 10 minutes of sustained downtime.”
Effective Date	The date from which the availability metrics and thresholds become enforceable.

Click Submit to add the Configuration to SLR List page.

Was this article helpful?

What's Next

Service Level Requirement List

Table of contents