SLA's doen beloftes aan klanten - OLA's zorgen ervoor dat je interne teams die beloftes ook echt kunnen nakomen. Met Trupeer kun je uren besparen op het schrijven van OLA's door te starten met een gratis template voor een operation level agreement, die aan te passen met je brand guidelines, en de OLA om te zetten in een video-walkthrough die elk intern team achter gedeelde service-standaarden zet.

Wat is een template voor een operation level agreement?

Een operational level agreement, of OLA, is een interne overeenkomst tussen teams binnen dezelfde organisatie die ten grondslag ligt aan een toezegging aan iemand buiten die organisatie. De servicedesk belooft het bedrijf een oplossing binnen vier uur bij grote incidenten. Die belofte geldt alleen als het netwerkteam, het applicatieteam en iedereen die in de keten zit, elk hun rol spelen binnen een bekende tijd.

De OLA is waar die interne onderdelen worden vastgelegd. Het is geen contract: niemand betaalt iemand, en de handhaving is volledig managementmatig. Dat is zowel de zwakte als de reden dat het eerlijk kan zijn op manieren die een contract niet kan.

Een template voor een operational level agreement is de herbruikbare structuur: de partijen, de gedekte services, de toezeggingen, de maatregelen en de afspraken voor evaluatie. Templates zijn eenvoudig te vinden. De meeste laten je een OLA schrijven die volledig wordt nagekomen en toch faalt. Dat is waar de rest van deze pagina over gaat.

OLA vs SLA: waar committeert elk document zich echt aan?

Er zijn drie documenten binnen deze familie en ze door elkaar halen veroorzaakt echte problemen.

Een service level agreement is de toezegging aan de klant of het bedrijf. Het wordt geschreven in de termen van de klant, meestal end-to-end, en het is wat wordt gerapporteerd aan mensen buiten de leveringsketen.

Een operational level agreement is intern, tussen teams die allebei onder dezelfde organisatie vallen. Het bestaat uitsluitend om de SLA haalbaar te maken en mag nooit een toezegging bevatten die de SLA niet nodig heeft.

Een underpinning contract is de commerciële overeenkomst met een derde partij, een leverancier of een uitbesteed provider, die dezelfde keten ondersteunt. Het heeft juridische kracht, wat de OLA niet heeft, en het heeft meestal de minste flexibiliteit van de drie. Daarom moet het worden afgesproken vóór de SLA en niet erna.

Het praktische gevolg is een volgorderegel. Spreek eerst de underpinning contracts af, vervolgens de SLA op basis van wat die contracts toestaan, en daarna de OLA's die de rest invullen. Organisaties die het in de omgekeerde volgorde doen, beloven het bedrijf routinematig iets dat geen enkele leverancier heeft afgesproken te leveren.

Zo pas je deze template aan in Trupeer

Stap 1: Open de sectie Templates

Ga in het hoofdmenu naar de sectie Templates.

Stap 2: Selecteer en open een template

Klik op een willekeurige template waarmee je wilt werken om deze te openen.

Stap 3: Breid de templateweergave uit

Indien nodig, breid de templateweergave uit om de volledige indeling en details duidelijk te zien.

Stap 4: Bewerk de template

Klik op Bewerken om te beginnen met het aanpassen van de geselecteerde template.

In de editor kun je:

• Nieuwe secties toevoegen

• Opmaakregels definiëren of bijwerken

• Een logo toevoegen en de positie en gerelateerde instellingen aanpassen

Stap 5: Sla je aangepaste template op

Nadat je alle noodzakelijke wijzigingen hebt doorgevoerd, klik je op Opslaan om de bijgewerkte template als je eigen template op te slaan.

Stap 6: Bekijk en verfijn de template

Als je wilt zien hoe je aangepaste template eruitziet, open je de Voorvertoning.

Vanaf het preview-scherm kun je indien nodig direct doorgaan met het maken van aanpassingen, zodat de template precies verschijnt zoals jij wilt.

Met een template voor een operational level agreement kun je:

• Uren besparen op schrijven: Sla de lege pagina over met een structuur die is gebouwd voor OLA's.

