SLA voor softwarebeheer: responstijd, oplostijd en prioriteiten

1. Wat is een SLA precies?

Een Service Level Agreement is de afspraak over wat je van je beheerpartij mag verwachten als er iets misgaat, en wat je daarvoor betaalt. Het is geen garantie dat er nooit iets kapotgaat. Het is een garantie over hoe snel en hoe goed er wordt gereageerd als dat wel gebeurt.

Een goede SLA is kort en concreet. Hij beantwoordt vier vragen: wanneer ben je bereikbaar, hoe snel reageer je, hoe snel los je op, en wat valt er wel en niet onder. Alles wat daar niet over gaat, hoort in de algemene voorwaarden of in het beheercontract.

2. Responstijd is niet hetzelfde als oplostijd

Dit is het punt waar de meeste teleurstellingen ontstaan. Responstijd is de tijd tussen je melding en het moment dat een specialist ernaar kijkt en reageert. Oplostijd is de tijd tot het probleem verholpen is of er een werkbare tijdelijke oplossing staat.

Een SLA die alleen een responstijd noemt, belooft dus vooral aandacht, geen resultaat. Vraag altijd naar beide. En let op de kleine lettertjes: gaat het om klokuren of om werkuren? "Binnen 4 uur" op vrijdagmiddag half vijf kan in werkuren dinsdagochtend betekenen.

3. Prioriteiten: niet elke melding is een brand

Een SLA werkt met prioriteitsniveaus. Hoe hoger de impact, hoe strakker de tijden. Een gangbare indeling ziet er zo uit:

Wie bepaalt de prioriteit? In de praktijk stelt de klant hem voor bij de melding en bevestigt de beheerpartij hem na een eerste beoordeling. Leg vast dat een P1 altijd telefonisch gemeld mag worden, ook buiten kantoortijd als dat is afgesproken.

4. Wat valt eronder, en wat niet?

Beheer is niet hetzelfde als onbeperkt ontwikkelen. Een heldere SLA maakt onderscheid tussen:

• Correctief onderhoud — fouten herstellen in wat is opgeleverd. Dit valt onder het beheerpakket.
• Preventief onderhoud — updates van frameworks, beveiligingspatches, certificaten, back-ups en monitoring. Meestal inbegrepen, soms met een vast aantal uren.
• Adaptief onderhoud — aanpassingen omdat een extern systeem verandert, bijvoorbeeld een nieuwe API-versie van je boekhoudpakket. Vaak deels inbegrepen.
• Nieuwe functionaliteit — dit is ontwikkelwerk en valt buiten de SLA. Het gaat via een aparte offerte of een strippenkaart.

Vraag ook naar de uitsluitingen: storingen door wijzigingen die je zelf hebt doorgevoerd, problemen bij een hostingpartij die niet onder beheer valt, of software die buiten de scope van de oplevering staat.

5. Welk niveau heb je nodig?

De juiste SLA hangt af van wat een uur stilstand je kost. Een intern planningstool dat een dag uit de lucht kan, heeft andere eisen dan een webshop die op zaterdagavond de meeste omzet draait. Een eenvoudige vuistregel:

• Basis — kantoortijden, respons binnen een werkdag. Voor interne tools en websites zonder directe omzet.
• Plus — verlengde bereikbaarheid, respons binnen enkele uren, proactieve monitoring. Voor webshops en bedrijfskritische koppelingen.
• Premium — 24/7 bereikbaar voor P1, gegarandeerde oplostijden, vaste specialist. Voor platformen waar stilstand direct geld of reputatie kost.

Twijfel je tussen twee niveaus? Reken uit wat een dag storing kost aan omzet, handwerk en klantvertrouwen. Vaak is het verschil in maandprijs kleiner dan één zo'n dag.

6. Vijf vragen om te stellen voordat je tekent

• Zijn de tijden in klokuren of werkuren, en wat zijn jullie werkuren?
• Hoe meld ik een storing, en hoe zie ik de status? Een klantportaal met tickets voorkomt dat meldingen zoekraken.
• Wat gebeurt er als jullie de afgesproken tijd niet halen?
• Krijg ik periodiek een rapportage van meldingen, doorlooptijden en uitgevoerd onderhoud?
• Wat is inbegrepen aan preventief onderhoud, en hoeveel uur zit er in het pakket?