Verhuur dispatchsoftware: zo plant u leveringen, chauffeurs en materieel

Eén stuk materieel van een depot naar één klant brengen is een opgelost probleem: kies een chauffeur, geef hem een adres, en hij vertrekt. Twaalf of twintig stuks materieel op dezelfde dag naar twaalf of twintig verschillende klanten brengen, sommige worden geleverd, sommige opgehaald, sommige al vastgelegd op een vast ochtendtijdslot, andere flexibel, is een heel ander probleem. Het is net zozeer een kwestie van volgorde als van planning: welke stops dicht bij elkaar liggen, welke chauffeur toch al die kant op gaat, en welke adressen daadwerkelijk haalbaar zijn, uitgezocht voordat een route is vastgesteld, in plaats van ontdekt nadat een bestelwagen is geladen en vertrokken.

Dat is het onderdeel van verhuurdispatch dat het minst aandacht krijgt. Er valt veel te zeggen over wat er gebeurt zodra een chauffeur vertrekt, van de chauffeursapp die hij onderweg gebruikt tot de leverervaring die een klant ziet terwijl hij wacht, en nog meer over het vastleggen van solide bewijs op het moment van overdracht. Dit artikel gaat over de stap daarvóór: het planscherm op kantoor, waar de rit van de dag daadwerkelijk wordt opgebouwd, voordat een chauffeur de werf verlaat. Als de rit slecht is opgebouwd, lost geen enkele gepolijste app en geen enkel overdrachtsbewijs op wat daarna volgt: een chauffeur die dezelfde postcode drie keer op een dag doorkruist, een stop waarvan niemand besefte dat hij buiten het servicegebied lag totdat de chauffeur er al voor geparkeerd stond, of het wekelijkse bezoek van een vaste klant dat vergeten wordt omdat niemand de rit heeft opgebouwd vanuit de lijst van vorige week.

Het startpunt voor de rit van de dag zouden de al bestaande boekingen moeten zijn, niet een nieuwe lijst die door wie die ochtend routes plant opnieuw wordt getypt. Een verhuurorder bevat al het leveradres, de artikelen die uitgaan of terugkomen, de contactpersoon ter plaatse en de betreffende data, omdat die informatie is vastgelegd toen de order werd opgenomen, niet verzonnen op het moment van dispatchen. Diezelfde gegevens opnieuw invoeren in een apart planningshulpmiddel is precies waar fouten insluipen: een omgewisseld cijfer in een postcode, een contactnummer dat van de verkeerde regel is overgenomen, een artikelaantal dat stilletjes afwijkt van wat daadwerkelijk is geoffreerd.

Bij Renttix worden leverings- en ophaaltaken rechtstreeks gepland op een dispatchbord, waarbij gegevens uit de order zelf komen in plaats van uit een parallel spreadsheet. Dat is belangrijker dan het klinkt: degene die de rit van de dag plant, werkt vanuit hetzelfde record waarin ook de order van de klant staat, dus een wijziging in een order, een aangepast aantal, een andere contactpersoon ter plaatse, een verzette datum, is precies de wijziging die op het bord verschijnt, in plaats van iets dat apart moet worden doorgegeven aan wie het routeplan beheert.

Zodra de taken van de dag bestaan, is de volgende stap ze zo ordenen dat een chauffeur ze daadwerkelijk in een zinnige volgorde kan afwerken. Dat is niets bijzonders: leveringen en ophalingen die dicht bij elkaar liggen in dezelfde route groeperen, in plaats van één chauffeur zigzaggend door de stad te sturen terwijl een tweede drie straten verderop rijdt, is een basaal, goed bekend principe van routeplanning. Het voordeel is eenvoudig: minder kilometers, minder verspilde minuten tussen stops, en een rit die een chauffeur in zijn hoofd kan houden in plaats van er stop voor stop doorheen gedicteerd te worden door een navigatiesysteem dat geen idee heeft wat er hierna komt.

Op het dispatchbord worden taken per route gegroepeerd en rechtstreeks aan chauffeurs toegewezen, zodat degene die de dag plant de hele vorm van een rit kan zien terwijl die wordt opgebouwd: welke stops bij elkaar horen, welke chauffeur al een rustige dag heeft en er nog eentje bij kan nemen, en welke taken nog aan niemand zijn toegewezen. Dit beeld opbouwen op het dispatchbord, in plaats van te jongleren met een uitgeprinte lijst en een aparte kaart, maakt van de rit één plan, geen meerdere documenten die allemaal met elkaar moeten kloppen tegen de tijd dat de chauffeurs vertrekken.

Een van de meest vermijdbare problemen in de dispatchplanning is een adres dat om te beginnen nooit geaccepteerd had moeten worden. Een telefonisch opgenomen boeking, of een oud klantadres dat wordt hergebruikt voor een nieuwe order, kan buiten het gebied liggen dat een depot realistisch kan bedienen, en het eerste dat iemand hiervan merkt is wanneer een chauffeur veertig minuten na zijn geplande tijdslot voor een hek geparkeerd staat, aan de telefoon met kantoor om te vragen wat hij moet doen.