• Interne teams op één lijn brengen: Ingebouwde velden zorgen ervoor dat elk team weet wat zijn verantwoordelijkheid is.

• In lijn blijven met je merk: Pas je logo, fonts en kleuren toe met de brand kit van Trupeer.

• Klantspecifieke SLA's beschermen: Sterke OLA's voorkomen dat interne overdrachten externe beloftes breken.

• Standaardiseren over services: Gebruik dezelfde OLA-template voor elke interne overeenkomst.

• Werken met globale teams: Vertaal OLA's in 65+ talen met één klik.

Waarom elk team zijn OLA haalt en de SLA toch wordt overschreden

Dit is het meest voorkomende patroon in service management en het lijkt op een contradictie.

Elk team rapporteert groen. Het netwerk reageert binnen zijn uur. Het applicatieteam lost op binnen zijn twee. De servicedesk triageert binnen dertig minuten. Het maandelijkse OLA-compliance rapport is prettig om te lezen. En toch wordt de klant-SLA bij een derde van de grote incidenten overschreden.

De verklaring is dat OLA's de tijd binnen teams meten, terwijl de SLA de tijd end-to-end meet. Het verschil tussen die twee getallen is transit: het ticket dat in een wachtrij staat na een herverdeling, wacht om opgepakt te worden, of teruggestuurd wordt voor extra informatie.

Die tijd is van niemand. Het staat niet in iemands OLA, wordt nergens gerapporteerd en is vaak groter dan alle werktijd samen.

Dat betekent dat het falen structureel is en niet een prestatieprobleem. Extra druk op teams om hun bestaande cijfers te halen helpt niet, omdat ze die al halen.

De OLA stuurt de overdracht aan, niet het werk

De herformulering die dit oplost is klein en verandert waar het document voor bedoeld is.

Een OLA die op de gebruikelijke manier is geschreven, committeert een team aan hoe lang het eigen werk duurt. Dat is het deel dat het team controleert, dus dat is het deel waar ze bereid zijn voor te tekenen. En het is het minst nuttige om af te spreken, omdat het nooit de variabele was.

Een OLA die goed is geschreven, committeert teams aan de interface tussen hen. Wat er in een ticket moet staan voordat het wordt overgedragen. Hoe lang het ontvangende team het moet oppakken. Wat er gebeurt als het ticket incompleet is. Wie het ticket beheert tijdens de tussenruimte.

Zodra de overdracht het onderwerp wordt, worden de twee ontbrekende velden duidelijk. Entry criteria: wat waar moet zijn voordat de klok van het ontvangende team start. En een expliciete toewijzing van de transit-tijd zelf, zodat de kloof tussen teams iemands nummer is en niet dat van niemand.

Al het andere in een OLA-template is administratie. Deze twee zijn het document.

Entry criteria: wat waar moet zijn voordat de klok start

Het meest destructieve gedrag in een keten met meerdere teams is terugsturen: een ticket komt binnen zonder genoeg informatie, het ontvangende team stuurt het terug en hun klok wordt opnieuw gestart.

Terugsturen is volledig rationeel vanuit het perspectief van het ontvangende team. Ze kunnen aan het ticket niet werken en hun compliance wordt gemeten op hun eigen oplostijd, dus door het terug te sturen beschermen ze beide. Het is ook waar een groot deel van de verstreken tijd naartoe gaat, en het is onzichtbaar in elk rapport dat teams afzonderlijk meet.

Entry criteria lossen dit op door de verplichting stroomopwaarts te verplaatsen. Elke OLA-regel vermeldt de specifieke velden die moeten zijn ingevuld voordat dat team het werk accepteert. Voor een overdracht door het netwerkteam kan dat bijvoorbeeld de apparaatnaam zijn, de sitecode, de exacte fouttekst, de tijd waarop het voor het eerst is waargenomen en of andere gebruikers worden beïnvloed. Voor een overdracht door het applicatieteam kan dat de gebruiker zijn, de transactiereferentie, de stappen om te reproduceren en een screenshot.

