Attachment C- Minimum Service Level Agreement .xlsx
XLSX spreadsheet 18 KB Posted
- Attached to
- Labratory Information Management-IDOA
- Solicitation number
- 26-448DOIT-APP44-B-52888
- Issued by
- Illinois
About this file
This is a Minimum Service Level Agreement attachment for a Laboratory Information Management System solicitation issued by the Illinois Department of Innovation and Technology on behalf of the Illinois Department of Agriculture. The agreement establishes service level requirements and performance standards that the selected vendor must maintain throughout the contract term. The document outlines specific metrics and benchmarks for system availability, response times, and support services that the vendor must consistently achieve to meet contractual obligations.
The service level agreement specifies measurable performance targets across critical operational areas, including system uptime requirements, incident response and resolution timeframes, and user support availability standards. The agreement defines penalties or remedies for non-compliance with established service levels and establishes a framework for monitoring, reporting, and validating vendor performance against agreed-upon metrics. These standards ensure that the Laboratory Information Management System maintains adequate functionality and reliability to support the Department of Agriculture's operational requirements throughout the contract period.
View the file
Other files
On GovTribe
Work with this file
- Download the original file
- Contacts named in this file
- Similar government files
- Ask GovTribe AI about this file
Text version
SLA
| ID | Service Level Requirement (SLR) Name | Service Level Requirement (SLR) Description/Objective | Target | Measurement Formula | Service Level Requirement (SLR) Reporting Period | Measurement of Non-Compliance | Penalty |
| S1 | Availability | The Application should be available to all users of the System | 99.90% | (# of minutes of uptime during the reporting period) / (Total planned uptime during the reporting period) | Monthly | Uptime percentage below the target | For each 0.1% below 99.9%, apply a service credit equal to 2% of monthly fees |
If uptime falls below 98%, apply an additional 10% penalty for that month S2 Performance - Average Response Time System performance should meet end-user expectations to deliver increased customer satisfaction and efficiency gains Average response time should be 2 seconds (response time from entering command to receiving result) (Sum of all transaction response time) / (Number of transactions) Monthly Time difference between measured average response time and 2 seconds If average response time exceeds 2 seconds by more than 0.5 seconds, 1% of monthly fees per 0.5-second increment
| S3 | Performance - Maximum Response Time | System performance should meet end-user expectations to deliver increased customer satisfaction and efficiency gains | 95% of transactions complete (response time from entering command to receiving result) in less than 3 seconds | (Transactions completed within required time) / (Total Transactions) | Monthly | Percentage of transactions below target | If less than 95% of transactions meet the 3-second threshold, 2% of monthly fees per percentage point below target |
| S4 | Critical and High Severity Incident Resolution Timeframe | Critical and High severity incidents should be addressed quickly to minimize the business impact of the incident (critical and high severity incidents are defined in the incident and defect priority tab) | 95% of critical and high severity incidents fixed within specified resolution times | (Number of critical and high severity incidents fixed within SLA Target) / (Total number of critical and high severity incidents) | Monthly | Per incident not fixed exceeding the resolution time by 20% | $500 per incident or defect not resolved within SLA timeframe |
If resolution compliance falls below 90%, apply additional 5% of monthly fees S5 Critical and High Severity UAT Defect Resolution Timeframe Critical and high UAT defects should be addressed quickly to minimize the impact of the defect on UAT timelines (critical and high severity UAT defects are defined in the incident and defect priority tab) 95% of critical and critical and high severity UAT defects are fixed within specified resolution times (Number of critical and high severity UAT defects fixed within SLA Target) / (Total number of critical and high severity UAT defects) Monthly Per defect not fixed exceeding the resolution time by 25% $500 per incident or defect not resolved within SLA timeframe
If resolution compliance falls below 90%, apply additional 5% of monthly fees
| S6 | Security Incidents Response Time | DoIT security point-of-contact should be notified of any security incidents as quickly as possible | All of notifications completed within 1 hours of identifying | |
| (all notifications should occur as soon as possible) | Number of incidents not reported within 1 hour | Monthly | Per incident not reported within 1 hour | $1,000 per incident not reported within 1 hour |
| S7 | Disaster Recovery Restoration Timelines | In case of a disaster and crisis situation that effects the availability of the service, the system has to be restored as rapidly as possible with minimal data loss. | The Recovery Time Objective (RTO) to be less than 0.5 hour, and the Recovery Point Objective (RPO) to be no data loss | |
| Actual time to restoring service from disaster declaration, and amount of data lost attributed to occurrence of disaster | Per disaster event occurrence | Minutes greater than target | $2,500 per hour beyond RTO target |
$5,000 per occurrence of data loss S8 Delivery of Enhancements To avoid scheduling issues and potential end-user issues, all enhancements should be completed in alignment with the proposed schedule Enhancements deployed into production on schedule (Date approved) - (Planned production deployment date (captured in the proposal)) Per enhancement DDI effort Per day the enhancement is deployed to production after the planned date $250 per day late per deliverable or enhancement
If delay exceeds 10 business days, apply additional 5% of monthly fees S9 DDI Deliverables Timeliness Delivery of project milestone deliverables according to the planned schedule is critical to the success of the AGR solution being deployed. Deliver key milestone deliverable according to agreed to schedule (Date deliverable received) - (Planned deliverable date (captured in the approved project plan)) Per milestone deliverable Per day the deliverable is submitted after the planned date $250 per day late per deliverable or enhancement
If delay exceeds 10 business days, apply additional 5% of monthly fees
Incidents
| Instructions | ||||
| Table 1. Incident Severity/Priority Definitions and Security Incidents Definitions | ||||
| The grid below establishes the criteria for assigning priority/severity to defects and incidents. | ||||
| Scenario Description | Urgency | Impact | ||
| Location | Multiple Users | Single User | ||
| A full outage of multiple services or all business capabilities and/or noncompliance with regulations. | Critical | High | High | |
| An incident completely affecting a service or business capability, no workaround available. | Critical | High | Medium | |
| An incident partially to significantly affecting a service or business capability; workaround is available. | Medium | Medium | Medium | |
| An incident that has no impact to the availability of the affected service or business capability; redundancy is available. | Low | Low | Low |
| Instructions | ||||
| Table 2. Critical and High Severity User Acceptance Test (UAT) Defect Resolution Definitions and Timeframes | ||||
| The service level standards below apply to UAT defects. | ||||
| Defect Resolution Timeframe is the elapsed time from when the defect is reported to the Vendor to the time the defect is resolved. | ||||
| UAT Defect | ||||
| Severity/Priority | UAT Defect Resolution Definition | Defect Resolution | ||
| Timeframe | Assessment | |||
| Severity 1 - Critical | 1. No additional testing can occur until the defect is resolved. This is often referred to as a “showstopper”. | 12 hours | Stops Testing | |
| 2. Defects where the Solution will not complete a critical process or essential functionality. | ||||
| 3. Terminal defects or defects which cause a “total solution hang” are always Critical defects. | ||||
| Severity 2 - High | 1. Scripts/scenarios for a critical process cannot continue, but other scripts/scenarios are unaffected, and testing can continue for those unaffected scripts/scenarios. | 1 business day | Stops Critical Scenario Testing | |
| 2. A large scale data defect, or corruption, created or caused by the Solution which will lead to production problems. | ||||
| 3. Missing “in-scope” functionality from the design of an Enhancement Request (ER) ticket being implemented by an upcoming release. No alternative functionality is available in the system to support what is missing from the ER ticket. | ||||
| Severity 3 - Medium/Low | 1. Scripts/scenarios for a non-critical process cannot continue or the actual results of non-critical scripts/scenarios are not as expected, but do not prevent the continued execution of other scripts/scenarios. | 5 business days | Assurance Bug/Problem Sub Task | |
| 2. Any data defect, or corruption, created or caused by the Solution which will not lead to production problems and/or can be corrected with a temporary production data update process. | ||||
| 3. Missing “in-scope” functionality from the design of an ER ticket being implemented by an upcoming release, but alternative functionality is available in the system to support what is missing from the ER ticket. |
| Instructions | ||
| Table 3. Critical and High Severity Production Defect Resolution Definitions and Timeframes | ||
| The service level standards below apply to incidents and defects in Production. | ||
| Incident Resolution Timeframe is the elapsed time from when the incident is reported or escalated to the Vendor's Help/Service Desk to the time the incident is resolved. | ||
| Incident Severity/Priority | Production Defect Resolution Definition and Timeframe | Incident Resolution Timeframe |
| Severity 1 - Critical | The production system is down, or mission critical functionality is inoperable. Users are unable to reasonably perform their normal functions. The situation is considered an emergency. | 4 hours |
| Examples: portal outage, network outage, critical system component outage (e.g., lab operations) | ||
| Severity 2 - High | The system is usable but severely limited. Significant impact to application functionality, data, or performance which is resulting in a high number of users being unable to perform their normal functions or is resulting in a high number of customer benefits being blocked/incorrect. There is no workaround, or it is cumbersome to business operations. | 1 business day |
| Examples: Integration hub is down resulting in lack of ability to receive test orders from EHRs, or web-based provider portal is down resulting in lack of ability to update patient demographics, submit test orders, and view and print certified result reports. | ||
| Severity 3 - Medium | Moderate impact to application functionality, data, or performance resulting in multiple users being impacted in their normal function or resulting in a high number of customer benefits being blocked/incorrect. For application functionality issues, a readily apparent and DoIT approved workaround exists. For performance issue, the degradation is minor and is not rendering the normal functions of the system unusable or causing a significant disruption to users. | 5 business days |
| Examples: Incorrect abnormal range values for a test or assay small subset of a program), incorrect validation requiring workaround. | ||
| Severity 4 - Low | Minor loss of application functionality resulting in limited or no impact to users being able to perform their normal function. A workaround is not required as a result of the limited impact. | 20 business days |
| Examples: typo with material impact, display alignment issues |
File details come from the government source that posted it. Updated .