Dispatchsystem för uthyrning: så planerar du leveranser, förare och utrustning

Att få en enskild utrustning från en depå till en kund är ett löst problem: välj en förare, ge dem en adress, och de kör iväg. Att få tolv eller tjugo utrustningar till tolv eller tjugo olika kunder samma dag, vissa ska levereras, andra hämtas, vissa redan bundna till ett fast förmiddagsfönster, andra flexibla, är ett helt annat problem. Det är lika mycket en sekvenseringsövning som en schemaläggningsövning: vilka stopp ligger nära varandra, vilken förare är redan på väg åt det hållet, och vilka adresser är faktiskt nåbara, klarlagt innan en rutt är fastställd, i stället för upptäckt efter att en skåpbil redan är lastad och iväg.

Det är den delen av uthyrningsdispatch som får minst uppmärksamhet. Det finns mycket att säga om vad som händer när en förare väl har kört iväg, från förarappen de använder på vägen till den leveransupplevelse en kund ser medan de väntar, och ännu mer om att fånga solida bevis vid överlämningen. Den här artikeln handlar om steget innan allt det: planeringsskärmen på kontoret, där dagens runda faktiskt byggs upp, innan en förare lämnar depån. Om rundan är dåligt byggd hjälper ingen polerad app eller överlämningsbevis mot det som följer: en förare som korsar samma postnummer tre gånger på en dag, ett stopp som ingen insåg låg utanför serviceområdet förrän de stod parkerade utanför det, eller en stamkunds veckovisit som glöms bort eftersom ingen byggde om rundan utifrån förra veckans lista.

Startpunkten för dagens runda bör vara de bokningar som redan finns, inte en ny lista skriven av den som planerar rutter den morgonen. En uthyrningsorder innehåller redan leveransadressen, artiklarna som ska ut eller in, kontaktpersonen på plats och de aktuella datumen, eftersom den informationen fångades när ordern togs emot, inte hittades på vid dispatchtillfället. Att skriva in något av det igen i ett separat planeringsverktyg är precis där misstag smyger sig in: en omkastad siffra i ett postnummer, ett kontaktnummer kopierat från fel rad, ett artikelantal som tyst glider ifrån vad som faktiskt offererades.

I Renttix planeras leverans- och hämtningsjobb direkt på en dispatchtavla, hämtat från själva ordern i stället för ett parallellt kalkylblad. Det spelar större roll än det låter: personen som planerar dagens runda arbetar utifrån samma post som kundens order finns i, så en ändring gjord i en order, en justerad kvantitet, en annan platskontakt, ett omschemalagt datum, är exakt den ändring som visas på tavlan, i stället för något som måste vidarebefordras separat till den som äger ruttplanen.

När dagens jobb väl finns är nästa steg att ordna dem till något en förare faktiskt kan ta sig igenom i en vettig ordning. Det här är inget exotiskt: att gruppera leveranser och hämtningar som ligger nära varandra i samma rutt, i stället för att skicka en förare i sicksack genom staden medan en andra täcker tre gator bort, är en grundläggande, välkänd princip inom ruttplanering. Nyttan är enkel: färre mil, färre bortkastade minuter mellan stopp, och en runda en förare kan hålla i huvudet i stället för en som dikteras stopp för stopp av en GPS utan aning om vad som kommer härnäst.

På dispatchtavlan grupperas jobb efter rutt och tilldelas förare direkt, så personen som planerar dagen kan se hela formen av en runda medan den byggs: vilka stopp hör ihop, vilken förare redan har en lätt dag och kan ta ett till, och vilka jobb ännu inte tilldelats någon. Att bygga den bilden på dispatchtavlan, i stället för att jonglera mellan en utskriven lista och en separat karta, gör rundan till en enda plan, inte flera dokument som alla måste stämma överens innan förarna åker iväg.

Ett av de mest undvikbara problemen i dispatchplanering är en adress som aldrig borde ha accepterats från början. En bokning som tagits emot per telefon, eller en gammal kundadress som återanvänts för en ny order, kan ligga utanför det område en depå realistiskt kan betjäna, och det första någon får veta om det är när en förare står parkerad utanför en grind, fyrtio minuter efter sitt planerade tidsfönster, i telefon med kontoret och frågar vad de ska göra.

Renttix hanterar det här i planeringsfasen, inte ute på vägen. Varje depå har ett serviceområde definierat som en polygon ritad på en karta, och leveransadresser kontrolleras mot det. En order som läggs via en ansluten webbutik spärras före kassan om adressen faller utanför den relevanta depåns täckning, så bokningen accepteras aldrig från början. För order som når tavlan på annat sätt gäller samma kontroll när dagen planeras: ett stopp utanför en depås serviceområde flaggas som utanför området på dispatchtavlan medan rundan fortfarande byggs, inte efter att en skåpbil har lämnat depån. Det är skillnaden som spelar roll: samtalet om huruvida ett jobb är realistiskt sker på planeringsskärmen, med tid att omfördela det till rätt depå eller fråga kunden, i stället för i mobilen hos någon som står parkerad på vägrenen.