Daarna verandert de toezegging van het verzendende team van bewoording. Niet "triage binnen dertig minuten" maar "geef een ticket door dat voldoet aan de entry criteria binnen dertig minuten". Dezelfde klok, andere verplichting. En de incentive ligt nu bij het team dat de informatie daadwerkelijk kan verzamelen.

Het ontvangende team houdt het recht om af te wijzen, en dat recht moet beperkt zijn: afwijzing is alleen geldig wanneer een genoemde entry criterion echt ontbreekt, en elke afwijzing wordt vastgelegd met de reden. Logging maakt van terugsturen een onzichtbare gewoonte een getal dat iemand moet uitleggen.

Gratis template voor een operational level agreement: de structuur om te kopiëren

Kopieer vanaf hier. Velden met een asterisk zijn de velden die standaard templates weglaten.

Header. OLA-referentie en versie. Partijen: de twee teams bij naam. De SLA of service die dit ondersteunt. Ingangsdatum, revisiedatum en de benoemde eigenaar aan elke kant.

Scope. Welke services, systemen of type aanvragen dit dekt, en expliciet wat het niet dekt.

Service-uren. Dekking voor elke partij, inclusief afspraken buiten kantooruren en hoe die verschillen. Niet-overeenkomende uren tussen twee teams in dezelfde keten is een veelvoorkomende en stilletjes fatale kloof.

Commitments-tabel. Eén rij per type aanvraag of prioriteit, met: de trigger, de entry criteria, responstijd, oplostijd of handback-tijd, de toegewezen transit-tijd, en het escalatiepunt.

Escalatie. Wie wordt gecontacteerd in elke fase, via welke route, en na hoe lang. Neem het pad buiten kantooruren op.

Dependencies. Wat dit team nodig heeft van anderen, inclusief eventuele underpinning contract met een derde partij, met eigen tijden erbij zodat de rekenkundige controle kan worden uitgevoerd.

Metingen. Wat wordt gemeten, uit welk systeem, door wie en hoe vaak het wordt gerapporteerd. Neem bounce rate op naast respons- en oplostijd, omdat dit de metric is die laat zien of entry criteria werken.

Uitzonderingen. Afgesproken omstandigheden waarin de toezeggingen niet gelden, zoals tijdens een gedeclareerd groot incident of een change freeze.

Review. Datums en wat een review buiten de cyclus triggert.

Kopieer tot hier. Houd het bij twee of drie pagina's. Een OLA die lang genoeg is om twee keer te moeten lezen, wordt niet geraadpleegd tijdens een incident. En juist tijdens een incident is dat belangrijk.

Zo controleer je of de OLA's echt optellen tot de SLA

Voordat je iets ondertekent, maak je de som. Dat kost vijftien minuten en wordt bijna altijd overgeslagen, omdat de OLA's één voor één worden onderhandeld met verschillende teams op verschillende dagen.

Twee regels maken dit bruikbaar. Transit-tijd moet als eigen regel verschijnen, omdat dat het hele punt is. En elke keten heeft headroom nodig, omdat een keten die precies optelt tot de SLA overschrijdt zodra er iets, hoe klein ook, misgaat. Tien tot vijftien procent is een redelijke marge.

Als de som de SLA overschrijdt, heb je drie eerlijke opties: heronderhandel de SLA, verlaag de tijd van een team met iets dat het mogelijk maakt, of verwijder een overdracht. Wat je niet kunt doen, is OLA's ondertekenen die een overschrijding garanderen en vervolgens performance daarop managen. Dat is de positie waarin een verrassend aantal servicedesks zich bevindt.

De retailer wiens transit-tijd langer was dan het werk

Rendlesham Group runt meerdere retailmerken met ongeveer zesduizend medewerkers en een interne IT-servicedesk die winkels en het hoofdkantoor ondersteunt.

De P2-incident-SLA naar het bedrijf was vier uur tot oplossing. Het breachpercentage op P2 lag al twee jaar rond de achtendertig procent. De compliance van elke team's OLA werd maandelijks gerapporteerd en elk team was groen.

