Spoeddienst automatiseren: intake van dringende aanvragen en geprioriteerde dispatch in één platform, plus een informatiesite die gevonden wordt.
AI-automatisering voor spoed- en storingsdiensten gaat over rust in de drukte: dringende meldingen komen gestructureerd binnen, krijgen een prioriteit in één overzicht en bereiken de monteur, terwijl een aparte site zorgt dat zoekers je vinden. EIGHTY8 bouwde zowel het intakeplatform als de vindbaarheidssite voor een storingsdienst, en belooft geen responstijden. Die hoort bij jouw dienst, niet bij de techniek.
Een storingsdienst leeft van wachten tot het misgaat. En dat wachten is chaotisch van binnen. Meldingen komen binnen via oproep, app, formulier en doorverwijzing, elk in een ander formaat: waar staat het object, wat is er kapot, hoe dringend is het, is er gevaar. De coördinator die dat alles in zijn hoofd of op papiertjes bewaart, is de single point of failure van de dienst.
Dan de prioritering. Twee meldingen tegelijk, één monteur beschikbaar, en de beslissing wie eerst gaat valt op wie het hardst belt. Zonder één overzicht dat meldingen op urgentie en locatie rangschikt, wordt de volgorde bepaald door toeval. En de klant die te laat geholpen wordt, is niet per se de minst dringende geweest.
En er is de vindbaarheid. Wie een storing heeft, zoekt nu, hier, en belt degene die bovenaan staat. Een dienst zonder een site die op die zoektermen gevonden wordt, laat die opdrachten liggen voor partijen die het werk niet beter uitvoeren. En de meldingen die dan wél binnenkomen, komen binnen als losse berichten in plaats van als gestructureerde aanvragen.
Twee dingen die samen één dienst vormen: het platform waar meldingen binnenkomen, geprioriteerd worden en naar monteurs gaan, en de informatiesite waar zoekende klanten je vinden en een melding kunnen doen. De kaarten hieronder zijn de bouwstenen. Wat we bewust níet leveren is een belofte over hoe snel er gereageerd wordt. Dat is een besluit van jouw dienst, niet een eigenschap van software.
Discovery bij de coördinatie zelf: hoe komt een melding nu binnen, welke velden zijn er nodig om te handelen, hoe beslis je over volgorde, en wat moet een monteur zien voordat hij vertrekt. Uit die analyse komt een scope met aannames en een offerte op nacalculatie.
Het platform bouwen we rond jouw werkregels: de intake vraagt wat de dispatcher nodig heeft, de prioritering volgt regels die jij vaststelt en kan aanpassen, en de toewijzing aan monteurs gebeurt in één overzicht. Een agent kan melder-updates en statusberichten voorbereiden (concepten die een mens verstuurt) terwijl beslissingen over mensen en veiligheid altijd menselijk blijven.
De informatiesite is het publieke deel: gevonden worden op de juiste zoektermen, uitleg wat bij een storing te doen, en een meldmogelijkheid die direct in het platform landt. Na de livegang kijken we waar meldingen nog onvolledig binnenkomen en stellen we de intake bij.
Twee projecten voor één storingsdienst staan openbaar op onze casepagina: het platform rond intake en geprioriteerde dispatch, en de bijbehorende informatiesite die op de juiste zoektermen gevonden wordt en waarvan de sitemap automatisch meegroeit. Wat je daar níet leest: hoeveel meldingen de dienst afhandelt, welke opdrachtgevers erachter zitten en welke responstijden zij hanteren. Die beloftes hoort bij de dienst zelf, niet bij een casebeschrijving.
Een melding draagt namen, adressen en vaak toegangsgegevens tot een gebouw. Gegevens die in de verkeerde handen schade doen. We leggen per workflow vast wie wat ziet, hoe lang een afgehandelde melding bewaard wordt en welke velden een agent mag lezen bij het opstellen van een statusbericht. Toegang is per rol geregeld: de monteur op pad ziet zijn melding, niet de hele dagplanning. Alles wat een melding raakt is via logging terug te volgen, en jouw eigen operationele protocollen blijven leidend naast de AVG.
Een traject hier wordt vooraf gescopet en op nacalculatie afgerekend, met een offerte waarin alle aannames staan: hoeveel meldingstromen er zijn, of de informatiesite opnieuw gebouwd wordt of blijft, en hoeveel monteurs en rollen het platform moet dragen. Er is geen vaste brancheprijs. Een dienst met twee monteurs en een dienst met een wachtlijst zijn andere bouwopgaven, en wij rekenen het werk, niet de categorie.
De software rangschikt, de coördinator beslist. Meldingen krijgen een prioriteit op basis van regels die jullie zelf vaststellen (gevaar, objecttype, wachttijd) en die regels zijn aan te passen zodra jullie er anders over oordelen. De toewijzing aan een monteur is een klik in het overzicht, nooit een automatische uitruil. In dit vak is de volgorde van hulp een professionele oordeelsvraag, en we bouwen de techniek daaromheen, niet erdoorheen.
Bij een kleine dienst is het overzicht juist het schaarsste: één persoon coördineert naast zijn eigen werk, en één drukke avond bepaalt of meldingen wegvallen. We beginnen daarom met alleen de intake en het overzicht, zonder extra modules, in de tools die je al gebruikt. Groeit de dienst, dan groeit het platform mee. Wat het niet wordt, is een zwaar systeem dat beheer vraagt dat je niet hebt. Dat zetten we vooraf uit in de scope.
We bouwen eerst rond wat er al is. Heeft je planningpakket of de app van je monteurs een koppeling, dan stromen meldingen daarnaartoe en komen statussen terug. Monteurs merken niets nieuws. Bestaat die weg niet, dan vangt het overzicht het op en werkt het als enkel overzicht naast je huidige aanpak. In de discovery leggen we vast welke route het wordt, en het uitgangspunt blijft dat niemand tweemaal hetzelfde intoetst.
Via scope en nacalculatie. De discovery telt op hoeveel meldingstromen er zijn, of de informatiesite nieuwgebouwd wordt of blijft staan, hoeveel monteurs en rollen het platform moet dragen en welke koppelingen mogelijk zijn. Daaruit komt een schriftelijke offerte met alle aannames, vóórdat er gebouwd wordt. Je rekent af op wat er staat. Geen abonnement op een categorie, want elke storingsdienst is anders ingericht.
EIGHTY8