En stor del av uthyrningsverksamheten är återkommande affärer: samma kund som tar samma artiklar samma dag varje vecka, eller ett kontrakt som löper i månader med leveranser och hämtningar med fasta intervall. Att planera en runda från ett tomt blad varje enskild dag, även för kunder vars mönster aldrig ändras, är bortkastad möda, och det är också en tillförlitlighetsrisk. Om att bygga morgondagens runda beror på att någon kommer ihåg att en viss kund har sitt veckovisit att vänta, kommer förr eller senare någon att glömma.

Återkommande scheman löser det genom att själva generera dispatchjobben. Mönstret ställs in en gång, och därefter dyker de aktuella leveranserna och hämtningarna upp på tavlan automatiskt rätt dagar, redan stämplade med sin hemmarutt. En depå som planerar nästa vecka börjar inte från noll; de återkommande besöken ligger redan på de aktuella dagarna, och det egentliga planeringsarbetet handlar om att passa in de nya eller enstaka jobben och anpassa dem kring schemat som redan finns.

Ett relaterat men separat fall är en uthyrning som innehåller sin egen löpande servicekomponent, i stället för en engångsleverans med en eventuell hämtning. En bärbar toalett i en lång uthyrning som behöver service varje vecka är det tydligaste exemplet: enheten går ut en gång, men en förare måste tillbaka till platsen enligt en fast cykel så länge uthyrningen pågår, och varje sådant besök är ett eget jobb med sin egen registrering av att det ägde rum.

Att lägga till en servicerad på en order hanterar det här direkt: Renttix genererar då besöksschemat för hela uthyrningens löptid, och varje besök spåras genom sin egen livscykel, från schemalagt, via slutfört, till klart för fakturering. Det sista steget spelar lika stor roll för planeringen som för faktureringen: ett slutfört besök som ligger i klart för fakturering är en synlig signal att jobbet ägde rum och avslutades korrekt, i stället för något som måste jagas ikapp separat i slutet av månaden.

Att planera rundan väl är halva jobbet; att veta hur det faktiskt går när förarna väl är ute är den andra halvan. När ett jobb väl har tilldelats och en förare arbetar med det, är statusen synlig för kontoret i realtid. Ett jobb som pågår, är pausat eller är slutfört visas på samma tavla där det planerades, i stället för att bara bli känt när föraren är tillbaka på depån vid dagens slut.

För en dispatcher är det skillnaden mellan att reagera på ett problem medan det fortfarande finns tid att göra något åt det, och att få veta det i efterhand. Om ett jobb längre fram på en rutt kommer att bli försenat för att ett tidigare stopp drog ut på tiden, syns det medan resten av dagen fortfarande kan justeras. Förarens egen upplevelse av jobbet, att fånga signaturer, foton och resten, är ett ämne som förtjänar sin egen artikel; från planeringssidan är det som spelar roll att dispatchtavlan och förarappen läser samma underliggande jobb, inte två separata system som måste stämmas av för hand.

Ta, som ett exempel, en depå som planerar nästa dags leveranser och hämtningar över en blandad runda: en handfull nya engångsorder som kommit in den veckan, flera långvariga uthyrningar med veckans servicebesök förfallet, och två hämtningar för uthyrningar som avslutas. Inget av det behöver sammanställas från separata listor. Engångsorden ligger på tavlan eftersom de bokades som order från början; veckans servicebesök finns redan där eftersom de genererades av sina servicerader; och hämtningarna ligger på tavlan eftersom deras uthyrnings slutdatum utlöste dem. Planerarens egentliga jobb den morgonen är att kontrollera alla adresser flaggade som utanför området, gruppera de återstående stoppen i vettiga rutter efter område, och tilldela dem till förarna i tjänst, inte att uppfinna en runda på nytt som till stor del redan låg där och väntade på att organiseras.

Det är egentligen argumentet för att behandla dispatchplanering som en egen disciplin, skild från både förarappen och leveransregistret: det är stadiet där en dag antingen blir en väl sekvenserad, realistisk plan, eller en lista med goda föresatser som faller isär vid förmiddagens mitt. Om du vill se hur en blandad runda som denna skulle se ut på din egen dispatchtavla, med dina egna depåer, serviceområden och stamkunder, boka en demo så går vi igenom det tillsammans.