Alle artikels
AI

Hoe plan je als installateur storingsmeldingen automatisch in met AI?

Cover voor blogpost over storing automatisch inplannen voor installateurs

"In januari gaat de telefoon om zeven uur. Tegen negen uur krijg ik twintig meldingen van kapotte verwarming en maar drie techniekers."

Bij een installateur is de planning het hart van de zaak. En in de meeste bedrijven zit die planning letterlijk in het hoofd van één persoon. Die weet welke klant een onderhoudscontract heeft, welke technieker aan een warmtepomp mag werken, en dat mevrouw in Berchem al twee keer eerder gebeld heeft over hetzelfde toestel. Is die persoon ziek of op vakantie, dan merkt het hele bedrijf het.

In dit artikel tonen we hoe software dat werk kan overnemen: hoe een melding binnenkomt, hoe ze wordt gekoppeld aan de juiste klant en het juiste toestel, hoe de dringendheid wordt bepaald, en hoe er uit die hele stroom een planningsvoorstel komt. En we geven mee over wat AI hier wel mag doen en wat AI vooral niet mag doen.

De regel die erdoorheen loopt: de AI leest de melding, maar het maakt de planning niet. Wat dringend is, bepalen jouw regels. Welk tijdslot het wordt, zoekt een planningsalgoritme. En wie er daadwerkelijk vertrekt, beslis je zelf.

Waarom storingen plannen zo moeilijk is

Een storing inplannen klinkt eenvoudig: de klant belt, en een technieker gaat. In de praktijk moet de planner in een paar minuten zes dingen tegelijk afwegen.

  • De melding zelf is vaag. "Hij doet het niet meer" of "er knippert een rood lampje". Merk, type en foutcode ontbreken vrijwel altijd.
  • Ze komt via alle kanalen binnen. Telefoon, mail, WhatsApp, het contactformulier, en soms via de gsm van een van je techniekers.
  • Dringendheid hangt af van de context. Een uitgevallen warmtepomp in juli kan wachten. In januari, bij vriesweer, niet.
  • Contract en garantie spelen mee. Heeft de klant een onderhoudscontract met een afgesproken responstijd? Staat het toestel nog onder garantie, en via wie?
  • Techniekers zijn niet inwisselbaar. Wie aan het koelcircuit van een warmtepomp werkt, heeft een certificaat nodig. De ene kent ketels, de andere sanitair.
  • Een tweede rit kost geld. Komt de technieker zonder het juiste onderdeel, dan komt hij of zij terug. Dat is een halve dag weg en een klant die niet blij is.

Van die zes punten is er maar één echt AI-werk: de melding zelf begrijpen. De rest wil regels, goede data en een knappe planningslogica. En juist die verdeling bepaalt hoe je de software bouwt.

Pijplijn voor storingsmeldingen: telefoon, mail, WhatsApp, klantportaal en het toestel zelf komen samen en gaan door melding begrijpen, klant en toestel koppelen, dringendheid bepalen, interventie voorbereiden en een planningsvoorstel. Eenvoudige vragen krijgen een goedgekeurd antwoord, bij gasgeur wordt er niets ingepland maar meteen doorverwezen, en de planner bevestigt voor de klant een moment kiest.


Waar komen storingsmeldingen binnen?

Vijf kanalen, en de software moet ze allemaal in één lijst kunnen smelten:

  1. Telefoon. Nog altijd het belangrijkste kanaal. Wat de klant zegt, noteer je kort, of je laat de voicemail netjes uitschrijven.
  2. Mail, vaak met foto's erbij. Sorteer je je inbox vandaag al automatisch? Dan is dit de logische volgende stap: een mail in de categorie "dringend" wordt een interventie.
  3. WhatsApp, via een WhatsApp Business-account van het bedrijf. Niet via de privénummers van je techniekers, want daar verdwijnen meldingen tussen alle andere berichten weg.
  4. Een klantenportaal of webformulier. In onze ogen het beste kanaal, omdat je er zelf de juiste vragen kunt stellen. Vraag bijvoorbeeld altijd een foto van het typeplaatje van het toestel.
  5. Het toestel zelf. Steeds meer warmtepompen en ketels melden hun foutcodes via een online portaal van de fabrikant. Biedt die fabrikant een koppeling aan, dan weet je van de storing voor de klant belt. Niet elk merk maakt dat mogelijk, dus bekijk dat per merk.

Stap 1: de melding begrijpen

Hier is AI echt goed in. Het model leest de melding en vult een strak schema in:

  • wie is de klant
  • waar staat het toestel
  • welk merk en type
  • wat is het symptoom
  • is er een foutcode, en sinds wanneer.

Een foto van het typeplaatje leest AI net zo goed als een getypte tekst.

Ontbreekt er iets belangrijks, dan stelt de software één gerichte vraag. Geen "kan u ons wat meer info bezorgen?", maar "welke code staat er op het display van uw warmtepomp?".