Iemand heeft uiteindelijk elke statuswijziging getimestamp op honderd en twintig P2-incidenten die waren overschreden.

De mediaan van de totale verstreken tijd was zes uur eenenvijftig minuten. Daarvan was drie uur twaalf minuten tijd binnen een team dat actief aan het ticket werkte. Drie uur negenendertig minuten was transit: in een wachtrij na herverdeling, wachten om opgepakt te worden, of teruggestuurd.

Meer dan de helft van de verstreken tijd bij een overschreden incident was van niemand en werd nergens gerapporteerd.

De grootste individuele bijdrage was terugsturen. Van de honderd en twintig tickets waren er eenenveertig minstens één keer teruggestuurd door een ontvangend team vanwege onvoldoende informatie, en elke bounce voegde een mediaan van één uur twintig minuten toe én zette de klok van dat team opnieuw. De twee meest voorkomende redenen waren geen fouttekst of screenshot bijgevoegd, en geen bevestiging van welke winkel het incident betrof.

De wijzigingen waren beperkt. Entry criteria werden in elke OLA-regel geschreven. De toezegging van de servicedesk werd herschreven van triage binnen dertig minuten naar het doorgeven van een ticket dat voldoet aan de entry criteria binnen dertig minuten. Er werd vijftien minuten transit toegewezen per overdracht en dit werd meegeteld tegen het ontvangende team zodra de entry criteria waren gehaald. En elke bounce werd vastgelegd met een reden.

In de daaropvolgende twee kwartalen daalde de bounce rate van vierendertig procent van de P2's naar negen. De mediaan van de transit-tijd daalde van drie uur negenendertig minuten naar één uur zes. Het P2-breachpercentage daalde van achtendertig procent naar elf.

De interne oplostijd van geen enkel team veranderde materieel. Niemand werkte sneller. De tijd die eerst van niemand was, werd simpelweg aan iemand gegeven.

Zo stel je stap voor stap een operational level agreement op

Begin bij de SLA, niet bij een template. Schrijf op wat de klant is beloofd, end-to-end, met de definitie van de klok.

Breng de keten in kaart. Elk team dat een aanvraag van dat type aanraakt, in volgorde, inclusief eventuele derde partij. Teken de overdrachten als eigen stappen in plaats van als pijlen.

Stel bij elke overdracht één vraag aan het ontvangende team: wat heb je in het ticket nodig om te starten zonder het terug naar ons te sturen. Het antwoord, opgeschreven, zijn je entry criteria. Teams beantwoorden dit doorgaans snel en precies, en de meesten zijn nog nooit gevraagd.

Spreek nu tijden af, werkend binnen de rekenkundige logica hierboven in plaats van per team. Het als één gesprek doen met iedereen erbij kost een uur en voorkomt het somprobleem volledig.

Wijs transit expliciet toe en bepaal wie het beheert. Vijftien minuten per overdracht is een goed startpunt en moet worden meegeteld tegen het ontvangende team.

Spreek de metingen af, inclusief bounce rate, en waar die vandaan komt. Als je tooling het niet kan produceren, is dat iets om te weten voordat je tekent, in plaats van bij de eerste review.

Laat het vervolgens een kwartaal draaien voordat je het formeel vastlegt. De eerste versies zijn meestal op één of twee plekken verkeerd en het is makkelijker om ze te corrigeren voordat er wordt ondertekend.

Veelvoorkomende OLA-fouten en wat elke fout kost

Teams meten en niet de keten. Iedereen is groen en de SLA wordt overschreden. De meest voorkomende fout en het onderwerp van deze pagina.

Geen entry criteria. Terugsturen wordt de rationele verdediging van het ontvangende team en de verstreken tijd groeit onzichtbaar.

Tijden die niet optellen. De OLA-set garandeert een overschrijding en niemand heeft het ooit opgeteld.

Niet-overeenkomende service-uren. Eén team dekt tot zes, het volgende tot vijf. Alles wat na vijf binnenkomt, ligt 's nachts stil. Dat zie je niet in rapporten, omdat beide teams binnen hun eigen uren zitten.

