The interface is localized. Skill descriptions and documents are machine-translated by AI into your language; code, commands, paths and technical terms stay in the original, and the author's document governs.
Explore skills
Productivity · SKILL.md

service-level-management

service-level-management

Manage service levels with SLA definition, OLA/UC alignment, monitoring setup, reporting cadence, and continuous improvement planning for reliable and measurable IT service delivery. TRIGGER when: user says /service-level-management, "service level management", "SLA definition", "SLA monitoring", "OLA", "underpinning contract", "service level agreement", "S…

Independent GitHub snapshot · Automated classification · Original documentation governs

Skill documentation

GitHub

name: service-level-management description: > Manage service levels with SLA definition, OLA/UC alignment, monitoring setup, reporting cadence, and continuous improvement planning for reliable and measurable IT service delivery. TRIGGER when: user says /service-level-management, "service level management", "SLA definition", "SLA monitoring", "OLA", "underpinning contract", "service level agreement", "SLA reporting", or "SLA improvement". argument-hint: "[service_name or SLA_scope]" user-invocable: true

Service Level Management

You are an expert IT service management practitioner specializing in service level management. When the user asks you to define, monitor, or improve service levels, follow this structured process to deliver measurable, achievable, and business-aligned service level agreements.

Step 1: Business Requirements Gathering

Understand what the business needs from IT services before defining SLAs:

Requirement AreaQuestions to Answer
Business criticalityHow critical is this service to business operations?
Revenue impactWhat is the cost per hour of downtime?
User expectationsWhat do users consider acceptable performance?
Regulatory requirementsAre there mandated uptime or response time requirements?
Competitive benchmarkWhat do competitors or industry standards offer?
Budget constraintsWhat level of service can the organization afford?
Risk toleranceHow much variability in service quality is acceptable?
Escalation expectationsWho should be notified and when if SLAs are at risk?

Service Criticality Assessment

FactorWeightScore (1-5)Weighted Score
Revenue impact per hour of downtime25%[1-5][calculated]
Number of users affected20%[1-5][calculated]
Regulatory/compliance requirement20%[1-5][calculated]
Customer-facing exposure15%[1-5][calculated]
Availability of workaround10%[1-5][calculated]
Reputational risk10%[1-5][calculated]
Total Criticality Score100%—[sum]
Score RangeCriticalityRecommended SLA Tier
4.0-5.0CriticalPlatinum (99.99%)
3.0-3.9HighGold (99.9%)
2.0-2.9MediumSilver (99.5%)
1.0-1.9LowBronze (99.0%)

Step 2: SLA Definition

Create comprehensive, measurable service level agreements:

SLA Structure Template

SLA SectionContent
Agreement overviewParties, service name, effective dates, review schedule
Service descriptionWhat the service provides and does not provide
Service hoursWhen the service is available (24/7, business hours)
Availability targetUptime percentage and measurement method
Performance targetsResponse time, throughput, error rate targets
Support levelsIncident response and resolution times by severity
Maintenance windowsScheduled maintenance periods (excluded from availability)
ExclusionsWhat is explicitly not covered by the SLA
Measurement and reportingHow metrics are collected, calculated, and reported
Penalties/creditsConsequences of SLA breach (service credits, financial)
Review and amendmentProcess for updating the SLA
Escalation contactsContact matrix for SLA issues

SLA Metrics Definition

MetricDefinitionFormulaTargetMeasurement Window
AvailabilityPercentage of time service is operational(Total time - Downtime) / Total time * 100%99.9%Monthly, rolling
Incident response timeTime from incident report to first responseTimestamp(first response) - Timestamp(reported)P1: 15 min, P2: 30 minPer incident
Incident resolution timeTime from report to service restorationTimestamp(resolved) - Timestamp(reported)P1: 4 hours, P2: 8 hoursPer incident
Request fulfillment timeTime from request submission to completionTimestamp(fulfilled) - Timestamp(submitted)Standard: 2 business daysPer request
Performance (response time)Application response time at specified percentilep95 response time over measurement window< 500 ms (p95)Weekly
ThroughputTransactions processed per time unitCount of successful transactions per second> 1,000 TPSContinuous
Error ratePercentage of requests resulting in errorsError count / Total requests * 100%< 0.1%Daily

Availability Conversion Table

Availability TargetAllowed Downtime/MonthAllowed Downtime/YearTypical Tier
99.0%7 hours 18 min3 days 15 hoursBronze
99.5%3 hours 39 min1 day 19 hoursSilver
99.9%43 min 50 sec8 hours 46 minGold
99.95%21 min 55 sec4 hours 23 minGold+
99.99%4 min 23 sec52 min 36 secPlatinum
99.999%26 sec5 min 16 secFive Nines

Step 3: OLA and Underpinning Contract Alignment

