What Is Service Level? Definition, KPIs and SLAs Explained
What is service level? Learn the meaning, how SLAs work, key KPIs, and how nonprofits and volunteer programs set and measure them.
On this page
A service level is a measurable performance target that states how well a service must perform, such as answering 80% of calls within 20 seconds. For a volunteer coordinator, the useful question is whether that target reflects what volunteers need.
You might be looking at a provider's healthy status dashboard while an applicant waits for clearance and a shift leader asks whether they can join the weekend roster. Nobody seems to have broken a promise, yet you still can't give the volunteer an answer. That's the difference between measuring a working system and measuring a useful service.
Table of Contents
- What a Service Level Means in Plain Terms
- Core Dimensions and Metrics Every Service Level Uses
- Service Level Agreements and What They Must Specify
- Service Level Examples for Volunteer and Nonprofit Work
- How to Set a Service Level You Can Keep
- Measuring and Reporting Whether Service Levels Are Met
- Choose One Service Level to Measure This Month
What a Service Level Means in Plain Terms
A service level is the measurable standard itself. A service-level agreement, or SLA, is the written agreement that records the standard, responsibilities, measurement rules, and consequences of missing it. They're related, but they aren't interchangeable.
Say a restaurant gives you an estimated waiting time for a table. You can check the promise against a clock, provided everyone agrees whether the wait ends when the host calls your name or when you're seated. A promise that sounds clear can still leave room for disagreement.
The same problem appears in volunteer programs. A coordinator might count a request as handled when they forward it to a department lead, while the volunteer considers it handled only when they receive a decision.
Separate the service, measure, and target
Every useful service level has distinct parts:
- The service is the work being delivered, such as answering volunteer calls.
- The measure is the evidence you collect, such as the share of calls answered before a waiting-time threshold.
- The target is the result you've agreed counts as acceptable performance.
Keep those parts separate when drafting a promise. Answering volunteer calls describes an activity, not a service level. Answering them promptly still leaves the coordinator and volunteer free to interpret promptly differently.
A measurable promise isn't the whole experience
Service quality includes whether someone received a helpful, respectful, accurate answer. A service level makes a particular part of that experience checkable, but it doesn't capture everything.
Consider a food bank handling shift-swap requests. The team could measure whether volunteers receive a decision by the published deadline, rather than whether someone opened their email. That gives the coordinator a result they can report and gives volunteers a promise they can understand.
A quick refusal without an explanation might meet the timing target and still leave someone frustrated. Pair the timing measure with a simple review of whether replies resolve the request. When someone asks, “What is service level?”, the practical answer is a standard you can test, not a substitute for good judgment.
Core Dimensions and Metrics Every Service Level Uses
Service levels commonly draw on availability, response time, throughput, incident response, and restoration or resolution time. The right choice depends on what you're protecting: access to a portal, a timely answer, enough processing capacity, or recovery after something breaks.
The diagram separates these dimensions so you can match each to a volunteer-facing promise.
Availability needs a defined service window
The availability calculation is agreed service time minus downtime, divided by agreed service time, expressed as a percentage. Count only the service window you've explicitly agreed to measure.
For a 30-day, round-the-clock service window, 99.9% availability permits approximately 43.2 minutes of downtime, while 99.99% permits approximately 4.32 minutes, using the availability method described in Broadcom's ITIL service-level reference.
That small-looking change in the target leaves much less recovery time. Before requesting it, consider whether the service needs stronger redundancy, monitoring, change controls, and incident coverage.
Core service level metrics with formulas and examples
The examples below describe what to measure, rather than prescribing universal targets.
| Metric | What It Measures | How It Is Calculated | Nonprofit Example |
|---|---|---|---|
| Availability | Share of agreed time the service is usable | Agreed time minus downtime, divided by agreed time, expressed as a percentage | Volunteer sign-up portal usable throughout recruitment |
| Answer rate within threshold | Share of offered contacts answered in time | Contacts answered within target divided by contacts offered, expressed as a percentage | Helpline calls answered before the agreed waiting limit |
| Average speed of answer | Average wait among answered contacts | Total waiting time of answered contacts divided by answered contacts | Average intake-line wait among callers who got through |
| Abandonment rate | Share of callers who leave before an answer | Abandoned contacts divided by contacts offered, expressed as a percentage | Intake callers who hang up in the queue |
| Response time | Time until the first reply | Reply timestamp minus request timestamp | Volunteer email receives a substantive reply |
| Restoration time | Time to bring a user-facing service back | Service-restored timestamp minus outage-start timestamp | Donor database usable again after an outage |
| Occupancy | Share of available staff time spent handling work | Handling time divided by available time, expressed as a percentage | Coordinator call-handling time compared with available rostered time |
For contact queues, contacts offered is the important denominator. Counting only answered contacts leaves out the people who gave up waiting.
Average speed of answer describes the callers who reached someone. Occupancy describes staff workload, not whether volunteers could get help. Throughput, meanwhile, counts completed work over an agreed period and helps you see whether the team is keeping pace.
Choose the measure that matches the promise. A reply isn't a completed application, and processing time isn't necessarily the full turnaround time experienced by the applicant.
Service Level Agreements and What They Must Specify
A headline target doesn't settle what a provider has promised. The written scope and measurement rules determine what the number means.
Suppose a charity buys a volunteer-management platform with an uptime commitment. The platform remains accessible, but safeguarding reviews sit unassigned. The provider may meet its agreement because it promised platform access, not completion of the charity's review process.
That distinction matters when choosing a service. Don't let a technical commitment stand in for an operational promise that nobody has made.
Write the responsibilities beside the target
An SLA should make these items explicit:
- Service scope: Identify the functions, users, locations, and workflows covered.
- Measures and targets: State what successful performance means for each covered service.
- Measurement governance: Name the measurement method, observation period, reporting party, and data owner.
- Exclusions: Document maintenance, dependency failures, customer-caused delays, and partial degradation.
- Reporting and escalation: Specify when results are shared and who handles disputes or breaches.
- Remedies: Record any agreed service credits, corrective-action reviews, or other responses.
Measurement governance is central to interpreting an SLA: a narrowly defined 99.99% commitment can be less useful than a broader, auditable 99.5% commitment connected to the user's outcome, a distinction discussed in this service-level agreement publication on Springer.
Neither percentage tells you enough by itself. You need to know which functions count, what evidence is available, and who decides whether an interruption qualifies.
Contract check: Ask whether the agreement could be met while the volunteer still cannot complete the task.
Separate provider performance from your team's work
For a screening workflow, the provider may own delivery of a usable report while your safeguarding lead owns the placement decision. Recording both responsibilities prevents the volunteer's wait from disappearing between organizations.
The same discipline applies to incoming enquiries. For teams designing an enquiry-handling process, GolfRep's resource on how to improve golf club enquiry response times provides a related context for examining response ownership.
Keep the agreement usable during a problem. A coordinator should be able to identify the responsible person, find the relevant evidence, and follow the escalation route without interpreting a vague promise of priority support.
Service Level Examples for Volunteer and Nonprofit Work
| Program or Service | Example Service Level | How It Is Measured |
|---|---|---|
| Urgent safeguarding helpline | Answer urgent inquiries within the agreed priority threshold | Contacts answered within target divided by contacts offered |
| Routine volunteer helpline | Meet a separate routine-queue answer target | Same calculation, reported separately from urgent inquiries |
| Volunteer background check | Deliver usable results within the agreed turnaround window | Measure from complete authorization to delivery of results |
| Volunteer email requests | Provide a substantive first reply by the published business-day deadline | Reply timestamp minus request timestamp |
| Shift scheduling platform | Meet agreed availability during shift hours | Count eligible downtime within shift hours and document maintenance exclusions |
| Donor database restore | Restore usable service within the agreed recovery window | Measure restoration separately from acknowledgment |
These are starting points for writing a promise, not standards every nonprofit should adopt. Each row becomes useful only when you attach an achievable target and clear ownership.
Give urgent and routine callers different treatment
An urgent safeguarding queue might target 90% of inquiries answered within 30 seconds, while the familiar 80% within 20 seconds convention isn't a universally established optimum, as explained in Digital Minds BPO's call-center benchmark guide.
The lesson isn't to copy either figure. Use your own abandonment patterns, volunteer feedback, staffing coverage, and urgency classifications to choose a threshold.
Report urgent inquiries separately. A busy routine queue shouldn't make the combined result look reassuring while people with safeguarding concerns struggle to reach the right person.
Define what completion means for each workflow
For screening, distinguish results delivered from volunteer cleared for placement. The latter may require a coordinator's review and a separate decision. Don't present the provider's turnaround as the deadline for every part of your safeguarding process.
Our screening service is used by nonprofits, churches, and youth programs nationwide, and customers pay only for complete, usable results. Those terms help define the deliverable, but they don't replace your organization's responsibility to review it.
For shift scheduling, define whether availability means volunteers can merely open the site or can successfully accept a shift. If maintenance is excluded, keep a separate operational record of volunteers affected during that maintenance.
For the donor database, treat acknowledgment and recovery as different promises. A helpful support reply doesn't mean the fundraising team can access donor records again.
A fair measure follows the task the person needs to finish, not just the action your system finds easiest to record.
Choose the example closest to a harmful delay in your program. Fit it into your wider nonprofit volunteer management process, including who acts when the result arrives and who contacts the volunteer if it doesn't.
How to Set a Service Level You Can Keep
A usable service level needs a target and a capacity model. You need to know not only what you want to promise, but who will do the work when requests arrive unevenly.
Use this process to connect the volunteer's outcome with your operating limits.
Build the target around actual capacity
Start with the outcome people care about. Write down the result the volunteer needs, such as receiving a placement decision. Avoid choosing server uptime because it's already on a dashboard.
Define the unit of work and its entry requirements. A complete application is a different workload from an unfinished form, so record what must be present before processing begins.
Collect a baseline before promising a deadline. Export request volumes, waiting times, incomplete submissions, and missed deadlines into a shared spreadsheet. Include busy periods and quieter ones so an unusually calm week doesn't determine the promise.
Separate request types. Safeguarding concerns, shift changes, and general enquiries shouldn't compete under an undifferentiated target when the consequences of delay differ.
Plan for demand above the average. A staffing study describes six or seven servers maintaining an average wait of about 3.55 minutes in studied branches handling daily volumes of roughly 665 and 924 customers, respectively, in the staffing study published by Wiley. Those aren't nonprofit staffing ratios to copy; the practical lesson is to allow spare capacity for uneven arrivals rather than staffing only to average demand.
Set an escalation trigger the team can act on. For example, flag an urgent queue when the oldest eligible request approaches its deadline, and name the backup coordinator who takes over.
Agree on a review date. Compare the promise with actual demand, staffing coverage, and volunteer feedback before tightening or relaxing it.
Document the limits without hiding the wait
Seasonal recruitment, holidays, missing authorizations, and manual review can change the workload. State business hours and dependency rules clearly, then record those delays rather than removing them from view.
A pause may be valid for measuring provider-controlled processing. The coordinator still needs the total elapsed wait to explain the situation to the volunteer.
For a supplementary explanation, the embedded video offers another way to approach service-level planning.
Measuring and Reporting Whether Service Levels Are Met
Start with a definition that another person could apply and reach the same result. Record the event being measured, clock start and stop, eligible hours, sampling method, severity classification, and treatment of pauses or customer-caused delays.
Acknowledging a ticket within 15 minutes doesn't mean restoring service within 15 minutes, and customer-facing restoration must be distinguished from internal repair, as explained in HDI's service-level management guidance.
Mean Time to Restore Service, or MTRS, concerns getting the service usable again. Mean Time to Repair, or MTTR, can describe repair of an internal component. Label the measure explicitly rather than assuming everyone interprets the abbreviation the same way.
Turn a monthly report into a decision
Consider a hypothetical helpline report that shows overall target attainment but repeated failures during evening coverage. Don't stop at the green monthly indicator.
| Report Entry | What the Coordinator Should Check |
|---|---|
| Overall target met | Did urgent and routine queues both meet their own targets? |
| Evening breaches | Did the rota match incoming demand and handling time? |
| Callers abandoned | Were people leaving before the answer threshold? |
| Service interruptions | Could callers complete the intended task? |
| Repeated delay reason | Does the team need coverage, training, or a workflow change? |
A breach count needs a defined unit. Decide whether you're counting individual late requests, failed reporting intervals, or service incidents; mixing them makes comparisons unreliable.
For a wider technical reporting perspective, Vight's guide to MSP KPIs is a related resource for teams working with managed service providers. Keep your volunteer-facing report focused on measures that lead to a decision.
Keep evidence and staffing context together
Store request timestamps, outcome, delay reason, and responsible queue alongside the report. Use volunteer time tracking to understand coverage, but don't treat hours worked as proof that requests were handled on time.
Reporting safeguard: Show excluded delays and unresolved work alongside the compliance result, not in place of it.
Before sharing the report, compare attainment with abandonment and feedback by request type. If the dashboard looks healthy while volunteers describe unanswered questions, investigate the measure before congratulating the team.
Choose One Service Level to Measure This Month
Choose the workflow where a missed deadline causes the most harm. That might be a safeguarding referral awaiting acknowledgment, a shift confirmation that determines whether an event is staffed, or screening results needed before a volunteer can begin.
Don't start with every process at once. A focused pilot lets the coordinator check whether the evidence is reliable and whether someone can act when a request approaches its deadline.
Put the promise on a working sheet
Use a shared Google Sheet or Microsoft Excel workbook, with a definition tab and a request log. Keep sensitive screening information out of a broadly shared performance sheet; use request identifiers and restrict access appropriately.
Write down:
- Measured event: The volunteer-facing result you're checking.
- Clock boundaries: The specific records that mark entry and completion.
- Target: The proposed standard you're testing.
- Escalation threshold: The condition that requires action before further harm.
- Reporting owner: The person responsible for checking and explaining the result.
Treat the initial month as a baseline, not proof that the target will always hold. Check whether holidays, recruitment peaks, or unusual cases were absent before making an external commitment.
Make the review practical
Bring the log to a team meeting and examine the delayed requests, not just the overall result. Ask which delays staff could control, which depended on another party, and which volunteers needed an earlier update.
A higher percentage isn't automatically a better promise. A clearly defined target that the team checks and consistently meets is more useful than an impressive figure nobody can explain.
Create the shared sheet this month, assign its owner, and record each eligible request through completion. At the review, decide whether to tighten, relax, or keep the target, and write down the staffing or process change needed to support that decision.
We offer volunteer background screening with a usage dashboard and reporting included in pay-as-you-go screening, plus a Compliance Roster showing who is cleared right now. Visit VolunteerBadge to explore how those tools can support a screening workflow with clearly defined deliverables and visible follow-through.
