Een temperatuuralarm om 03.00 uur is nog geen afgehandeld incident. Pas wanneer locatie, installatie, melding en contactroute bij elkaar komen, kan de juiste wachtdienst gericht reageren.
TeleDispatch meet de temperatuur niet zelf en stelt geen technische diagnose. We verwerken het signaal dat een installatie, monitoringplatform of beller aanlevert en voeren de opvolging uit die de klant vooraf heeft vastgelegd.
Een alarm is nog geen opvolging
Een automatisch bericht kan kort zijn: een locatiecode, alarmtype, meetwaarde of foutmelding. Voor een technicus is dat pas bruikbaar wanneer duidelijk is bij welke site en koelzone het hoort, wanneer het ontstond en welke actie volgens de afspraken nodig is.
Daarom vertalen we een aangeleverd signaal niet op eigen initiatief naar een technische conclusie. We koppelen het aan het installatieregister en de procedure van de klant, vullen alleen de voorgeschreven context aan en starten de bijbehorende contactcascade.
Welke gegevens maken het signaal bruikbaar?
De precieze intake verschilt per installatiepark. Deze gegevens vormen vaak het praktische vertrekpunt:
- Locatie: klant, site, adres en een bereikbare contactpersoon ter plaatse.
- Installatie: installatie-ID, koelzone, cel of proces waarop de melding betrekking heeft.
- Bron en tijdstip: bijvoorbeeld monitoringplatform, SMS, e-mail, API of telefonische melding.
- Alarmtype: de omschrijving die het systeem of de melder werkelijk doorgeeft.
- Gemelde waarde of foutcode: letterlijk geregistreerd, zonder die als diagnose te presenteren.
- Status: eerste melding, herhaling, herstelbericht of communicatieverlies.
- Operationele context: alleen wat de procedure vraagt en een bevoegde melder feitelijk kan bevestigen.
Een vaste veldstructuur voorkomt dat installatie-ID, waarde en tijdstip in vrije tekst verdwijnen. De wachttechnicus ontvangt daardoor dezelfde kerninformatie, ongeacht het kanaal waarlangs het alarm binnenkwam.
De klant bepaalt grenswaarde, prioriteit en actie
Welke temperatuur aanvaardbaar is, wanneer een herhaalmelding urgent wordt en wie buiten kantooruren bereikbaar moet zijn, zijn beslissingen van de klant en diens technische verantwoordelijken. TeleDispatch legt die regels vóór de ingebruikname vast in een beslisboom.
Per alarmtype kan de instructie bijvoorbeeld bepalen dat we alleen registreren, eerst een aangewezen contactpersoon bellen of meteen de wachtdienst en een vervanger activeren. Zo hoeft een operator ’s nachts geen technische urgentie te improviseren.
Automatisch signaal en telefoongesprek vullen elkaar aan
Een systeemsignaal kan consequent een installatie-ID, meetwaarde en foutcode doorgeven. Een medewerker ter plaatse kan dan weer bevestigen welke zone bedoeld wordt of wie toegang kan verlenen. Wanneer beide kanalen betrouwbaar beschikbaar zijn, kan die informatie binnen dezelfde afgesproken incidentroute samenkomen.
De keuze van het kanaal blijft praktisch. In SMS, e-mail of API: welk meldkanaal past bij welke storing? vergelijken we hoeveel context, automatisering en fallback ieder kanaal kan bieden.
Van contactcascade naar bevestigde aanname
Na de intake contacteren we de technicus, regiopartner of verantwoordelijke die volgens planning, site en installatietype klaarstaat. Neemt de eerste persoon niet op, dan vervolgt de operator de vastgelegde fallback. Pogingen, antwoorden en status worden geregistreerd.
Een bevestigde aanname betekent dat de afgesproken partij de melding heeft ontvangen en aanvaard. Het is geen belofte dat de technicus op een bepaald tijdstip arriveert of dat de installatie kan worden hersteld. Alleen bevestigde informatie wordt teruggekoppeld aan de personen die de klant daarvoor heeft aangeduid.
Fictief voorbeeld: alarm in koelzone B
Om 03.00 uur levert een monitoringplatform een alarm aan voor koelzone B van een bepaalde site. Het bericht bevat een installatie-ID, tijdstip, gemelde meetwaarde en alarmcode. TeleDispatch koppelt het signaal aan de vooraf goedgekeurde instructie en controleert of de verplichte velden aanwezig zijn.
De operator belt vervolgens de geplande wachttechnicus. Wanneer die niet antwoordt binnen de afgesproken route, wordt de vervanger gecontacteerd. Zodra iemand de taak bevestigt, registreert TeleDispatch die aanname en verstuurt de afgesproken statusmelding. Dit fictieve voorbeeld beschrijft de informatiestroom; diagnose en herstelling blijven bij de bevoegde specialist.
Wat TeleDispatch wel en niet doet
- Wel: aangeleverde alarmen ontvangen, herkennen, registreren en volgens instructie routeren.
- Wel: ontbrekende, vooraf bepaalde context opvragen wanneer een bevoegde melder bereikbaar is.
- Wel: de contactcascade uitvoeren en bevestigde statussen rapporteren.
- Niet: zelf continu temperaturen meten of de werking van sensoren garanderen.
- Niet: een technische diagnose stellen, een installatie bedienen of een herstelling beloven.
- Niet: buiten de goedgekeurde beslisboom zelf grenswaarden of urgentie bepalen.
Leg de vervolgroute vooraf vast
Een permanentie werkt het best wanneer de belangrijkste keuzes al gemaakt zijn vóór het eerste nachtelijke alarm:
- Sites, koelzones en installatie-ID’s in een actueel register.
- Alarmtypes, grenswaarden en prioriteiten zoals door de klant bepaald.
- Wachtdienst, vervangers, tijdvensters en contactkanalen.
- Welke informatie ter plaatse mag worden opgevraagd.
- Wie welke status ontvangt en wanneer een incident administratief wordt afgesloten.
- Welke alternatieve route geldt wanneer een kanaal of contactpersoon uitvalt.
Meer over geteste instructies, fallback en rapportage leest u op kwaliteit en continuïteit.
Van nachtelijk signaal naar gerichte vervolgactie
De waarde van alarmopvang zit niet in het ontvangen van nog een bericht, maar in een controleerbare route naar de juiste persoon. Met een actueel installatieregister en duidelijke instructies wordt een kort signaal een bruikbaar incident voor de wachtdienst.
Bekijk hoe TeleDispatch alarmopvang en storingsdispatching voor koeltechniek en koudeketens combineert.