Service Levels for Internal Processes: Setting and Tracking Turnaround Times

How to set realistic turnaround commitments for internal processes, measure them automatically, and actually do something when they slip.

Someone in sales asks how long a new supplier setup takes. Finance says “a few days”. The supplier gets set up in eleven. Nobody lied, exactly; nobody had ever measured it, and “a few days” was the number that felt right on a good week.

Internal processes rarely come with promises attached. That is fine until the people waiting on them start planning around guesses. A service level gives everyone a number they can rely on, and a tool can tell you whether you are keeping it.

What a service level actually is

A service level is a commitment about how quickly a type of work will be handled. In plain terms: “We will do X within Y, for Z percent of requests.”

All three parts matter. “We process purchase orders quickly” is a sentiment. “We approve purchase orders under a set amount within two working days, nine times out of ten” is something you can check.

The percentage is the part teams usually skip, and it is the part that keeps the commitment honest. Promising 100% means the first awkward request breaks your record. Promising 90% admits that some requests are messy and gives you room to handle them properly.

You will also see two related terms:

Response time: how long until someone acknowledges the request and picks it up.
Resolution time: how long until the work is finished.

Many internal teams only need one. If your requesters mainly worry about requests vanishing into a void, start with response time. If they worry about deadlines, start with resolution.

Setting a number you can keep

The worst way to set a service level is in a meeting where someone senior picks a number. The best way is to look at what you already do.

If your spreadsheet has a date requested and a date completed, you have a baseline. Say you pull the last three months of IT access requests and find that most close within three working days, a handful take a week, and two took a month because they needed approval from a director on leave. A sensible first commitment is three working days for 85% of requests. That is roughly what you already achieve, and it is now written down.

A few rules make the number usable:

Use working time, not calendar time. A request that lands at 5pm on Friday should not be two days late by Monday morning. Decide your working days and hours and have the tool count against them.
Split by type when the work genuinely differs. A password reset and a new laptop are both “IT requests”, but one takes minutes and the other involves a supplier. One service level for both will be meaningless for each.
Pause the clock when you are waiting on the requester. If you have asked for missing information, the time spent waiting is not your delay. Most tools can track time in a “waiting on requester” state separately.

That last point depends on having real states rather than a free-text status, which is covered in Replacing the “Status” Column: Designing Real Workflows with States and Transitions.

Measuring it without anyone typing dates

In a spreadsheet, turnaround times rely on someone remembering to fill in a completion date. They forget, or they fill it in a week later with today’s date, and your measurements become fiction.

In a proper tool, the timestamps come for free. When a record is created, the tool records the time. When it moves to “Done”, the tool records that too. Your service level calculation becomes a simple difference between two dates the system captured itself.

Set up three things:

A due-by field calculated on creation. Requested time plus the service level for that request type, in working hours. People can see the deadline on every record.
A breach flag. A calculated field that turns true when the current time passes the due-by and the request is not finished.
A summary view. Percentage of requests met within target, by type, for the last 30 days.

If you want more on building that summary view so nobody exports it to make a chart, see Reporting Without Exports: Getting Dashboards from Your New System.

Acting on breaches before they happen

Measuring breaches after the fact is useful for monthly reviews. It does nothing for the requester whose order is late today.

The more valuable signal is “at risk”: a request that has used, say, 75% of its allowed time and is still not started. That is the moment when someone can still act. A sorted list of at-risk requests, oldest first, is often all a team lead needs to check twice a day.

Be careful with alerts here. One message to the owner when a request goes at risk is helpful. A message to the whole team every hour until it is resolved is noise that people will mute within a week. Automations That Actually Save Time (And the Ones That Just Create Noise) has more on that balance.

When a breach does happen, decide in advance what follows. For most internal work, the answer is modest: the request moves to the top of the queue and the team lead gets told. You do not need an escalation ladder that ends at the chief executive.

Reviewing and adjusting

Service levels are not carved in stone. Check them once a quarter with a short set of questions:

Question	What it tells you
Are we hitting the target comfortably?	The number may be too generous; tighten it if requesters would benefit.
Are we missing it consistently?	Either capacity is short or the target was wishful.
Are breaches clustered in one request type?	That type may need its own process or its own target.
Are requests sitting in “waiting on requester” for days?	Your intake form is missing questions.

That last row is worth chasing. Long waits for information usually mean the form at the front door is not asking for what the work needs.

Share the results with the people who depend on you. A short monthly note saying “we met our two-day target on 91% of requests” builds more trust than any number of reassurances that the team is busy.

Where to start this week

Pick one internal process people regularly ask “how long will this take?” about.
Pull three months of request and completion dates and work out what you actually achieve today.
Write one commitment in the “X within Y for Z%” form, using working time, and share it with requesters.
Add a due-by field and an at-risk view to the tool so the number is tracked without anyone typing a date.