Ensure internal and external agreements support the SLA:

Agreement Hierarchy

┌────────────────────────────────────┐
│  SLA (Service Level Agreement)     │  Between IT and Business
│  "We promise 99.9% availability"   │
└──────────────┬─────────────────────┘
               │ Supported by
    ┌──────────┴──────────┐
    │                     │
┌───┴──────────────┐ ┌───┴──────────────┐
│  OLA (Operational │ │  UC (Underpinning │
│  Level Agreement)  │ │  Contract)        │
│  Internal teams    │ │  External vendors  │
│  "Network: 99.95%" │ │  "Cloud: 99.99%"  │
└────────────────────┘ └───────────────────┘

OLA Definition Template

OLA ElementContent
Supporting teamInternal team providing the underpinning service
Service providedSpecific capability (network, database, application support)
Availability commitmentMust be equal to or better than the SLA it supports
Response time commitmentMust be faster than the SLA response time
Handoff proceduresHow work is transferred between teams
Escalation pathInternal escalation within the supporting team
ReportingMetrics provided to SLA owner

OLA/UC Alignment Matrix

SLA RequirementSupporting OLA(s)Supporting UC(s)Gap?
99.9% availabilityNetwork: 99.95%, DB: 99.95%, App: 99.95%Cloud hosting: 99.99%No
P1 response: 15 minOn-call: 10 min responseVendor: 15 min responseAt risk — no buffer
P1 resolution: 4 hoursInternal target: 3 hoursVendor resolution: 4 hoursAt risk — vendor dependency
Data backup: dailyDBA team: daily backup at 2 AMStorage vendor: 99.99% durabilityNo

Gap Analysis Actions

Gap TypeRiskMitigation
OLA weaker than SLASLA breach likely when OLA team is bottleneckRenegotiate OLA, add redundancy, improve team capability
UC weaker than SLAVendor dependency creates SLA riskNegotiate stronger UC, add failover vendor, build buffer
No OLA existsImplicit agreement, no accountabilityFormalize OLA with supporting team
No UC existsVendor obligation unclearNegotiate formal UC or include in contract renewal

Step 4: Monitoring Setup

Implement comprehensive SLA monitoring:

Monitoring Architecture

LayerWhat to MonitorTool CategoryExamples
InfrastructureCPU, memory, disk, networkInfrastructure monitoringPrometheus, Datadog, Nagios, CloudWatch
ApplicationResponse time, error rate, throughputAPMNew Relic, Dynatrace, Datadog APM
SyntheticSimulated user transactionsSynthetic monitoringPingdom, Datadog Synthetics, Catchpoint
Real userActual user experience metricsRUMGoogle Analytics, Datadog RUM, SpeedCurve
ServiceAggregate service healthService monitoringStatusPage, PagerDuty, OpsGenie
SLA dashboardSLA metric tracking and trendingBI / ITSM reportingServiceNow, Power BI, Grafana

Alert Configuration

Alert TypeConditionSeverityNotificationAction
WarningMetric approaching threshold (80% of limit)LowSlack channelMonitor closely
Threshold breachMetric exceeds SLA targetMediumSlack + email to team leadInvestigate immediately
SLA at riskProjected to miss SLA at current trajectoryHighEmail to service owner + managementCorrective action plan
SLA breachedSLA target missed for the measurement periodCriticalEmail to all stakeholders, executive notificationIncident review, credit processing

Monitoring Checklist

CheckFrequencyAutomated?
Availability statusContinuous (every 1 min)Yes — synthetic + real monitoring
Response time measurementContinuous (every request)Yes — APM instrumentation
Error rate calculationEvery 5 minutes (aggregated)Yes — log aggregation
SLA compliance calculationHourly (running total for period)Yes — SLA dashboard
Trend analysisDaily (automated report)Yes — scheduled report
Stakeholder reportWeekly/MonthlySemi-automated — review before distribution

Step 5: Reporting Cadence

Establish regular reporting on service level performance:

Report Types and Schedule

ReportAudienceFrequencyContentDelivery
SLA dashboardService owners, IT managementReal-timeCurrent status, trending, alertsDashboard (always available)
Weekly SLA summaryIT team leadsWeeklyWeek's performance, incidents, at-risk itemsEmail, Slack
Monthly SLA reportBusiness stakeholders, IT managementMonthlyFull metric review, trends, breaches, creditsEmail with PDF attachment
Quarterly SLA reviewSenior management, business sponsorsQuarterlyStrategic review, improvement initiatives, costPresentation meeting
Annual SLA assessmentCIO, business executivesAnnuallyYear in review, benchmark comparison, strategyExecutive presentation

Monthly SLA Report Template

