Wanneer een website of applicatie een belangrijke rol speelt binnen marketing, verkoop of de dagelijkse operatie, kan een technisch incident direct gevolgen hebben. Klanten kunnen geen aanvraag indienen, medewerkers kunnen niet verder of essentiële informatie is tijdelijk niet beschikbaar.
Op zo’n moment wil je niet eerst uitzoeken wie bereikbaar is en wanneer iemand naar het probleem kan kijken. Met een Service Level Agreement (SLA) leggen we vooraf duidelijke afspraken vast over support en incidentafhandeling.
Een SLA vanuit bedrijfsimpact
Niet ieder incident heeft dezelfde urgentie. Een kleine visuele afwijking vraagt om een andere aanpak dan een volledig onbereikbare webshop of applicatie. Daarom spreken we verschillende prioriteitsniveaus af op basis van de impact op gebruikers en bedrijfsvoering.
Per niveau leggen we onder andere vast binnen welke termijn het incident wordt beoordeeld, hoe communicatie verloopt en welke escalatieroute wordt gevolgd. Zo weten beide partijen wat er gebeurt wanneer zich een probleem voordoet.


Bereikbaarheid die past bij jouw organisatie
Afhankelijk van het belang van het platform kunnen we afspraken maken over support tijdens kantoortijden én over bereikbaarheid buiten reguliere werktijden.
Webreact biedt onder andere mogelijkheden voor 12×5- en 24×7-bereikbaarheid. De passende vorm hangt af van de bedrijfsimpact, technische omgeving en afhankelijkheden van externe leveranciers. Een SLA wordt daarom altijd op maat ingericht. Een corporate website vraagt om andere garanties dan een applicatie waarop een operationeel proces dag en nacht afhankelijk is.
Ondersteuning door mensen die het platform kennen
Een incident wordt sneller onderzocht wanneer het supportteam de applicatie, hostingomgeving en architectuur al kent. Daarom bieden we een SLA alleen aan in combinatie met managed hosting en technisch beheer. Onze developers beschikken dan over toegang, documentatie en kennis van de belangrijkste processen. Dat voorkomt dat kostbare tijd verloren gaat aan het verzamelen van basisinformatie op het moment dat de druk al hoog is.
Heldere communicatie tijdens een incident
Een organisatie wil tijdens een storing niet alleen weten dát eraan wordt gewerkt. Belangrijker is duidelijkheid over de impact, voortgang, eventuele tijdelijke oplossing en het moment van een volgende update. Daarom maken communicatie en escalatie expliciet onderdeel uit van de afspraken.
Na een belangrijk incident kunnen we bovendien onderzoeken wat de oorzaak was en welke structurele verbetering nodig is om herhaling te voorkomen.

Eerlijk over afhankelijkheden
Een SLA voorkomt niet dat er ooit een storing ontstaat. Ook kan Webreact geen onbeperkte garanties geven over onderdelen die volledig worden beheerd door externe software- of infrastructuurleveranciers. Daarom maken we vooraf duidelijk welke onderdelen binnen onze invloed en verantwoordelijkheid vallen.
Reactietijden kunnen we garanderen. Hersteldoelstellingen en beschikbaarheidsafspraken worden bepaald op basis van de technische omgeving en aanwezige afhankelijkheden. Die duidelijkheid voorkomt verkeerde verwachtingen wanneer het er werkelijk toe doet.
Heb je nog vragen?
-
Voor websites en webshops werken we standaard met een onderhoudscyclus van zes maanden. Twee keer per jaar lopen we de techniek grondig na en voeren we geplande updates uit. We kiezen bewust voor een gecontroleerd ritme: iedere nieuwe release direct installeren is niet automatisch veiliger of beter.
Voor maatwerksoftware bepalen we de onderhoudsfrequentie per applicatie. De gebruikte technologie, koppelingen, bedrijfsimpact en snelheid waarmee afhankelijkheden veranderen bepalen welk ritme verstandig is.
Kritieke beveiligingsproblemen wachten uiteraard niet op het volgende geplande onderhoudsmoment.
-
Bij websites en webshops onderhouden we de technische basis, zoals het CMS, thema, plug-ins en andere gebruikte componenten. We controleren daarnaast of belangrijke functionaliteiten na wijzigingen correct blijven werken en houden relevante beveiligingsinstellingen actueel.
Bij maatwerksoftware kijken we onder andere naar frameworks, libraries, API-koppelingen, achtergrondprocessen en andere technische afhankelijkheden. Hiervoor stellen we een beheerplan op dat aansluit op de architectuur van de applicatie.
Kleine technische problemen kunnen we vaak binnen de beschikbare beheeruren oplossen. Vraagt een probleem om omvangrijke aanpassingen of nieuwe functionaliteit, dan bespreken we dit vooraf. Dat valt onder doorontwikkeling en wordt niet ongemerkt als regulier onderhoud uitgevoerd.
-
Dan wachten we niet tot het volgende onderhoudsmoment. Bij een relevante kwetsbaarheid beoordelen we de ernst en bepalen we welke actie nodig is. Dat kan bijvoorbeeld een beveiligingsupdate, tijdelijke maatregel of aanvullende technische aanpassing zijn.
Hetzelfde geldt bij een storing. Je kunt altijd contact met ons opnemen en wij onderzoeken wat er aan de hand is. Afhankelijk van het onderhoudspakket of aanvullende SLA-afspraken kunnen monitoring, bereikbaarheid en reactietijden uitgebreider zijn geregeld.
Zo combineren we gepland preventief onderhoud met de mogelijkheid om in te grijpen wanneer de situatie daar tussentijds om vraagt.
-
Niet iedere update wordt automatisch rechtstreeks op de live-omgeving geïnstalleerd. De aanpak hangt af van het platform en het gekozen beheer- of onderhoudsniveau.
Bij websiteonderhoud kan dat variëren van automatische updates tot handmatige updates waarbij we belangrijke functionaliteiten controleren. Binnen het Premium-pakket testen we wijzigingen eerst in een aparte testomgeving voordat ze naar productie gaan.
Voor maatwerksoftware bepalen we vooraf welke onderdelen na een wijziging getest moeten worden en of een test- of acceptatieomgeving nodig is. Hoe bedrijfskritischer de oplossing, hoe belangrijker een gecontroleerd update- en releaseproces wordt.
-
Ja. Voor websites en webshops zijn back-ups onderdeel van onze onderhouds- en hostingoplossingen. Binnen het Starter-pakket maken we standaard wekelijks een back-up en binnen Business en Premium dagelijks. De standaard retentieperiode is vier weken.
Bij maatwerksoftware stemmen we de back-upstrategie af op de applicatie en de hoeveelheid data die verloren mag gaan. Een bedrijfskritische applicatie kan immers andere eisen stellen aan back-upfrequentie en herstel dan een reguliere website.
Wanneer herstel nodig is, kunnen we op basis van de beschikbare back-ups teruggaan naar een eerdere werkende situatie.
Klaar voor de volgende stap? Laat het ons weten.