Verwachting versus werkelijkheid

Wanneer er een website of applicatie uitvalt, verwachten klanten vaak dat er direct iemand aan de slag gaat. Zeker wanneer ze betalen voor Managed Hosting of een SLA hebben afgesloten. En meestal gebeurt dat op een ongunstig tijdstip. Wat is het telefoonnummer eigenlijk? Is er een spoeddienst? Waar heb ik de SLA ook alweer opgeslagen? Daar ontstaat vaak de eerste teleurstelling. Een SLA is namelijk geen garantie dat een probleem binnen een uur is opgelost. Sterker nog: in veel gevallen is het niet eens een garantie dat je binnen een uur reactie hebt. Vaak staat er alleen maar dat de partner binnen een bepaalde tijd reageert en dan ontvang je meestal alleen: ‘We hebben je melding ontvangen en gaan het probleem onderzoeken’. Dat is geen oplossing.

Responstijd is geen oplostijd

Een grote misvatting rondom SLA’s dus. Een responstijd zegt alleen iets over wanneer de leverancier contact opneemt. De oplostijd is afhankelijk van de aard van het probleem. Sommige storingen zijn binnen 10 minuten opgelost. Andere vereisen veel meer werk, zoals hardwarevervanging of overleg met derde partijen en kunnen uren duren. Toch worden de begrippen responstijd en oplostijd vaak door elkaar gehaald.

Zo sterk als de zwakste schakel

Voor agencies is dit nog belangrijker. Veel bureaus spreken met hun klanten af dat incidenten snel worden opgepakt en dat is logisch, want je wilt complete en goede service bieden aan je klanten. Die belofte kun je echter alleen maar waarmaken als de partijen achter de schermen dezelfde afspraken hanteren. Wanneer jouw hostingpartner alleen tijdens kantooruren bereikbaar is, terwijl jij 24/7 support belooft, zit er natuurlijk een gat tussen de verwachting en de werkelijkheid. Daarom is een SLA niet alleen een afspraak tussen de hostingprovider en een agency. Het werkt door naar de eindklant. De afspraken die jij maakt, moeten aansluiten op de afspraken die jouw leveranciers met jou maken.

Stel jezelf bijvoorbeeld de volgende vragen:

• Op welke tijden is support beschikbaar?
• Geldt de SLA ook buiten kantooruren?
• Welke incidenten hebben prioriteit?
• Wordt de omgeving actief gemonitord of wachten jullie op een melding?
• Welke werkzaamheden vallen wel of niet binnen de overeenkomst?
• Wat gebeurt er als een storing wordt veroorzaakt door software van een derde partij?

Een SLA draait om afspraken en vertrouwen

Een SLA is geen garantie dat er nooit iets misgaat. Het is een afspraak over hoe je samen omgaat met de momenten waarop er wél iets misgaat. Voor ons is een goede SLA niet alleen maar een juridisch document, maar ook een manier om verwachtingen helder te maken. Zo weet iedereen waar hij aan toe is voordat er een storing ontstaat. Uiteindelijk wil niemand tijdens een incident ontdekken dat zijn verwachtingen anders waren dan de afspraken op papier. Lees dus echt eerst je SLA door, voordat je deze in een mapje sleept en nooit meer bekijkt.

DevNomads Service Level (Up) Agreement

Bij DevNomads hebben we een eigen SLA ontwikkeld. Niet alleen omdat een SLA een verplicht juridisch document is, maar omdat we geloven dat goede dienstverlening begint met heldere afspraken en realistische verwachtingen. Met een Service Level Agreement leg je, zoals de naam al zegt, vast welke afspraken je maakt over het niveau van de dienstverlening. Dit strekt zich uit over zowel de technische dienstverlening als de service die daarop wordt verleend. Het biedt ons de middelen om beschikbaar te zijn en adequaat te reageren als dat nodig is, en geeft onze klanten duidelijkheid over wij in die rol de continuïteit waarborgen. Wat mag je van ons verwachten en waar kun je aanspraak op maken?

Een SLA is voor ons meer dan een document met responstijd en uitzonderingen. Het is de basis voor een goede samenwerking, want continuïteit kun je als hostingpartner niet alléén garanderen.

Neem uptime als voorbeeld. Uptime bereik je als hoster nooit alleen. Het is een samenspel tussen het gekozen hostingplatform, de applicatie, het gedrag van bezoekers en het gedrag van andere actoren, zoals bots, AI-agents en zoekmachine-indexaties. Ook de kwaliteit van de applicatie en de snelheid waarmee ontwikkelaar en hoster kunnen samenwerken, hebben hier grote invloed op. Uptimepercentages zijn daarom niet onbelangrijk om af te stemmen, maar ze zijn relatief en vertellen nooit het hele verhaal. Bovendien, heb je weleens uitgerekend hoe lang je met een beschikbaarheid van 99,7% per jaar eigenlijk offline mag zijn?

In de praktijk zijn open communicatie, goede wederzijdse bereikbaarheid en snel kunnen schakelen veel belangrijker dan het verschil tussen twee uptimepercentages. De wederzijdse afhankelijkheid tussen applicatie en hostingplatform én een goede samenwerking tussen ontwikkelaar, klant en hoster zijn uiteindelijk de doorslaggevende factoren.

Daarom zien wij een SLA niet als een lijst met garanties, maar als duidelijke afspraken over verwachtingen, verantwoordelijkheden en samenwerking. Juist als er iets misgaat, blijkt hoe waardevol die afspraken zijn.