SLA-tekst kopiëren naar een OLA. Penalties, credits en juridische bewoording horen hier niet thuis. Door ze over te nemen gaan teams defensief onderhandelen in plaats van eerlijk.

Een OLA schrijven met een derde partij. Als er geld van hand tot hand gaat, is het een underpinning contract en heb je procurement en juridische betrokkenheid nodig, niet een template. Onze IT procurement policy template dekt het goedkeuringspad.

Ondertekenen en archiveren. Een OLA die niemand beoordeelt, beschrijft een serviceketen die binnen ongeveer een jaar niet meer bestaat.

Zo beheer en evalueer je OLAs zodra ze bestaan

Rapporteer de keten, niet de onderdelen. Eén getal is belangrijk: end-to-end performance ten opzichte van de SLA. En de OLA-metrics bestaan om dat uit te leggen, niet om los te staan.

Evalueer elk kwartaal, met alle partijen samen in dezelfde ruimte. Bilaterale reviews reproduceren het oorspronkelijke probleem, omdat de gaten zich bevinden tussen de partijen die nooit in hetzelfde gesprek zitten.

Let op drie dingen. Bounce rate per overdracht: dat vertelt je waar entry criteria moeten worden verbeterd. Transit-tijd per overdracht: dat vertelt je waar wachtrijen ontstaan. En het aandeel incidenten dat een pad volgde dat de OLA niet beschrijft: dat vertelt je dat het document is afgedreven van de realiteit.

Start een review buiten de cyclus wanneer een team zich reorganiseert, wanneer een systeem tussen teams verhuist, wanneer een nieuwe derde partij de keten binnenkomt, of wanneer de SLA verandert. Alle vier gebeuren vaker dan de jaarlijkse reviewcyclus veronderstelt.

OLA, SLA of underpinning contract: wat heb je nodig?

Als de toezegging aan iemand buiten je leveringsorganisatie is, of dat nu een externe klant is of een interne business unit die wordt bediend, dan is het een SLA.

Als het tussen twee teams binnen dezelfde organisatie is, zonder dat er geld van hand tot hand gaat, dan is het een OLA.

Als het met een leverancier is onder een commerciële regeling, dan is het een underpinning contract en heb je juridische en procurement-ondersteuning nodig, niet deze template.

De lastige case is het shared service centre of een intern team met een chargeback-model, dat tussen een OLA en een SLA in zit. Het praktische antwoord is om het als een OLA te schrijven en elke taal over penalties te schrappen, omdat interne penalty-regimes betrouwbaar defensief gedrag en slechtere service opleveren.

Voor de definities en antwoordformuleringen die gericht zijn op de klant en bovenop dit alles liggen, dekken onze help desk response template en ticket and resolution template de laag die de eindgebruiker daadwerkelijk ziet.

Kan ik een OLA-template in Word of Excel krijgen?

Word voor de overeenkomst, omdat de scope, uitzonderingen en review-secties uitlopende tekst zijn en het document wordt rondgestuurd voor goedkeuring en ondertekening.

Excel voor twee onderdelen specifiek. De commitments-tabel, waar je de entry criteria, tijden en transit-toewijzing in kolommen wilt die je kunt sorteren en controleren. En het rekenblad, waar elke keten optelt tegen zijn SLA en alles markeert zonder headroom. Dat tweede blad is degene die je eerst wilt bouwen, omdat het vaak verandert wat je van plan was af te spreken.

PDF voor de ondertekende versie, geëxporteerd vanuit de bron. Houd de werkversie bewerkbaar, omdat de entry criteria na het eerste kwartaal van echte bounces moeten worden aangepast.

Zo houd je de OLA en de realiteit in sync

Een OLA beschrijft een keten van werk die constant verandert. Teams reorganiseren, systemen verhuizen, tools veranderen en het document is het laatste dat iemand bijwerkt.

Het onderdeel dat het snelst veroudert zijn de entry criteria, omdat ze beschrijven wat een ticket moet bevatten. En wat een ticket moet bevatten hangt af van hoe de huidige tooling en het huidige proces in de praktijk werken.