En niet elke melding is een storing. "Hoe zet ik mijn thermostaat op zomerstand?" verdient een antwoord, geen rit. Zo'n vraag beantwoordt de software met iets uit je eigen kennisbank, alleen antwoorden die jij vooraf hebt goedgekeurd. Hoe dat werkt, lees je in klantenservice automatiseren met AI. Technische ingrepen die fout kunnen lopen, laat je overigens nooit aan de klant over, ook niet via een goedgekeurd antwoord.

Stap 2: klant en toestel koppelen

Een melding is pas bruikbaar als je weet over welk toestel het gaat. Daarvoor heb je een installatiebasis nodig: welke toestellen staan op welk adres, wanneer zijn ze geplaatst, welk contract loopt er, tot wanneer geldt de garantie, en wat gebeurde er al eerder.

Het koppelen werkt ook hier in trappen, strak eerst en pas daarna AI:

  1. Exacte gegevens. Het telefoonnummer of mailadres staat al in je klantenbestand, dan is het klaar.
  2. Het adres. Zelfde straat en huisnummer, ook als de naam iets anders gespeld is.
  3. AI, als laatste vangnet. Bijvoorbeeld een huurder die belt over het toestel van de eigenaar, of een tweede woning. De AI stelt dan een koppeling voor, en bij twijfel vraagt de software het gewoon aan de planner.

Ligt je installatiebasis vandaag nog in een Excel-bestand of in iemands hoofd? Dan begint het project daar. Geen AI-werk, wel het fundament. Hoe je zo'n bestand omzet in iets waar je op kunt bouwen, lees je in van spreadsheet naar dashboard.

Stap 3: de dringendheid bepalen

Symptoom, seizoen en weer, contract, garantie en klant gaan naar jouw triageregels. Die bepalen of een melding meteen doorverwezen wordt, vandaag nog ingepland wordt, binnen twee werkdagen of bij de volgende ronde.


Het model mag voorstellen in welke categorie een melding valt: "geen verwarming", "waterlek", "geluid", "vraag over onderhoud". Maar hoe dringend die categorie is, beslissen jouw regels. Om twee redenen.

Eerst: uitlegbaarheid. Als een klant vraagt waarom hij pas donderdag geholpen wordt, wil je een antwoord kunnen geven. "Geen warmte, maar het toestel staat in noodmodus en het vriest niet" is dan een antwoord. "Het model vond het minder dringend" is dat niet.

Tweede: consistentie. Regels behandelen elke melding op dezelfde manier, ook om zeven uur in de ochtend op een drukke maandag.

Eén categorie verdient apart genoemd te worden: gevaar. Bij gasgeur of een afgaande CO-melder plant de software niets in. De klant krijgt meteen de instructie om de woning te verlaten en de noodnummers te bellen, en de melding komt bovenaan op het bord van de planner. Zo'n melding mag nooit in een wachtrij belanden.

En nog een detail: wil je bepaalde klanten voorrang geven, bijvoorbeeld een oudere alleenstaande bewoner, bewaar dan alleen een vinkje "voorrang", niet de reden. Gezondheidsgegevens zijn gevoelige persoonsgegevens onder de GDPR, en voor de planning heb je ze sowieso niet nodig.

Stap 4: de interventie voorbereiden

Voordat de planning begint, zet de software alles klaar wat de technieker nodig heeft:

  • De historiek van het toestel. Vorige storingen, vervangen onderdelen, het laatste onderhoud.
  • Wat de foutcode betekent. De AI zoekt in de handleidingen en servicedocumenten die jij aanlevert, en toont de relevante passage (met een verwijzing naar de bron).
  • Welke onderdelen waarschijnlijk nodig zijn, en of ze in de bestelwagen of in het magazijn liggen.
  • Contract en garantie. Wat valt onder het contract, en moet een garantiegeval via de procedure van de fabrikant lopen?

Het doel is simpel: dat de technieker de eerste keer klaar is. Elke tweede rit die je voorkomt, is een halve dag die je aan een andere klant kunt besteden.

Stap 5: het planningsvoorstel

Dagplanning van drie techniekers. Een nieuwe melding over een warmtepomp met foutcode wordt voorgesteld bij technieker A van 13 tot 15 uur, omdat die het koelcertificaat heeft, al in de buurt werkt, het onderdeel in de bestelwagen heeft en binnen de responstijd blijft. Andere vrije slots vallen af wegens geen certificaat of een andere regio.


Hier verwachten veel mensen AI, maar hier hoort net geen taalmodel. Een planning maken is een puzzel met harde voorwaarden: welke technieker mag dit, wie zit in de buurt, wie heeft tijd, wie heeft het onderdeel, en haal je de responstijd van het contract? Daar bestaan al tientallen jaren prima planningsalgoritmes voor. Ze zijn sneller, goedkoper en voorspelbaarder dan een taalmodel. Niet elk probleem is een AI-probleem, en dit is er eentje.

Het algoritme doet dan zijn werk: een tot drie opties, telkens met de reden erbij. De planner kiest er één goed, of kiest iets anders. Pas daarna krijgt de klant een sms of mailtje met twee tijdvensters om uit te kiezen, en die keuze belandt automatisch in de planning.

