Internal Service Level Agreements Between Departments: How to Set Turnaround Times and Accountability for Delays

How does an internal agreement differ from a supplier contract?

An internal service level agreement is a written commitment between a department that provides a service, such as IT, procurement or HR, and a department that uses it. It does not need legal drafting, but it does need the same precision in defining the service and how it is measured.

Google’s site reliability engineering literature distinguishes three levels: the indicator (SLI), a carefully defined quantitative measure of some aspect of the service; the objective (SLO), the target value for that indicator; and the agreement (SLA), which attaches consequences to meeting or missing the objectives. The simple test is to ask what happens if the objective is missed. If nothing happens, you have an objective, not an agreement. ^[1]

In external contracts the consequences are usually financial. Inside an organisation the consequence is normally an agreed action: a correction plan, escalation or a capacity review. The scope of ISO/IEC 20000-1 covers services provided to internal and external customers alike, so the same logic applies to a service between two departments. ^[4]

What clauses go into the agreement?

Define a valid request before setting any number. Most disputes between departments are not about how fast the work was done but about when the request was actually ready to be worked on.

Express the target as the share of requests it covers, not only as an average time. An average can hide requests that were badly delayed, whereas the distribution, such as the 90th percentile or the share of requests completed within the time limit, reveals what people actually experience. ^[1]

How do you define when the clock starts and stops?

Record three separate moments: when the request was received, when its information was complete, and when the service was delivered. Then agree the working hours, holidays, legitimate reasons for stopping the clock, and who is entitled to record a stop and its reason.

Google’s guidance recommends that an objective states how it is measured and over what period it is aggregated, because the aggregation method can change how the same number reads. ^[1] In an administrative setting this means deciding, for example, whether the target applies to the whole month’s requests or to each week separately.

Reasons departments commonly agree for stopping the clock include waiting for information or a document from the requester, waiting for a third-party approval required by the procedure, and a delay requested by the customer. A busy delivering team or an absent team member is not a reason to stop the clock; it is a capacity issue for management to address.

Do not stop at processing time. Show total waiting time from submission alongside it, even if part of that time is excluded from the delivering department’s commitment. A new employee waiting for an account does not care which department is responsible for the delay.

How do you choose the numerical target?

Do not simply adopt current performance as the target; that can lock the team into permanent heroic effort or cement a weak level that needs improving. ^[1] Start by asking the customer at what point the delay actually stops their work, then compare that with the delivering team’s capacity.

The same source makes two useful suggestions here: keep to a small number of representative indicators, and set the internal target slightly tighter than the published commitment, so the team sees problems before the customer feels them. ^[1]

The same service can have more than one target, such as an urgent and a standard route, provided the rule for urgency is written down; otherwise every request becomes urgent.

A useful target combines a percentage with a ceiling. Purely as an illustration: “90% of complete requests are delivered within two working days, and no request exceeds five working days without escalation to the named role.” The percentage measures normal performance; the ceiling protects the customer whose request has been forgotten at the bottom of the queue.

Hypothetical example: a new employee’s account

Hypothetical example: in a Gulf organisation, HR asks IT to set up an account for every new employee. One request was logged on a Thursday without the start date and stayed pending until it was completed on Sunday.

IT recorded arrival and completion times separately, which showed that processing time was within target and that most of the wait happened before the request was complete. Analysis of several months of requests showed the same field missing again and again. The organisation trialled making it mandatory on the form and tracked the effect on total time, not just processing time.

Who settles disputes over delays?

Write the escalation path by job title, not by person: who is notified first, how quickly they respond, and who decides if the dispute over clock time or an exclusion continues. Google’s workbook recommends that the policy behind objectives sets out the actions required when the limit is breached and an escalation path for disagreements about the calculation or the appropriateness of those actions. ^[2]

Google’s workbook expects all key stakeholders to approve the policy. ^[2] For an internal agreement that means three parties: the customer, who accepts the target as good enough; the delivering team, which confirms it can meet it without constant overload; and whoever has the authority to settle disputes. The UK government’s contract management principles state that governance should be proportionate to the size and risk of the commitment, be suitably empowered, and that indicators and incentives should be challenged regularly, with a mechanism to change them over the life of the arrangement. ^[3]

What mistakes make internal agreements fail?

A handful of mistakes recur in agreements between departments, and knowing them in advance saves months of argument:

• A target with no definition of a valid request. The delivering department commits to a number it only half controls, and every incomplete request becomes a dispute.
• Measuring only from the provider’s system. Some problems are felt by the customer without showing up in the service’s internal indicators, so measuring closer to the user’s experience is preferable. ^[1] In an administrative setting, that may mean surveying a sample of customers regularly alongside the system figures.
• Too many indicators. Too many distract from what matters, while too few leave important aspects unexamined. ^[1] Three or four indicators are usually enough for one internal service.
• Treating the agreement as a blame tool. If every delay becomes an occasion for accusations, departments will stop recording exceptions honestly and the measurement loses its value.
• An agreement with no review date. Request volumes, systems and teams change, and the target becomes unrealistic or meaningless without anyone noticing.

A safe start is to trial the agreement on one high-volume service for a few months, then roll it out once definitions and exclusions have been corrected.

What should management review each month?

Look at late requests by waiting stage and reason for return, not only at the compliance rate. Check each department’s ability to meet its commitment during peak periods and holidays. If request volumes change markedly, reassess capacity and the target before fixing a new commitment.

Google’s workbook suggests frequent reviews at first, around monthly, then moving to quarterly or less once measurement settles, while recording who drafted the agreement, who approved it, when it is next reviewed and the basis for each number. ^[2]

Conclusion

An internal service level agreement works when both departments read the same number in the same way. Define a valid request, separate the three moments in time, choose a target that customer and provider both accept, and write down who settles disputes before one arises.