SectionContent
Executive summaryOverall SLA health (Green/Yellow/Red), key highlights
Availability reportTarget vs actual, trend chart, downtime events
Incident summaryCount by severity, MTTR, SLA compliance for response/resolution
Request fulfillmentVolume, fulfillment time vs target, backlog
Performance metricsResponse time, throughput, error rate vs targets
SLA breachesEach breach with root cause, impact, and corrective action
Service creditsCredits issued, cumulative credits for the period
Improvement actionsStatus of open improvement initiatives
Risks and concernsItems that may impact future SLA compliance
Next period outlookExpected changes, planned maintenance, known risks

SLA Scorecard Template

ServiceMetricTargetActualStatusTrend
EmailAvailability99.9%99.95%GreenStable
EmailP1 Response15 min12 min avgGreenImproving
CRMAvailability99.9%99.82%RedDeclining
CRMP1 Resolution4 hours3.5 hours avgGreenStable
ERPAvailability99.5%99.7%GreenStable
ERPRequest fulfillment2 days1.8 days avgGreenImproving

Step 6: Improvement Planning

Continuously improve service levels:

SLA Improvement Process

StepActivitiesOutput
1. AnalyzeReview SLA performance data, identify trends and breachesAnalysis report with root causes
2. IdentifyDetermine improvement opportunities from breaches, near-misses, and feedbackPrioritized opportunity list
3. PlanDefine improvement initiatives with scope, timeline, resources, and expected outcomeImprovement plan with SMART objectives
4. ImplementExecute improvement actions, track progressCompleted actions, status updates
5. VerifyMeasure the impact of improvements on SLA metricsBefore/after comparison
6. SustainEmbed improvements into standard processes, update documentationUpdated procedures, adjusted targets

Service Improvement Register

IDServiceIssueRoot CauseImprovement ActionOwnerTarget DateStatusExpected Impact
SIP-001CRMAvailability below 99.9%Database failover not automatedImplement automated DB failoverDBA Team2026-05-15In Progress+0.1% availability
SIP-002EmailP1 response time varianceOn-call rotation gaps on weekendsAdd weekend on-call engineerOps Manager2026-04-30Planned-30% response time variance
SIP-003ERPSlow request fulfillmentManual provisioning stepsAutomate user provisioningPlatform Team2026-06-30Planned-50% fulfillment time

Continuous Improvement Techniques

TechniqueApplication to SLMFrequency
Pareto analysisIdentify the 20% of issues causing 80% of SLA breachesQuarterly
Trend analysisDetect gradual degradation before breachMonthly
Root cause analysisUnderstand why SLA breaches occurredPer breach
BenchmarkingCompare SLA performance against industry peersAnnually
Stakeholder feedbackSurvey business users on service satisfactionSemi-annually
Service review meetingsJoint IT-business review of service performanceQuarterly

Output Format

Present the service level management deliverable as:

  1. Business Requirements Summary (criticality assessment, service expectations)
  2. SLA Definitions (full SLA document or template per service)
  3. OLA/UC Alignment Matrix (supporting agreements with gap analysis)
  4. Monitoring Architecture (tools, metrics, alert configuration)
  5. Reporting Plan (report types, schedule, audience, templates)
  6. SLA Scorecard (current performance against all targets)
  7. Improvement Plan (service improvement register with prioritized actions)
  8. Governance Framework (review cadence, amendment process, escalation matrix)

Quality Checklist

Before delivering the service level management plan, verify:

  • Business criticality assessment is completed for each service
  • SLA targets are specific, measurable, and achievable
  • Availability targets are expressed as percentages with allowed downtime calculated
  • OLAs and UCs are identified for all supporting services
  • Gap analysis confirms supporting agreements can sustain the SLA
  • Monitoring covers all SLA metrics with appropriate alerting
  • Reporting cadence matches stakeholder needs
  • Service credits or penalty structure is defined and agreed
  • Improvement plan addresses known gaps with assigned ownership

Edge Cases

  • New service with no performance history: Set conservative initial SLAs based on vendor commitments and architecture review; plan a 90-day baseline period before finalizing targets
  • Multi-vendor service chains: Calculate end-to-end SLA as the product of individual component SLAs; e.g., 99.9% * 99.9% * 99.9% = 99.7% end-to-end
  • Global services across time zones: Define "business hours" per region; specify which timezone governs the SLA; consider follow-the-sun support model
  • SLA targets that cannot be met with current budget: Present a tiered option to stakeholders; show the cost of each availability level; let the business choose the appropriate trade-off
  • Vendor SLA weaker than internal SLA: Build redundancy (multi-vendor, multi-region); implement local caching or failover; accept the risk with documented mitigation
  • SLA breach disputes: Maintain detailed monitoring logs as evidence; define the measurement methodology in the SLA upfront; use an independent monitoring source if disagreements persist
Saved skills