Een foutmelding is voor de ontvanger
Een automatisering die stopt, moet dat zo melden dat een niet-techneut weet wat er ligt en wat hij moet doen. Wat een bruikbare melding bevat.
5 november 2026 · Jeffrey · 4 min lezen
Er staat een mail in de postbus van de administratie: "Error 500 in stap 14 (HTTP_RETRY_EXHAUSTED), zie log." Afzender: de koppeling die orders inleest. De medewerker die hem leest, weet drie dingen niet: wat er is misgegaan, of er nu orders kwijt zijn, en wat ze moet doen. Dus doet ze wat iedereen doet met een melding die niet voor mensen is geschreven: ze laat hem staan tot er iemand belt.
Daarmee is de melding niet mislukt omdat de techniek faalde, maar omdat hij aan de verkeerde ontvanger is gericht. De bouwer die hem schreef, schreef hem voor zichzelf.
Wat er over foutmeldingen bekend is
Over foutmeldingen in software bestaat behoorlijk wat onderzoek, en de samenvatting van Nielsen Norman Group uit 2023 zet de richtlijnen op een rij in drie groepen. De melding moet zichtbaar zijn op de plek waar de fout zich voordoet. Hij moet in taal staan die de gebruiker kent, zonder technisch jargon, en precies zeggen wat er aan de hand is; alleen het probleem noemen is niet genoeg, er hoort advies bij wat de gebruiker eraan kan doen. En hij moet het werk van de gebruiker bewaren: wie een fout herstelt, hoort verder te kunnen waar hij was, niet opnieuw te beginnen.
Die richtlijnen zijn geschreven voor schermen waar een mens achter zit. Bij een automatisering is er geen scherm en geen moment; de fout gebeurt om drie uur 's nachts in een proces waar niemand naar kijkt. Dat maakt de richtlijnen niet minder geldig, maar strenger: de melding is het enige contact dat de ontvanger met de fout heeft.
De ontvanger is niet de bouwer
De eerste vraag bij elke melding is wie hem moet kunnen afhandelen. Voor een koppeling die orders verwerkt, is dat de persoon die de orders kent: de binnendienst, de administratie. Niet de bouwer, want die kent de klanten niet, en niet de eigenaar, want die is de duurste omweg naar degene die het werk doet. "Error 500 in stap 14" is voor de bouwer; het hoort in het logboek, waar het bij een reconstructie zijn werk doet. De melding die naar de administratie gaat, is een tweede tekst, over hetzelfde voorval, voor een ander publiek.
Die tekst beantwoordt vier vragen. Wat is er niet gebeurd: "de order van Bakkerij De Vries uit de mail van 07:41 staat niet in het pakket." Wat is er met het werk gebeurd: "de mail staat in de map Uitzonderingen; er is niets kwijt." Wat kan de ontvanger doen: "voer de order met de hand in, of wacht tot na de storing en meld hem dan opnieuw aan." En wanneer hoeft ze niets te doen: "de overige elf orders van vanochtend zijn gewoon verwerkt." Wie die vier zinnen leest, kan handelen zonder iemand te bellen. Elke zin minder is een telefoontje meer.
De vier vragen dwingen ook iets af aan de binnenkant: een koppeling die moet kunnen zeggen dat er niets kwijt is, moet zo gebouwd zijn dat er niets kwijt ráákt. De melding is daarmee geen laatste laagje maar een ontwerpeis, en dat is precies waarom een automatisering die stilvalt zonder geluid gevaarlijker is dan een die nooit werkte.
Waar de melding heen moet
Een melding die niemand ziet, bestaat niet. De plek hangt af van het antwoord op één vraag: moet er vandaag iemand iets mee? Zo ja, dan hoort hij waar het dagelijkse werk al kijkt: de gedeelde postbus van de afdeling, een kanaal in de groepschat, de uitzonderingenlijst in het pakket zelf. Zo nee, dan is het geen melding maar logboek, en hoort hij niet tussen de post van vandaag. Een koppeling die beide door elkaar stuurt, leert zijn ontvangers binnen een maand dat zijn mail genegeerd kan worden, en dan komt ook de melding die er wél toe doet in de stilte terecht.
Eén bestemming verdient wantrouwen: de mailbox van één persoon. Die is op vakantie precies wanneer de leverancier zijn factuurindeling verandert.
De vraag aan de bouwer
Wie een automatisering laat bouwen, kan dit regelen voordat er één regel staat: vraag de bouwer om de foutmelding te laten zien die de administratie krijgt als het misgaat, als tekst, vooraf. Staat daar iets in met een code en het woord log, dan is de melding voor de bouwer geschreven en komt het telefoontje straks bij u terecht. Staan de vier vragen erin beantwoord, in gewone woorden, dan is er over de ontvanger nagedacht, en meestal ook over de rest.
Begin met één proces
Vertel welk werk bij u het vaakst wordt overgetypt. Blijkt automatiseren daar geen goed idee, dan hoort u dat in het eerste gesprek – vóór er een factuur is.
Kennismaking is gratis en vrijblijvend. Wilt u het onderbouwd? Dan is de Automation Check €295 – verrekend als u binnen 30 dagen laat bouwen.