
Loopt een bezoek uit, meldt een chauffeur zich ziek of komt er een dringende opdracht binnen, dan draait de engine een korte herstelsolve vanaf het huidige tijdstip. Afgewerkt en lopend werk blijft vastliggen, de rest van de dag wordt in seconden herpland, en technici zien het aangepaste plan op hun telefoon.
Een no show, een uitgelopen bezoek, een dringende boeking of een ziektemelding: elk van die events start een herstelsolve vanaf het huidige tijdstip. De feed toont wat er veranderde: bezoeken toegevoegd, herverdeeld, verschoven of geschrapt.
Alles vóór het huidige tijdstip ligt vast: afgewerkte bezoeken en de opdracht waar een chauffeur al naar onderweg is. Een nieuwe solve wijzigt alleen wat nog open staat.
Technici melden een opdracht af, verlengen die met 30 of 60 minuten, geven aan dat een klant niet thuis is, of geven een opdracht door aan een collega. De shift van een zieke chauffeur beëindigen is een dispatchactie; de resterende bezoeken worden bij anderen ingepland.
Zoek op een adres of voeg een dringende opdracht toe en krijg een gerangschikte lijst met slots, elk met de extra rijtijd, de overuren en de bezoeken die verschuiven. Onhaalbare slots vermelden de reden: een ontbrekende skill, een volle shift, een gesloten tijdvenster.
De solver stelt een plan voor; de planner kan elk onderdeel ervan aanpassen. Bezoeken kun je naar een andere technicus of een ander tijdstip slepen, en afspraken die al vastliggen voer je in als vast. De solver plant rond die beslissingen.
Een bezoek kun je naar een andere technicus of een ander tijdstip slepen. De verplaatsing wordt vastgepind, de route hertimet zich errond, en latere solves laten het bezoek staan waar het gezet is.
Bezoeken met een afgesproken tijdslot of een verplichte technicus voer je in als vast. De solver plant de overige bezoeken errond.
Een enkel bezoek, het eerste deel van een shift of een volledige route kun je vastpinnen. Vastgepind werk blijft ongewijzigd; de rest wordt bij elke solve geoptimaliseerd.
De solver stelt een plan voor; de planner aanvaardt het of past een onderdeel aan en laat de rest opnieuw oplossen.
Skills, tijdvensters, pauzes, shifts en prioriteiten. Een plan dat een harde regel schendt, wordt nooit voorgesteld.
Bezoeken kunnen skills op een minimumniveau en verplichte certificaten vereisen. Snellere technici zijn vroeger klaar, en de engine vermijdt een expert op routinewerk te zetten.
Harde vensters (met optioneel een tweede venster), een zacht voorkeursvenster, een laatste starttijd en contractuele SLA-deadlines worden allemaal gerespecteerd. SLA-bezoeken kunnen vroeger in hun venster worden ingepland.
Een vlottende lunch wordt binnen zijn toegelaten venster geplaatst; vaste afspraken zijn onverplaatsbare blokken. Werk overlapt nooit met een pauze.
Start en einde van de shift, een overurenbeleid dat overuren ontmoedigt binnen een marge of ronduit verbiedt, een plafond op bezoeken en rijtijd per shift, en een dekkingsradius rond elke thuisbasis.
Opdrachten dragen een prioriteit; sommige zijn verplicht, andere mogen wachten. Een bezoek kan afhangen van een ander dat eerst klaar moet zijn binnen een wachtvenster, en opdrachten met meerdere technici lopen op verschillende mensen, starten samen, alles of niets.
Rijtijd, wachttijd, overuren, kosten, eerlijkheid, SLA en winst zijn aparte gewogen doelstellingen. De gewichten bepalen welke afwegingen het plan maakt.
Werknemers hebben een dagtarief plus overuren; onderaannemers een activatiekost plus een uurtarief over hun werktijd. Een lege route kost niets, dus het plan weegt het eurobedrag mee, niet alleen de kilometers.
Optionele bezoeken dragen een winst. Een hoger gewicht haalt er meer van binnen als de omweg de moeite loont; een lager gewicht beschermt de kernroute. Verplicht werk wordt nooit geschrapt.
Een eerlijkheidsgewicht verdeelt de werktijd gelijkmatig over de technici. Hoger voor een gelijke dag, lager als efficiëntie zwaarder weegt.
Rijtijd, wachttijd, overuren, kosten, eerlijkheid, SLA en winst hebben elk een gewicht, per solve in te stellen. Dezelfde dag kan onder andere prioriteiten opnieuw worden opgelost zonder de data aan te passen.
De regels hierboven zijn de standaardset. Regels eigen aan jouw operatie worden aan het model toegevoegd als harde of zachte regels met een eigen gewicht. De solver behandelt ze zoals de ingebouwde: harde regels worden nooit geschonden, zachte regels worden afgewogen tegen de rest.
Een eigen regel is ofwel absoluut ofwel een gewogen voorkeur. Absolute regels worden nooit geschonden; voorkeuren dragen een gewicht dat je per solve instelt.
Eigen regels worden tijdens het zoeken op elk kandidaat-plan geëvalueerd, niet achteraf gecontroleerd. Een plan dat er een schendt, wordt nooit voorgesteld.
Elke regel rapporteert zijn eigen bijdrage, zodat je ziet wat hij het plan kost, zijn gewicht bijstelt of hem uitschakelt.
Je beschrijft de regel zoals je planners hem formuleren; hij wordt een benoemde regel in het model.