Onderhoudsvenster-berichtsjablonen die gebruikers kalmeren tijdens gepland onderhoud, gedeeltelijke storingen en verminderde prestaties, waardoor paniek en supporttickets afnemen.
De meeste onderhoudsberichten mislukken om één eenvoudige reden: ze creëren onzekerheid. Een banner die zegt “We voeren onderhoud uit” zonder details dwingt gebruikers te raden wat kapot is, hoe lang het duurt en of hun werk veilig is. Raden verandert in angst, en angst verandert in supporttickets.
Vage berichtgeving wekt ook argwaan. Als gebruikers fouten zien maar jouw bericht kalm en generiek klinkt, denken ze dat je het echte probleem verbergt. Die kloof tussen wat ze ervaren en wat je zegt ondermijnt vertrouwen.
Mensen hebben meestal meteen drie dingen nodig: duidelijke impact, duidelijke timing en duidelijke vervolgstappen.
Impact betekent benoemen wat beïnvloed is (inloggen, exports, betalingen), niet alleen “dienstonderbreking.” Timing betekent een specifiek venster en wanneer de volgende update komt, niet “binnenkort.” Vervolgstappen vertellen wat ze moeten doen terwijl ze wachten, zoals “probeer het over 20 minuten opnieuw” of “gebruik de mobiele app in plaats daarvan.”
Overbeloften maken het snel erger. “Geen impact verwacht” is riskant tenzij je echt zeker bent. Zodra zelfs één gebruiker is getroffen, is die zin bewijs dat je niet oplet. Eerlijke updates werken beter: zeg wat je weet, wat je nog niet weet en precies wanneer je weer controleert.
Het doel is niet om de situatie te verdraaien. Het doel is onzekerheid te verminderen. Wanneer mensen begrijpen wat er gebeurt, wat het voor hen betekent en wat ze nu moeten doen, stoppen ze met verversen, stoppen ze met het ergste te veronderstellen en stoppen ze met tickets openen alleen om controle te krijgen.
Gebruikers ontspannen wanneer je de situatie in eenvoudige woorden benoemt. Als je alles “onderhoud” of “problemen” noemt, gaan mensen uit van het slechtste en beginnen ze te herhalen, verversen en tickets te openen.
Begin met het juiste label:
“Degraded” mag nooit vaag zijn. Zeg wat de gebruiker zal merken. Bijvoorbeeld: “Exports kunnen 10 tot 20 minuten langer duren dan normaal” is duidelijker dan “Er zijn verminderde prestaties.”
Wees specifiek over wat beïnvloed is, zelfs als de lijst kort is. Noem de gebieden die mensen het meest interesseren: inloggen, betalingen en facturatie, synchronisatie, meldingen, dashboards, exports, API-toegang en bestandsuploads.
Vermijd angstaanjagende woorden, maar verberg de waarheid niet. Vervang “kritische fout” door “sommige gebruikers kunnen niet inloggen” en vervang “system instability” door “je kunt time-outs zien bij het opslaan.” Een kalme toon komt voort uit nauwkeurigheid, niet uit optimisme.
Als je het niet zeker weet, kies het label dat bij de gebruikersimpact past, niet de interne oorzaak. “Database onderhoud” zegt weinig tegen de meeste mensen. “De facturatiepagina kan tot 15 minuten onbeschikbaar zijn” vertelt wat ze kunnen verwachten en wat ze moeten doen.
Gebruikers vertrouwen wat ze exact zien op het moment dat ze geblokkeerd zijn. Goede berichtsjablonen gaan minder over slimme formuleringen en meer over het gebruik van het juiste oppervlak.
Gebruik een in-app banner voor het meeste geplande werk. Deze blijft zichtbaar terwijl mensen doen wat ze kunnen, en kap het scherm niet weg.
Gebruik een modal alleen wanneer de gebruiker niet veilig kan doorgaan (betalingshandelingen, gegevensbewerkingen, aanmeldingen). Als je een modal gebruikt, laat mensen hem sluiten en houd daarna een persistente banner.
Toasts zijn het beste voor korte, laag-risico updates (bijvoorbeeld: “Exports kunnen 10 minuten langzamer zijn”). Ze zijn makkelijk te missen, dus gebruik ze niet voor echte downtime.
Een eenvoudige regel:
Als gebruikers mogelijk niet kunnen inloggen, zet hetzelfde bericht op het aanmeldscherm. Hier begint paniek, omdat gebruikers aannemen dat hun account kapot is. Een eenvoudige mededeling zoals “Inloggen kan mislukken tussen 02:00–02:30 UTC” vermindert snel tickets.
Gebruik je statuspagina voor doorlopende updates en geschiedenis (wat veranderd is, wat nog beïnvloed is, wat hersteld is). Gebruik de in-app melding voor wat de gebruiker nu moet doen (wachten, later opnieuw proberen, exports vermijden, etc.). Verberg kritieke details niet alleen op de statuspagina, want veel gebruikers zullen die nooit bekijken.
E-mail en pushmeldingen helpen wanneer de impact groot is en gebruikers moeten plannen. Anders voelen ze zich luidruchtig. Als je ze verstuurt, houd ze consistent met de in-app tekst.
Stem ten slotte support af op dezelfde bewoording. Je automatische antwoord moet overeenkomen met de bannertekst en statusupdates zodat gebruikers geen tegenstrijdige berichten krijgen.
Mensen vertrouwen onderhoudsmededelingen wanneer ze specifiek, eerlijk en nuttig aanvoelen. Dat betekent niet lang. Het betekent het beantwoorden van de vragen die een gestreste gebruiker in de eerste 10 seconden heeft, met duidelijke timing en een plan.
Een betrouwbaar bericht bevat vijf basiszaken:
Tijd is waar berichten vaak vertrouwen verliezen. Gebruik een venster dat mensen begrijpen, zoals “16 jan, 01:00 tot 02:30 UTC.” Als je een groot wereldwijd publiek hebt, overweeg een tweede referentietijd die veel gebruikers delen (bijvoorbeeld “08:00 tot 09:30 Singapore tijd”). Vermijd valse precisie zoals “terug om 02:17.” Een bereik zoals “30 tot 60 minuten” voelt eerlijker en vermindert boze verversacties.
Als je iets nog niet weet, zeg wat je als volgende controleert. Bijvoorbeeld: “We onderzoeken verhoogde databaselast en bekijken recente deploys en trage queries. Volgende update om 14:30 UTC.” Die ene zin verandert stilte in een plan.
Voeg altijd een volgende update-tijd toe, zelfs als die snel is en zelfs als er niets verandert. “Volgende update over 20 minuten” kalmeert omdat het een belofte zet die je kunt nakomen.
Voorbeeld van vertrouwenwekkende details: “Bestandsexports kunnen 10 tot 30 minuten langer duren dan gewoonlijk. In de tussentijd kun je rapporten in de app bekijken. We plaatsen een nieuwe update voor 16:10 UTC.”
Goede onderhoudsmededelingen voelen kalm omdat ze specifiek en consistent zijn. Behandel ze als checklists, niet als aankondigingen.
Schrijf de eerste versie met duidelijke placeholders. Begin met: wat is beïnvloed, wanneer begint het, hoe lang kan het duren en wie is getroffen. Laat haken voor details die je later bevestigt (exacte eindtijd, getroffen regio's, functienaam). Zo kun je vroeg publiceren zonder te gokken.
Kies een ernstlabel dat bij de realiteit past. Gebruik één label en houd dat aan op je banner, statuspagina en e-mail. Bijvoorbeeld: Maintenance (gepland), Partial outage (sommige gebruikers of functies), Degraded performance (traag of vertraagd). Als je kleuren gebruikt, houd die consistent (groen = normaal, geel = gedegradeerd, rood = storing) zodat gebruikers snel kunnen scannen.
Voeg één zin toe die het label in gewone taal uitlegt. “Degraded” moet altijd iets concreets betekenen zoals “exports kunnen 5–15 minuten duren.”
Bied een workaround als dat mogelijk is. Zelfs een klein alternatief vermindert tickets. Voorbeeld: “Als je het rapport nu nodig hebt, gebruik de CSV-download vanaf het dashboard terwijl geplande exports vertraagd zijn.” Als er geen workaround is, zeg dat één keer duidelijk.
Plan je updates voordat je publiceert. Plan twee herinneringen: één kort vóór het venster en één “start nu”-bericht op het exacte starttijdstip. Als de timing verandert, werk het bericht eerst bij en stuur daarna de herinnering.
Rond af met een finale update. Zeg wat veranderd is, wanneer het hersteld was en wat gebruikers moeten doen als iets nog niet klopt (ververs, opnieuw proberen of contact opnemen met support met specifieke informatie zoals tijdstempel of job-ID).
Gebruik deze sjablonen als uitgangspunt en pas de details aan op wat jouw gebruikers daadwerkelijk doen in je product. Houd de toon kalm en simpel. Geef één duidelijke actie die gebruikers kunnen ondernemen.
Onderwerp/Titel: Gepland onderhoud op [Dag], [Datum] om [Starttijd] [TZ]
Bericht: We hebben gepland onderhoud op [Dag, Datum] van [Starttijd] tot [Eindtijd] [TZ].
Tijdens dit venster is [wat onbeschikbaar zal zijn]. [wat nog werkt] blijft beschikbaar.
Als je je moet voorbereiden: voltooi [aanbevolen actie, bv. exports afronden, concepten opslaan] voor [tijd]. We plaatsen updates hier tijdens het venster.
Titel: Onderhoud is nu begonnen
Bericht: Het onderhoud is begonnen en duurt naar verwachting tot [Eindtijd] [TZ].
Op dit moment is [wat onbeschikbaar is]. Als je probeert [veelvoorkomende taak], kun je [verwachte fout/gedrag] zien.
Volgende update om [tijd] (of eerder als er iets verandert).
Titel: Onderhoud duurt langer dan gepland
Bericht: Het onderhoud duurt langer dan verwacht. De nieuwe geschatte eindtijd is [Nieuwe eindtijd] [TZ].
Wat dit voor jou betekent: [impact in één zin]. Wat je nu kunt doen: [veilige workaround of “probeer het na X”].
Sorry voor de verstoring – we delen een nieuwe update om [tijd].
Titel: Onderhoud voltooid
Bericht: Het onderhoud is voltooid sinds [tijd] [TZ].
Je kunt nu [top 2–3 belangrijkste acties om te verifiëren, bv. inloggen, een export uitvoeren, een betaling indienen]. Als iets nog niet goed lijkt, probeer [simpele stap zoals verversen/opnieuw inloggen] en neem dan contact op met support met [welke info mee te sturen, bv. tijd, account, screenshot].
Titel: Monitoring na onderhoud
Bericht: Systemen zijn weer online en we monitoren de komende [X uren] nauwgezet.
Je kunt [kleine symptomen, bv. tragere laadtijden, vertraagde e-mails] opmerken terwijl queues inlopen. Als je fouten tegenkomt, probeer het na [tijd] nogmaals.
Volgende update om [tijd] (of eerder bij een probleem).
Als de app niet volledig uitvalt, veroorzaken vage banners de meeste paniek. Wees specifiek over wat beïnvloed is (functie, regio of stap), wat nog werkt en wat gebruikers nu moeten doen.
Gebruik wanneer het grootste deel van het product werkt, maar één gebied niet.
Sjabloon
Titel: Partial outage: [feature/service] niet beschikbaar in [regio/accounttype]
Tekst: We zien een probleem waarbij [feature] niet werkt voor [wie getroffen is]. Andere delen van de app, inclusief [wat nog werkt], functioneren normaal. Ons team werkt aan een oplossing.
Impact: Je kunt [foutmelding/symptoom] zien wanneer je probeert [actie].
Workaround: Totdat dit is opgelost, [veilig alternatief].
Volgende update: Voor [tijd + tijdzone] (of eerder als opgelost).
Gebruik wanneer verzoeken succesvol zijn maar traag aanvoelen.
Sjabloon
Titel: Degraded performance: trager dan normaal [gebied]
Tekst: Sommige acties duren langer dan normaal, vooral [specifieke acties]. Je kunt time-outs of retries zien, maar data zou niet verloren moeten gaan.
Wat te doen: Als je een fout krijgt, wacht [X minuten] en probeer het opnieuw. Vermijd het herhalen van dezelfde actie (dat kan duplicaten veroorzaken).
Volgende update: Voor [tijd + tijdzone].
Gebruik wanneer het grootste probleem onzekerheid is.
Sjabloon
Titel: Intermitterend probleem: [feature] kan onvoorspelbaar falen of slagen
Tekst: We onderzoeken een probleem waarbij [feature] soms werkt en soms faalt. Als het faalt, is het veilig om na [X minuten] nogmaals te proberen.
Hoe helpen: Als je contact opneemt met support, voeg dan [request ID / tijdsbestek / getroffen regio] toe.
Gebruik wanneer gebruikers zich niet kunnen aanmelden. Houd het kalm en direct.
Sjabloon
Titel: Aanmeldproblemen: sommige gebruikers kunnen zich mogelijk niet aanmelden
Tekst: We zien verhoogde aanmeldfouten voor [wie getroffen is]. Als je vastzit, reset je wachtwoord niet herhaaldelijk tenzij je een duidelijke foutmelding ziet die dat aangeeft.
Wat te proberen: Ververs één keer, wacht [X minuten] en probeer het opnieuw. Als je SSO gebruikt, noteer of het SSO only is of alle aanmeldmethoden.
Gebruik wanneer gebruikers denken dat gegevens ontbreken.
Sjabloon
Titel: Gegevensvertraging: [rapporten/sync/analytics] kunnen [X minuten/uren] achterlopen
Tekst: Nieuwe activiteit kan langer duren om te verschijnen in [gebied]. Je data wordt nog steeds verzameld, maar verwerking is vertraagd.
Wat dit betekent: Exports/rapporten gemaakt tijdens deze periode kunnen onvolledig zijn. Indien mogelijk, wacht tot [tijd] om kritieke rapporten uit te voeren.
Volgende update: Voor [tijd + tijdzone].
De meeste supportpieken tijdens onderhoud worden niet door het onderhoud zelf veroorzaakt. Ze komen voort uit bewoording die mensen doet raden wat er gebeurt, hoe het hen raakt en wanneer het voorbij zal zijn. Als gebruikers moeten gokken, openen ze tickets.
Patronen die snel paniek veroorzaken:
Een klein voorbeeld: je exporttool is traag maar de rest van de app werkt. Als je banner zegt “Service outage”, stoppen gebruikers die niet exporteren alsnog en sturen ze supportberichten. Als het zegt “Exports kunnen 10–20 minuten duren; dashboards en bewerkingen zijn normaal. Volgende update om 14:30 UTC,” wachten veel mensen gewoon.
Als je berichtsjablonen bouwt, streef naar eenvoudige taal die drie vragen snel beantwoordt: Wat is beïnvloed, wat moet ik nu doen en wanneer krijg ik de volgende update.
Lees je bericht voor publicatie alsof je een bezorgde klant bent. Het doel is simpel: onzekerheid verminderen.
Zorg dat de bewoording overeenkomt op je banner, e-mail, helpdesk-macro's en eventuele statusberichten. Als de ene “degraded” zegt en de andere “down”, denken mensen dat je iets verbergt.
Houd de toon kalm en feitelijk. Vermijd hype, grappen of zinnen als “geen zorgen”. Een eenvoudige, stabiele zin zoals “We onderzoeken trage exports” werkt beter dan proberen opgewekt te klinken.
Doe de helderheidstest: kan een nieuwe gebruiker het probleem in één zin herhalen zonder eigen aannames toe te voegen? Zo niet, herschrijf het.
Als het voorbij is, rond het dan expliciet af: bevestig dat het is opgelost, geef de tijd van oplossing en vertel gebruikers wat ze daarna moeten doen (bijv. “Probeer je export opnieuw” of “Als je nog fouten ziet, ververs en probeer het nogmaals”).
Een veelvoorkomend “alles is kapot”-moment is wanneer één functie faalt terwijl de rest van de app normaal lijkt. Stel je een financieel hulpmiddel voor: de facturatiepagina laadt, facturen verschijnen en betalingen verlopen, maar CSV-exports time-outen voor sommige gebruikers. Mensen verversen, proberen het opnieuw en openen supporttickets omdat ze denken dat data ontbreekt.
Het eerste bericht moet zeggen wat werkt, wat niet werkt, wie getroffen is en wat te doen. Bijvoorbeeld:
“Het exporteren van facturen naar CSV time-outt momenteel voor sommige accounts. Facturatiepagina's en betalingen werken normaal. Als je data dringend nodig hebt, gebruik de filters op het scherm en kopieer de resultaten, of probeer te exporteren met een kleiner datumbereik. We onderzoeken het en plaatsen over 15 minuten een update.”
In het volgende uur moeten de updates evolueren van “we zien het” naar “dit is wat er veranderd is”:
Het eindbericht sluit de lus. Het bevat de fix, scope en een duidelijk supportpad:
“Opgelost: we hebben export-worker capaciteit verhoogd en timeout-instellingen aangepast. Van 10:05–11:05 UTC faalden sommige CSV-exports, maar facturatie en betalingen bleven beschikbaar. Als je nog steeds niet kunt exporteren, reageer op je laatste ticket met de exporttijd en het factuurbereik.”
Teams die zo communiceren zien meestal minder tickets omdat gebruikers drie dingen snel leren: hun data is veilig, wat ze nu moeten proberen en wanneer de volgende update komt.
Behandel onderhoudscommunicatie als een klein productfeature, niet als een eenmalige verontschuldiging. Het doel is consistentie: gebruikers moeten het patroon herkennen, weten wat te doen en erop vertrouwen dat je op schema updatet.
Zet je beste copy om in herbruikbare blokken met duidelijke variabelen en bewaar ze op één plek zodat iedereen in het team een melding kan publiceren zonder helemaal opnieuw te schrijven. Standaardiseer basics zoals starttijd, verwachte eindtijd, getroffen functies, regio's en wie is beïnvloed (alle gebruikers vs een subset).
Leg eigenaarschap en een simpele goedkeuringsflow vast. Eén persoon schrijft, één persoon keurt goed en één persoon publiceert, ook al zijn twee van die rollen bij kleine teams dezelfde persoon. Stel van tevoren een update-cadans in (bijv. elke 30 minuten tijdens een incident) zodat support niet hoeft te raden wanneer de volgende boodschap komt.
Wees voorzichtig met termen als “snapshots” en “rollback”. Beloon alleen wat je betrouwbaar kunt leveren onder druk. Als rollback mogelijk maar niet gegarandeerd is, zeg dat eerlijk en focus op wat gebruikers kunnen vertrouwen.
Als je dit herhaalbaar in de productervaring wilt maken, helpt het om de leveringspunten één keer te bouwen en te hergebruiken: een in-app bannercomponent, een lichte statuspagina en een nazorg “alles ok” flow. Als je team producten bouwt met Koder.ai (koder.ai), kun je deze UI-onderdelen en updateflows creëren via een chatgestuurd bouwproces, en daarna de copy en variabelen aanpassen zonder de hele app te herbouwen.
Rond af met een dry run tijdens een laag-risico onderhoudsvenster. Gebruik echte sjablonen, publiceer naar de echte oppervlakken, tim je updates en evalueer achteraf:
Zodra je die lus hebt, worden je sjablonen geen documenten meer maar een gewoonte.
Begin met wat beïnvloed is, hoe lang het ongeveer duurt, en wat de gebruiker nu moet doen. Een eenvoudige regel zoals “Exports kunnen 10–20 minuten langer duren; dashboards werken normaal; volgende update om 14:30 UTC” voorkomt raden en vermindert tickets.
Gebruik Maintenance voor gepland werk met een duidelijk tijdvenster, Partial outage wanneer een specifieke functie/regio uitvalt, en Degraded performance wanneer dingen werken maar traag of foutgevoelig zijn. Kies het label dat overeenkomt met wat gebruikers ervaren, niet met de interne oorzaak.
Omschrijf in één zin wat de gebruiker zal merken en kwantificeer het waar mogelijk. Bijvoorbeeld: “Exports kunnen 10–30 minuten duren en bij grote datumbereiken kunnen time-outs optreden” in plaats van “We zien verminderde prestaties.”
Gebruik een in-app banner voor de meeste situaties zodat mensen kunnen doorwerken. Gebruik een modal alleen wanneer doorgaan fouten of dataverlies kan veroorzaken (zoals bij betaalacties of bewerkingen), en laat daarna een blijvende banner staan zodat het bericht niet verdwijnt.
Plaats hetzelfde bericht op het aanmeldscherm wanneer aanmelden mogelijk kan mislukken, want daar begint paniek. Als je alleen binnen de app updates plaatst, denken buitengesloten gebruikers dat hun account kapot is en overstromen ze support.
Vermijd valse zekerheid zoals “Geen impact verwacht” tenzij je er echt zeker van bent. Zeg wat je weet, wat je nog niet weet, en wanneer je de volgende update geeft; die eerlijkheid wordt gelezen als bekwaamheid, niet als zwakte.
Geef altijd een specifieke volgende update-tijd, zelfs als er niets verandert. “Volgende update over 20 minuten” zet een belofte waar gebruikers op kunnen rekenen en vermindert de ververs-en-ticket-cyclus.
Geef één veilige actie die risico en duplicaten vermindert. Bijvoorbeeld: “Probeer één keer opnieuw na 2 minuten”, “Vermijd het herhalen van dezelfde export”, of “Gebruik een kleiner datumbereik”. Als er geen workaround is, zeg dat dan duidelijk één keer.
Zeg wat beïnvloed is, wat nog werkt en wat te doen als ze geblokkeerd zijn. Vertel gebruikers niet herhaaldelijk risicovolle acties uit te voeren (zoals wachtwoordresets of meervoudige inzendingen) tenzij het bericht dat specifiek adviseert.
Sluit expliciet af met een “opgelost”-melding die de tijd bevat, wat hersteld is, en wat te proberen als iets nog steeds niet goed lijkt (ververs, opnieuw inloggen, één keer opnieuw proberen). Als gebruikers nog randgevallen kunnen zien, zeg dat je monitort en wanneer je de definitieve bevestiging post.
