--- title: "Delivery Route Reassignment With AI Agents | Kylon" description: "How a delivery depot reassigns stops after driver callouts, checks the load manifest and rebalances for van, zone and cancellation changes, with dispatch approving." url: "https://kylon.io/use-cases/route-reassignment" language: "en" --- [HOME](https://kylon.io/)\>[Use Cases](https://kylon.io/use-cases)\>Route Reassignment: Sick-Day Stops Covered Without Overloading a Van Use Case7 min read # Route Reassignment: Sick-Day Stops Covered Without Overloading a Van When two drivers call out, their stops are reassigned under the route policy in one Kylon room, then rebalanced as vans, zones and cancellations change through the day. Agents plan and check, and the dispatch lead approves every move before a driver sees it. [Get started](https://app.kylon.io/sign-up) Kylon TeamProduct November 6, 2026 ## Two callouts at dawn and thirty stops without a driver A delivery depot builds its routes the night before. Then two drivers call out sick at six, and their stops need new drivers before the vans load. The route policy sets the rules: drivers stay inside their zones, each van has a limit in stops and cubic space, promised delivery windows hold where they can, and no route runs past the end of a shift. Stops, drivers and vans sit in an Airtable base, drive times come from Google Maps, the route policy and zone map are documents in Google Drive, and drivers post from the road in Slack. The load planner builds the manifest from whatever the plan said at half past six. By mid-morning a smaller van, a returning driver and a handful of cancellations have changed the picture, and the manifest still shows the first plan. ## Who works in the room People - Dispatch lead Approves every reassignment and rebalance before a driver is told - Load planner Builds the loading manifest from the approved plan and corrects it after the check - Fleet coordinator Reports van swaps and capacity changes and confirms which vans are on the road - Customer service lead Sends changed delivery windows to customers and logs cancellations Agents - FinDispatch planner Reassigns open stops by zone, delivery window and van capacity using drive times from Google Maps, and rebalances the zone when anything changes AirtableGoogle MapsGoogle Calendar - MycoManifest checker Compares the loading manifest with the approved plan stop by stop and lists every stop that is missing, doubled or on the wrong van Google DriveAirtable - NovaDriver and customer notices Drafts changed delivery windows for customers and posts approved route changes to drivers [Gmail](https://kylon.io/integrations/gmail) [Slack](https://kylon.io/integrations/slack) Each depot has its own Kylon room. Messages about stops, drivers or capacity go to Fin, the room's default agent. The manifest is Myco's work, so a question about what is on which van reaches Myco even when nobody names it. Once a change is approved, Fin opens a thread for Nova whose first message lists the stops that moved and the customers affected, and Nova drafts the notices from there. ## From the first callout to the end of the day The route policy is linked from the room guidelines, so every agent works from the same zone map and capacity table. Every stage stops at the dispatch lead before a driver or customer hears anything. ```mermaid flowchart TD callout([Drivers call out sick]) reassign["Fin reassigns each open stop by
zone, window and van capacity"] ok1["Dispatch lead approves the routes"] manifest["Myco compares the manifest with
the approved plan, stop by stop"] fix["Load planner corrects it,
dispatch lead confirms"] van["Fin rebalances the whole
zone for a smaller van"] noon["Fin gives a returning driver
only stops after the shift begins"] vanok["Fleet coordinator confirms,
dispatch lead approves"] handover["Dispatch lead
approves the handover"] zone["Fin reassigns stops that change
zone and removes canceled stops"] notices["Nova drafts the customer notices"] send["Dispatch lead approves routes,
customer service sends notices"] tally["Myco tallies stops per driver
and zone from current records"] sign["Dispatch lead signs off the day"] callout --> reassign --> ok1 --> manifest --> fix fix --> van & noon van --> vanok noon --> handover vanok & handover --> zone --> notices --> send --> tally --> sign class reassign,manifest,van,noon,zone,notices,tally agent class ok1,fix,vanok,handover,send,sign person class callout event classDef agent fill:#FFFFFF,stroke:#DCD3C8,color:#1B1712 classDef person fill:#EEF0E3,stroke:#6E7447,color:#1B1712 classDef event fill:#F4ECDD,stroke:#F4ECDD,color:#564C42 ``` | Stage | What happens | Who acts | Who decides | | --- | --- | --- | --- | | Reassignment | Each stop from the absent drivers goes to an in-zone driver with van space and time inside the delivery window | Fin, with drive times from Google Maps | The dispatch lead approves before routes are published | | Manifest check | The load planner's manifest is compared stop by stop with the approved plan | Myco | The load planner corrects it and the dispatch lead confirms | | Van capacity cut | A smaller replacement van triggers a rebalance across the zone, not only on that van | Fin | The fleet coordinator confirms the van and the dispatch lead approves | | Returning driver | A driver who starts at noon picks up only stops whose windows open after the shift begins | Fin | The dispatch lead approves the handover | | Zone fix and cancellations | Stops that change zone are reassigned, and canceled stops come off counts and capacity | Fin, then Nova for notices | The dispatch lead approves routes and customer service sends notices | | End of day | Stops per driver and per zone are tallied from the current records | Myco | The dispatch lead signs off the day | Stages of one callout day at one depot. Drivers, stops and van sizes in this example are illustrative. ## When the morning plan stops being true Changes arrive as messages. The fleet coordinator writes that van 7 is in the shop and the spare holds fewer stops. A driver messages that she can be in by noon. The zone owner posts a corrected boundary that moves two streets into the next zone. Fin treats each message as the source for that change and re-runs the plan with all of them in force, so the noon start and the smaller van both still apply when the zone fix lands. A capacity cut is where partial fixes fail. Pushing the overflow from one van onto its neighbors can overload a neighbor or push a stop out of its window. Fin rebalances the zone as a whole and shows the dispatch lead each stop that moved and why. Google Calendar gets a new event for each approved route block, and the Airtable records stay the plan everyone reads from. ## What the checks catch - A morning stop offered to the returning driver, whose shift does not start until noon - A street that moved zones under the corrected boundary but kept its old driver - A canceled stop still counted against a van, which hides space another stop needs - A rebalance that clears one overloaded van by overloading the next - A manifest that loads one stop on two vans while another stop appears on none ## What stays with people - Approving each reassignment and rebalance before drivers are told - Choosing which promised window gives way when no plan can keep them all - Sending every customer notice, which Nova prepares as a draft - Signing off the end-of-day tally ## Integrations in this workflow Kylon is not a routing or telematics system and it does not replace either. It works across the depot's existing tools and keeps the coordination between them in one place. - Airtable - [Gmail](https://kylon.io/integrations/gmail) - Google Calendar - Google Drive - Google Maps - [Slack](https://kylon.io/integrations/slack) - **Airtable** holds the stops, drivers, vans and the day's assignments - **Google Maps** supplies drive times between stops and locates each address for the zone check - **Google Calendar** gets one event per approved route block, created after the dispatch lead approves - **Google Drive** keeps the route policy, the zone map and the load planner's manifest - **Gmail** sends changed windows to customers through drafts a person sends - **Slack** is the drivers' channel, where callouts arrive and approved route changes are posted ## Where to start Start with one depot and one callout morning. Connect the Airtable base with stops and vans, let Fin use Google Maps for drive times, and put one rule in the room guidelines: any change to capacity, zones or staffing re-runs the whole zone, and nothing reaches a driver until the dispatch lead approves. ## Set it up with your agent Open a new Room, add your agent and paste this prompt. It connects the tools, builds the App with you and asks for your rules one step at a time, and nothing goes out until a person approves it. Set-up prompt Set up our sick-day route reassignment desk in this Room. Take it one step at a time and wait for my OK before you move on. 1. Connect Airtable, Gmail, Google Calendar, Google Drive, Google Maps and Slack. Tell me which ones still need connecting. 2. Ask me who works this desk: the dispatch lead, the load planner, the fleet coordinator and the customer service lead. Help me invite them to this Room. 3. Build a Route Board App with columns Unassigned, Proposed, Approved and Loaded. Pull today's stops, drivers and vans from Airtable so each stop has one record. 4. For each unassigned stop, check the driver's zone, van capacity and delivery window using drive times from Google Maps. When a van swap, returning driver or zone correction changes the picture, rebalance the whole zone and show every stop that moved and why. 5. Compare the load planner's manifest in Google Drive against the approved plan stop by stop. List every stop that is missing, doubled or on the wrong van. Hold all corrections until the load planner fixes the manifest and the dispatch lead confirms. 6. Hold every reassignment and rebalance until the dispatch lead approves. Hold every customer notice until the customer service lead sends the draft. 7. Write our rule that any change to capacity, zones or staffing re-runs the whole zone into this Room's guideline, so every agent reads from the same route policy and zone map. 8. After one clean callout morning, offer to turn the reassignment check into an Automation. Before you start, ask me for our rules one at a time. [Get started](https://app.kylon.io/sign-up) Your first company harness. Where humans and agents run your business together. [Get started](https://app.kylon.io/sign-up) ## More Use Cases [View all](https://kylon.io/use-cases) [ ### Backorder Communications: Customers Hear the Latest Date, Not Last Week's Customers hear the latest supplier date, an approved substitute or a cancellation offer, line by line. Agents work Pipedrive lines against Outlook notices and the Notion substitution table in one Kylon room, and every notice is a draft a rep sends. Logistics & supply chainEmail operationsSupport & customer success ](https://kylon.io/use-cases/backorder-communications)[ ### Carrier Damage Claims: Filings That Match the Tariff and the Paperwork Thirty freight damage claims, the filing manifest, carrier acceptances, a disputed delivery receipt and a tariff revision run through one Kylon room. Agents read ClickUp and the Dropbox claim packets, and the claims manager approves every change. Logistics & supply chainFinance operationsSupport & customer success ](https://kylon.io/use-cases/carrier-damage-claims)