Appendix H - Service Level Requirements~1.xlsx

XLSX spreadsheet 19 KB Posted

Attached to
Online Content for Professional Education and Training
Solicitation number
BD-23-1107-1107T-TRC01-81455
Issued by
Suffolk County, Massachusetts

About this file

This document outlines the Service Level Requirements (SLRs) for a state and local contract opportunity in Massachusetts. The SLRs cover incident response and resolution for the production solution, with requirements defined across four priority levels. For Priority 1 (critical) incidents, the response time is 30 minutes 95% of the time, and the resolution time is 4 hours 98% of the time. For Priority 2 (high) incidents, the response time is 4 hours 95% of the time, and the resolution time is 8 hours 98% of the time. The document also includes SLRs for Priority 3 (medium) and Priority 4 (low) incidents, with varying response and resolution targets.

The state and local contract opportunity is for "Online Content for Professional Education and Training" in Massachusetts. No additional details about the products, services, quantities, timelines, or other aspects of the contract opportunity are provided in the given information.

View the file

Other files

Show all 21

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

Service Level Requirements

Appendix H - Service Level Requirements
IDCategoryTypeNameDescriptionService Level Time FrameService Level MetricMeasurement FormulaMeasurement PeriodReporting PeriodMeasurement MethodCritical or Monitored
SLR-1MaintenanceIncident Response and ResolutionPriority 1 Incidents - Emergency; Critical Business Business ImpactThe production solution is not available; the incident disrupts an important component or critical business process in one or more business units and involved parties cannot work around the disruption manually. The problem has caused work to stop immediately and completely, which is affecting a primary business process or a broad group of users. There is no available way to work around this problem.Response Time30 minutes95% of the timePerformance Response = Incidents Response Within Target Per Priority/Total Incidents Per PriorityMonthlyMonthlyService management toolCritical
Resolution Time4 hours98% (or 1 miss per month if the volume is low)Performance Resolution = Incidents Resolution Within Target Per Priority/Total Incidents Per Priority
SLR-2MaintenanceIncident Response and ResolutionPriority 2 Incidents - High; Major Business ImpactThe incident affects a business process to such a great extent that it degrades a business function or affects multiple users. There may be a way to work around this problem, but the solution is not easily sustainable.Response Time4 hours95% of the timePerformance Response = Incidents Response Within Target Per Priority/Total Incidents Per PriorityMonthlyMonthlyService management toolCritical
Resolution Time8 hours98% (or 1 miss per month if the volume is low)Performance Resolution = Incidents Resolution Within Target Per Priority/Total Incidents Per Priority
SLR-3MaintenanceIncident Response and ResolutionPriority 3 Incidents - Medium; Moderate Business ImpactThe incident affects a business process, making certain functions unavailable to end users or degrading the solution. There may be a way around this problem.Response Time1 business day90% of the timePerformance Response = Incidents Response Within Target Per Priority/Total Incidents Per PriorityMonthlyMonthlyService management toolCritical
Resolution Time2 business days85%Performance Resolution = Incidents Resolution Within Target Per Priority/Total Incidents Per Priority
SLR-4MaintenanceIncident Response and ResolutionPriority 4 Incidents - Low; Minimal Business ImpactThe incident has little impact on normal business processes, and the Vendor can resolve it on a scheduled basis. There is a
way to work around this problem.Response Time1 business day90% of the timePerformance Response = Incidents Response Within Target Per Priority/Total Incidents Per PriorityMonthlyMonthlyService management toolCritical
Resolution Time3 business days85%Performance Resolution = Incidents Resolution Within Target Per Priority/Total Incidents Per Priority
SLR-5MaintenanceIncident Response and ResolutionIncident Response TimeTime to RespondMonthlyIncident Response within 15 minutes, ≥ 95%, Incident Response within 30 minutes, = 100%[Number of Incidents that met SLR]
[The total number of Incidents in the measurement period]MonthlyMonthlyTBDMonitored
SLR-6MaintenanceIncident Response and ResolutionIncident Notification TimeTime to Respond to Customer of Priority 1 or 2 IncidentsMonthly<15 minutes, 98% of the time[Number of incidents within Service Level Metric]

[Total number of incidents during Measurement Period] = “Percent (%) Attained”

For Incidents due to change — Measure every 4 weeksMonthlyMonthlyTBDMonitored
SLR-7MaintenanceRoot Cause Analysis (RCA)Root Cause AnalysisTime to Report - For Priority Priority 1 or 2 Incidents and as requestedMonthlyWithin 5 days of reported failure or as agreed by the MPS, 98% of the time[Number of instances within Service Level Metric]

