Running the Schedule Live: Real-Time Vehicle-to-Trip

The schedule issued at 6am was correct. By 9am a driver has called in sick, a vehicle is in the workshop, and a client has added two trips for the afternoon. From that point the real schedule lives in your planner's head and phone, and every fix depends on one person knowing the whole day by heart.

This is the fourth rung of the scheduling ladder: after vehicles are matched to trips and rosters are planned, the next step is keeping the plan true while the day changes.

In short: Running the schedule live means the day's plan updates when reality changes, instead of being rebuilt by phone. The system holds the current status of every trip, vehicle, and driver; when something breaks, it flags the conflict and proposes a re-assignment that respects the same rules the plan was built with (rest hours, licences, vehicle class). Your planner approves the change in seconds and every affected party is told automatically.

Why does the morning schedule fall apart by mid-day?

Because conditions keep changing after the schedule is issued. The usual causes:

• Driver no-shows and medical leave, discovered an hour before the shift.
• Vehicle breakdowns and workshop overruns, which take a bus out mid-rotation.
• Late-running trips, where one delay pushes the next two assignments.
• Ad-hoc jobs, the charter or extra trip a good customer asks for at 11am.

A plan built at 6am cannot know about a breakdown at 9am. The question is what happens next: a scramble over calls and chat groups, or a system that already knows which vehicle and driver can legally and practically take over.

What happens when re-assignment runs on phone calls?

Three costs, and they compound:

• The fix is slow. The planner has to reconstruct the day's state from memory before they can even start: who is where, who is free, and who has duty hours left.
• The fix creates the next problem. A swap made under pressure can quietly break a rest rule or leave the 3pm trip uncovered, which surfaces as a new problem two hours later.
• The key-person risk doubles. The person who built the plan is the only one who can repair it, so the operation cannot afford their day off. This is the same planner-dependency the scheduling pillar describes.

Your planner is usually very good at this. The problem is that the operation depends on that skill being available every minute of every day.

What does running the schedule live look like in practice?

Three levels, and most operators should start at the first:

• See: every trip, vehicle, and driver has a live status in one view, from a driver app or even simple check-ins. Anyone on the ops team can see the day, so the picture is no longer in one person's head.
• Flag: when a driver reports sick or a trip runs late, the system shows exactly which later assignments are affected, before they become surprises.
• Propose: the system suggests the re-assignment, drawn from who is genuinely available and legal for the trip, and the planner approves or overrides it. Routine swaps can eventually be automatic; judgement calls stay with the planner.

The planner stays central in this setup. They stop relaying every change by phone and spend their time on the decisions that genuinely need their judgement.

What changes when the schedule runs live?

	By phone	Live
Day's status lives in	The planner's head and chat groups	One shared view
A breakdown means	Reconstruct the day, then start calling	The affected trips are flagged at once
The fix checks rest rules	Checked by hand, under time pressure	Automatically, same rules as the plan
Who can handle it	Only the planner	Anyone on the ops team, planner approves
Planner's day off	A risk to the operation	A normal day

What do you need in place first?

Live re-assignment sits on top of the earlier rungs, and it inherits their data:

• Trips, vehicles, and drivers in a system rather than on paper or in a personal file (rung one and two).
• Rosters with rest rules and licence constraints encoded (rung three), because a live fix is only safe if it checks the same rules.
• A way for status to reach the system: a simple driver app, dispatcher updates, or GPS if you already have it. Full telematics is not a requirement to start.

If those are not in place yet, start there; the earlier posts in the ladder cover each step.

Is it worth it for your operation?

It is worth it when:

• You run enough vehicles that disruptions happen most days.
• Ad-hoc and charter work is a real share of revenue, so the day genuinely changes after 6am.
• One planner (or two) carries the whole day, and their absence is felt immediately.
• Late knock-on effects, one delay pushing three trips, show up in customer complaints.

It is not worth it when:

• Your routes are fixed and rarely disrupted; a solid static schedule already covers you.
• Trips and rosters are not yet digital. Live status on top of a paper plan has nothing to attach to.

What to do next

For the next two weeks, keep a simple tally:

• How many times per day the schedule had to change after it was issued.
• How many minutes each fix took, from problem known to everyone informed.
• Who made the fix, and what happened when that person was unavailable.

Those three numbers tell you what these disruptions currently cost, and they are the baseline any live-scheduling build has to beat.