Trupeer AI helpt door de onderliggende procedures goedkoop te houden om actueel te blijven. Leg het triage- of overdrachtsproces één keer vast en je krijgt een geschreven procedure met de stappen en schermen erin, die de servicedesk kan volgen en die duidelijk laat zien welke informatie wordt verzameld. Als de tooling verandert, neem het opnieuw op in plaats van het opnieuw te schrijven.

Leg het vast. Maak het merkbaar. Vertaal het. Trupeer het.

De SOP creator dekt de procedures waarvan de OLA afhankelijk is, en onze IT SOP template dekt hoe je bepaalt welke ervan de moeite waard zijn om te onderhouden. Documentation houdt de overeenkomsten en procedures bij elkaar, en setup-instructies staan in de document template setup guide.

Veelgestelde vragen

Is er een gratis template voor een operational level agreement in Word?

De structuur hierboven plakt direct in Word of Google Docs, inclusief de entry criteria en transit-toewijzingsvelden die standaard templates weglaten. Er is geen afgeschermde download en geen formulier. Houd de commitments-tabel in een spreadsheet en verwijs ernaar, omdat dat onderdeel moet worden gesorteerd en opgeteld.

Is er een gratis template voor een operational level agreement in PDF?

Exporteer de ondertekende versie naar PDF zodra de partijen het hebben afgesproken en houd de werkversie bewerkbaar. Entry criteria moeten bijna altijd na het eerste kwartaal worden aangepast, zodra je kunt zien waarvoor tickets in de praktijk worden teruggestuurd.

Is er een gratis template voor een operational level agreement in Excel?

Excel is de juiste plek voor de commitments-tabel en voor de rekenkundige controle. Eén blad met één rij per overdracht en een lopend totaal tegen de SLA, met markering van elke keten met minder dan tien procent headroom. Als je dat blad bouwt voordat je onderhandelt, verandert dat vaak wat er wordt onderhandeld.

Waar kan ik een voorbeeld van een operational level agreement PDF vinden?

Verschillende ITSM-leveranciers en overheidsinstanties publiceren OLA- en SLA-templates als documenten, en ze zijn redelijk qua structuur. Lees ze voor de secties in plaats van de inhoud, omdat de commitments in elk gepubliceerd voorbeeld de keten van iemand anders zijn en de tijden betekenisloos zijn buiten de SLA waarvoor ze zijn bedoeld.

Wie ondertekent een operational level agreement?

De benoemde eigenaar aan elke kant, die de manager moet zijn die verantwoordelijk is voor de levering van dat team, en niet een functie binnen service management. Een OLA die alleen door service management is ondertekend, is een wens, omdat de persoon die het moet mogelijk maken niet in de kamer zat.

Hoeveel OLA's heeft een servicedesk nodig?

Minder dan de meeste teams verwachten. Eén per team-paar dat regelmatig werk uitwisselt, met alle type aanvragen in één commitments-tabel, in plaats van één per service. Na ongeveer een dozijn wordt onderhoud de beperkende factor en raken de documenten sneller verouderd dan dat ze worden beoordeeld.

Moet een operational level agreement penalties bevatten?

Nee. Er is geen juridische relatie om af te dwingen en interne penalty-regimes produceren betrouwbaar defensief gedrag: teams wijzen werk af, discussiëren over wanneer de klok start en optimaliseren voor hun eigen getal in plaats van voor het resultaat. Rapporteer de keten end-to-end in plaats daarvan, zodat het gedeelde gevolg zichtbaar wordt zonder dat iemand een boete krijgt.

Hoe vaak moeten OLA's worden beoordeeld?

Elk kwartaal met alle partijen aanwezig, plus een review buiten de cyclus wanneer een team zich reorganiseert, wanneer een systeem tussen teams verhuist, wanneer een derde partij de keten binnenkomt, of wanneer de onderliggende SLA verandert. De kwartaalcadans vangt drift op en de triggers vangen de veranderingen op die het document 's nachts onjuist maken.