[Total number of instances during Measurement Period] = “Percent (%) Attained”

For Incidents due to change — Measure every 4 weeksMonthlyMonthlyTBDMonitored
SLR-8MaintenanceRoot Cause Analysis (RCA)Root Cause ResolutionCompleted per RCA planWeeklyComplete the RCA plan per approved schedule, 100% of the timeCompleted within required timeWeeklyMonthlyTBDMonitored
SLR-9OperationsAvailabilityPlanned Service WindowThe number of hours per week that an application must be available.

Maximum 168 (7 * 24)

Excludes planned maintenance down-time Weekly 166, allowing a two hour planned maintenance window each week. (D * H) - M Where D = number of days per week system must be available H = hours per day when system must be available

M = hours of planned downtime permitted for maintenance activitiesWeeklyMonthlyService Management ToolMonitored
SLR-10OperationsAvailabilityScheduled DowntimeAvailability per locationWeekly≤4 hours down time per month (per component), 100% of the timeActual scheduled downtime per component is defined as: monthly outage duration - monthly planned outageWeeklyMonthlyService Management ToolMonitored
SLR-11OperationsAvailabilityUptimeAvailability of contentMonthly99%[Availability (%) = 100% — Unavailability (%)]
Where Unavailability is defined as: (sum outage duration x 100%) ÷ (schedule time — planned outage)WeeklyMonthlyService Management ToolCritical
SLR-12OperationsApplication Response TimeResponse Time of the Application - for Solution ScreensEffective response time for users accessing the applicationSun-Sat, 00:00-24:00 ET (7 x 24)≤2 seconds for 90% of recorded transactionsResponse time of the application for the user to include all functions of the application, but excluding any latency caused by third party integrations or Trial Court networkDailyMonthlyDedicated Transaction Response Time Monitoring SoftwareCritical
SLR-13OperationsApplication Response TimeResponse Time of the Application - for Recorded TransactionsEffective response time for users accessing the applicationSun-Sat, 00:00-24:00 ET (7 x 24)≤5 seconds for 99.5% of recorded transactionsResponse time of the application for the user to include all functions of the application, but excluding any latency caused by third party integrations or Trial Court networkDailyMonthlyDedicated Transaction Response Time Monitoring SoftwareCritical
SLR-14OperationsApplication Response TimeResponse Time of the Application - for all Recorded TransactionsEffective response time for users accessing the applicationSun-Sat, 00:00-24:00 ET (7 x 24)≤20 seconds for 100% of all recorded transactionsResponse time of the application for the user to include all functions of the application, but excluding any latency caused by third party integrations or Trial Court networkDailyMonthlyDedicated Transaction Response Time Monitoring SoftwareCritical
SLR-15OperationsInformation Transmission/ReadinessIntegration Completion (e.g., Case Initiation Completion)Integration Performance (e.g., eLC and Content Integration Performance)MonthlyElapsed time ≤ 90 seconds from transmission of integration record, 99.9% of the time (e.g., case from MassCourts to the CMS)[Number of instances of within Service Level Metric]
[Total number of integration records (e.g., cases) initiated]MonthlyMonthlyTBDCritical
SLR-16RecoveryRecovery Time Objective (RTO) and Recovery Point Objective (RPO)Recovery Time Objective (RTO) and Recovery Point Objective (RPO)Recovery Time and Data RecoveryDesignated recovery period following a disaster≤8 hours with ≤1 hour of data loss[Number of instances within Service Level Metric]
[Total number of instances during Measurement Period]Designated recovery period following a disasterPeriodically throughout the recovery periodTBDCritical
SLR-17RecoverySemi-Annual Disaster Recovery (DR) TestSemi-Annual Disaster Recovery (DR) TestSemi-Annual DR TestSemi-annualSemi-annual test completed, DR test results made available to the MPS and accepted by the MPS in accordance with the criteria agreed upon by the Vendor and the MPS prior to execution of each test, 100% of the time[Number of instances within Service Level Metric]
[Total number of instances during Measurement Period]Semi-annualSemi-annualTBDMonitored
SLR-18DocumentationRelease DocumentationRelease Documentation delivered within agreed timingDocumentation received within agreed time prior to Release dateMonthlyAll documentation is available[Number of instances (releases) within Service Level Metric]

[Total number of instances during Measurement Period] Monthly Quarterly TBD Monitored

&"Arial,Regular"&K000000Page B.1.&P

Definition: An incident is an event that is not part of normal operations that disrupts operational processes. It may involve the failure of a feature or service that should have been delivered or some other type of operation failure.

File details come from the government source that posted it. Updated .