En loopt een interventie uit? Dan rekent de software gewoon opnieuw, stelt voor welke afspraken moeten schuiven, en na jouw akkoord krijgen de betrokken klanten automatisch bericht.

En na de interventie?

Ook hier valt tijd te winnen. Na afloop spreekt de technieker een kort memo in, en de software maakt er een werkbon van: vaststelling, uitgevoerd werk, onderdelen en uren. De technieker kijkt die even na, de klant tekent op de gsm of tablet.

Vervolgens bepalen contract en garantie wat er gefactureerd wordt. De geschiedenis van het toestel wordt aangevuld, en het volgende onderhoud staat meteen in de planning. Lukt het herstellen niet meer, dan wordt de melding gewoon een offerteaanvraag voor een vervanging. Hoe die verder loopt, lees je in offertes automatiseren met AI.

En na een paar maanden heb je cijfers die de meeste installateurs nooit krijgen: hoe vaak je de responstijd haalt, hoe vaak de eerste rit volstaat, welke merken en types het vaakst uitvallen, en in welke weken je team overbelast is.

Voor wie het technisch wil weten

  • Go voor de verwerkingspijplijn en de koppelingen met telefonie, mail, WhatsApp en de fabrikantportalen.
  • PostgreSQL met een event log per toestel. Elke melding, interventie en vervanging wordt een gebeurtenis die je nooit overschrijft. Daardoor is de geschiedenis van een toestel altijd volledig. Waarom dat zo goed past bij KMO-software, lees je in event sourcing voor KMO-software.
  • Een planningsalgoritme als aparte dienst, bijvoorbeeld op basis van open-source optimalisatiesoftware zoals OR-Tools.
  • Vue.js voor het planbord en voor een mobiele webapp voor de techniekers. Deze moet ook offline werken, in een kelder is er niet altijd bereik.
  • Een API, met MCP erbovenop, zodat je planning later ook met een AI-assistent kan praten. Meer daarover in Is jouw software klaar voor MCP's?
  • Europese infrastructuur, op ons managed platform of bij jou. Kies voor privacy-gevoelige meldingen die adressen en foto's bevatten een Europees AI-model, en pin de modelversie vast.

Waar gaat het meestal mis?

  • Een installatie-database die niet klopt. Weet de software niet welk toestel waar staat, dan kan ze ook niets voorbereiden.
  • Alles automatisch willen inplannen. Een planner die het bord kent, ziet dingen die geen regel vat. Laat de software voorstellen doen, maar laat een mens beslissen.
  • De AI laten bepalen wat dringend is. Het model herkent symptomen, maar de waarden om op te classificeren zijn een beslissing van jouw bedrijf.
  • De techniekers vergeten. Is de werkbon-app omslachtig, dan gebruikt niemand die. Test hem met je techniekers, in een bestelwagen, met handschoenen aan.
  • Meldingen op privénummers laten binnenkomen. Breng eerst alle kanalen samen. Anders mist de software precies de meldingen die er het meest toe doen.

Heb je hier maatwerk voor nodig?

Eerlijk antwoord: niet altijd. Er bestaat prima planningssoftware voor installateurs, en past die bij hoe jullie werken, gebruik hem dan. Maatwerk begint te lonen wanneer je planningsregels specifiek zijn, wanneer je je huidige pakket wilt houden maar de intake en triage ervoor wil automatiseren, of wanneer meldingen binnenkomen via kanalen die je pakket niet aankan. Dan bouw je geen vervanging, maar een laag eromheen.

Veelgestelde vragen

Plant de software zelf mijn techniekers in?

Nee. Ze stelt een tot drie opties voor, telkens met de reden erbij. De planner bevestigt of kiest iets anders.

Werkt dit met mijn huidige planning- of facturatiesoftware?

Meestal wel, via de API van je pakket. Heb je nog geen pakket, dan krijg je een eigen planbord.

Kan AI bepalen hoe dringend een storing is?

Het model herkent het symptoom en stelt een categorie voor. Hoe dringend die categorie is, bepalen jouw eigen regels, met het seizoen, het contract en de garantie erbij.

Wat gebeurt er bij gasgeur of een CO-melder?

Dan wordt er niets ingepland. De klant krijgt meteen de instructie om de woning te verlaten en de noodnummers te bellen, en de melding komt bovenaan bij de planner.

Kunnen klanten storingen via WhatsApp melden?

Ja, via een WhatsApp Business-account van je bedrijf. De melding komt in dezelfde lijst als telefoon en mail terecht.

Wat met de privacy van mijn klanten?

Meldingen bevatten adressen en soms foto's van binnenshuis. Die verwerk je best op Europese servers, met een verwerkersovereenkomst.


Hoe komen storingen vandaag bij jullie binnen, en wie beslist wie er vertrekt? Vertel ons hoe jullie planning werkt, dan schetsen we samen wat er in fase één zou zitten.

Gepubliceerd op 29 sep 2026
Profile picture of cofounder Mathias
Engineering
Mathias Beke

Bouwt software die snel draait, weinig kost, en volledig op Europese servers staat.