Renttix pakt dit aan in de planningsfase, niet onderweg. Elk depot heeft een servicegebied dat is gedefinieerd als een polygoon op een kaart, en leveradressen worden hiertegen gecontroleerd. Een order geplaatst via een gekoppelde webshop wordt vóór het afrekenen geblokkeerd als het adres buiten de dekking van het betreffende depot valt, zodat de boeking om te beginnen nooit wordt geaccepteerd. Voor orders die op een andere manier op het bord terechtkomen, geldt dezelfde controle wanneer de dag wordt gepland: een stop buiten het servicegebied van een depot wordt op het dispatchbord gemarkeerd als buiten gebied terwijl de rit nog wordt opgebouwd, niet nadat een bestelwagen het depot heeft verlaten. Dat is het verschil dat ertoe doet: het gesprek over of een taak realistisch is, vindt plaats op het planscherm, met tijd om die aan het juiste depot toe te wijzen of bij de klant na te vragen, in plaats van op de mobiele telefoon van iemand die langs de weg geparkeerd staat.

Een groot deel van de verhuurbusiness is herhaalbusiness: dezelfde klant die elke week op dezelfde dag dezelfde artikelen afneemt, of een contract dat maanden loopt met leveringen en ophalingen op vaste intervallen. Elke dag een rit vanaf een blanco vel plannen, zelfs voor klanten wier patroon nooit verandert, is verspilde moeite, en het is ook een betrouwbaarheidsrisico. Als het opbouwen van de rit van morgen ervan afhangt dat iemand zich herinnert dat een bepaalde klant zijn wekelijkse bezoek verwacht, zal vroeg of laat iemand het vergeten.

Terugkerende schema's lossen dit op door zelf de dispatchtaken te genereren. Het patroon wordt eenmalig ingesteld, en vanaf dat moment verschijnen de betreffende leveringen en ophalingen automatisch op de juiste dagen op het bord, al voorzien van hun vaste route. Een depot dat de volgende week plant, begint niet bij nul; de terugkerende bezoeken staan al op de betreffende dagen, en het echte planningswerk bestaat eruit de nieuwe of eenmalige taken in te passen rond het schema dat er al staat.

Een verwant maar apart geval is een verhuur die een eigen doorlopende servicecomponent bevat, in plaats van één levering met uiteindelijk een ophaling. Een portable toilet in een langlopende verhuur die elke week onderhoud nodig heeft, is het duidelijkste voorbeeld: de unit gaat één keer de deur uit, maar een chauffeur moet gedurende de hele looptijd van de verhuur op een vaste cyclus terugkomen op locatie, en elk van die bezoeken is een eigen taak met een eigen registratie dat het heeft plaatsgevonden.

Een servicelijn toevoegen aan een order handelt dit rechtstreeks af: Renttix genereert vanaf dat moment het bezoekschema voor de hele looptijd van de verhuur, en elk bezoek wordt gevolgd door zijn eigen levenscyclus, van gepland, via voltooid, tot gereed voor facturatie. Die laatste stap is voor de planning net zo belangrijk als voor de facturatie: een voltooid bezoek dat op gereed voor facturatie staat, is een zichtbaar signaal dat de taak heeft plaatsgevonden en correct is afgesloten, in plaats van iets dat aan het einde van de maand apart moet worden nagejaagd.

De rit goed plannen is de helft van het werk; weten hoe het daadwerkelijk verloopt zodra chauffeurs onderweg zijn, is de andere helft. Zodra een taak is toegewezen en een chauffeur ermee bezig is, is de status in real time zichtbaar voor kantoor. Een taak die loopt, on hold staat of voltooid is, verschijnt op hetzelfde bord waarop hij is gepland, in plaats van pas bekend te worden wanneer de chauffeur aan het einde van de dag terugkeert naar het depot.

Voor een planner is dat het verschil tussen reageren op een probleem terwijl er nog tijd is om er iets aan te doen, en het achteraf ontdekken. Als een taak verderop op een route vertraging gaat oplopen omdat een eerdere stop langer duurde dan verwacht, is dat zichtbaar terwijl de rest van de dag nog kan worden aangepast. De eigen ervaring van de chauffeur met de taak, het vastleggen van handtekeningen, foto's en de rest, is een onderwerp dat een eigen artikel verdient; vanuit het oogpunt van planning gaat het erom dat het dispatchbord en de chauffeursapp dezelfde onderliggende taak uitlezen, geen twee aparte systemen die handmatig moeten worden afgestemd.

Neem, ter illustratie, een depot dat de leveringen en ophalingen van de volgende dag plant over een gemengde rit: een handvol nieuwe eenmalige orders die die week zijn binnengekomen, meerdere langlopende verhuren met een wekelijks servicebezoek dat verschuldigd is, en twee ophalingen voor verhuren die eindigen. Niets daarvan hoeft uit aparte lijsten te worden samengesteld. De eenmalige orders staan op het bord omdat ze om te beginnen als orders zijn geboekt; de wekelijkse servicebezoeken staan er al omdat ze door hun servicelijnen zijn gegenereerd; en de ophalingen staan op het bord omdat de einddatum van hun verhuur ze heeft geactiveerd. Het eigenlijke werk van de planner die ochtend bestaat eruit elk adres dat als buiten gebied is gemarkeerd te controleren, de resterende stops te groeperen in zinnige routes per gebied, en ze toe te wijzen aan de chauffeurs die dienst hebben, niet uit het opnieuw bedenken van een rit die grotendeels al klaarstond, wachtend om georganiseerd te worden.

Dat is precies het argument om dispatchplanning te behandelen als een discipline op zich, apart van zowel de chauffeursapp als het leverregistratie: het is de fase waarin een dag ofwel een goed gesequencet, realistisch plan wordt, ofwel een lijst goede voornemens die halverwege de ochtend uiteenvalt. Als u wilt zien hoe zo'n gemengde rit eruit zou zien op uw eigen dispatchbord, met uw eigen depots, servicegebieden en vaste klanten, boek dan een demo en we lopen het samen door.