Logistics scheduling software holds the forward view: what you have committed to over the coming days and weeks, what capacity exists to serve it, where the two do not reconcile, and whether the commitments you made were met. With Pentoggle, an operator can describe how work is committed and resourced and generate the starting application around it.
This page is about the forward view. What happens on the day, when a vehicle does not return and a driver does not report, is a different problem covered by Dispatch Management Software. Scheduling is what makes dispatch easier or harder before the day begins.
Delivery scheduling is covered here rather than separately, since committing a delivery window to a customer is the same problem as committing a pickup or a vehicle placement.
Many operators already run Tally for accounting and a GPS or telematics provider for vehicle data. Those stay where they are. What is often still managed outside them is the forward commitment position.
Key takeaways
- Commitments are frequently made by people who cannot see capacity, and capacity is managed by people who did not make the commitments. The gap between the two is where over-commitment happens.
- Capacity is not a single number. It is vehicles of a particular type, in a particular place, with an available driver and valid documents, and any one of those can be the binding constraint.
- A schedule with no slack will not survive an ordinary week, so the question is not whether it slips but whether the slippage is visible early enough to tell someone.
- Provisional and confirmed commitments behave differently and should not occupy capacity in the same way.
- A useful number is commitments met on the committed date, against commitments made.
The spreadsheet is often not the problem
A weekly planning sheet updated in a Monday meeting works, and for an operation with steady volume and a stable fleet it can work well.
The trouble starts at identifiable points.
When commitments are made away from the sheet
A customer calls the branch and is given a date. The sales team confirms a placement. Neither reaches the planning sheet until later, and the sheet was the only place capacity was visible.
When capacity has several dimensions
Three vehicles are free on Thursday. None is the right type, or they are in the wrong city, or one has a document expiring, or there is no driver for the second. The sheet said three.
When the plan is a snapshot
The sheet reflects Monday. By Wednesday two things have changed and nobody has updated it, so the Thursday commitment is made against a picture that is two days stale.
When nobody checks afterwards
Whether last month's committed dates were actually met is not recorded anywhere, so the same over-commitment repeats without anyone establishing that it is a pattern.
What logistics scheduling software holds
Commitments
Committed pickups, deliveries and vehicle placements with dates, windows, customer and location.
Commitment status
Provisional, confirmed or firm, since these should occupy capacity differently.
Capacity by dimension
Vehicles by type and location, drivers available, crews where relevant, and any equipment the work requires.
Constraints on capacity
Documents expiring, maintenance due, driver rest, and vehicles already committed elsewhere.
The reconciliation
Where commitments exceed available capacity, by day, by vehicle type and by location.
Customer requirements
Delivery windows, site access times, appointment requirements and anything else that narrows when work can be done.
Changes to the schedule
What moved, when, at whose request, and what it displaced.
Adherence
Whether committed dates were met, with reasons where they were not.
Capacity is several numbers, not one
A common scheduling error is treating capacity as a count of vehicles.
A commitment can be served only if a vehicle of the right type is available, in the right place or able to get there, with a driver who is available and licensed for it, with documents valid through the movement, and with no earlier commitment already on it. Any one of those can be the binding constraint, and which one binds changes week to week.
The practical consequence is that a schedule which checks only vehicle count will look feasible and fail on the day, and it will fail for a different reason each time, which makes it look like bad luck rather than a systematic gap.
Holding capacity as a structured set rather than a number lets the reconciliation identify what is actually short. Not "Thursday is tight" but "Thursday is short one tanker in the western zone", which is a specific problem with specific options: hire one, move a commitment, or tell the customer now rather than on Thursday morning.
There is a second benefit that is less obvious. Once the binding constraint is recorded each time, a pattern emerges over a few months. An operation that is repeatedly short of one vehicle type in one location has a fleet composition question rather than a scheduling question, and that finding is worth more than any individual week's plan. See Fleet Management Software for the utilisation side of the same question.
Documents deserve specific mention because they are the constraint most often missed at scheduling time. A vehicle whose fitness or permit expires mid-week is available for part of the week only, and a schedule that does not know this will commit it to a movement it cannot complete. Holding validity against the vehicle, as covered in Vehicle Document and Compliance Software, lets the schedule see it.
The commitment gap
In most operations, commitments and capacity are managed by different people, and the information flows badly in both directions.
The commercial side makes commitments. A customer asks whether you can place two vehicles on Thursday and somebody says yes, because saying no loses the load and because they have a general sense that Thursday is usually fine.
The operations side manages capacity. They discover Thursday's commitments when Thursday arrives, or shortly before, and absorb the gap through hired vehicles, rescheduling, or a call to the customer.
Neither party is behaving unreasonably. The problem is structural: the person making the promise cannot see what is left, and the person who has to keep it was not consulted.
Closing this does not require a formal approval process, which most operations will not sustain. It requires two things.
Capacity has to be visible at the point of commitment. Not a report produced weekly, but the current position, visible to whoever is on the phone with the customer. Even an approximate view changes the conversation from a guess to a check.
Provisional commitments have to be distinguishable from confirmed ones. A great deal of quoted work never materialises. If provisional and confirmed occupy capacity identically, the schedule shows a fleet that is fully committed while vehicles stand idle, and people learn to ignore it. If provisional work occupies nothing, the schedule shows capacity that is already spoken for. Holding the status explicitly, and showing both a firm position and a fully-loaded position, is what makes the view usable.
The failure to watch for is a schedule that is technically accurate and operationally ignored. That happens when it is either too pessimistic or too slow to update, and both are more common than a schedule being wrong.
Slack is a design decision
A schedule with no slack will not survive an ordinary week. Vehicles break down, customers move dates, drivers do not report, and a plan that assumed none of these will require rework every single day.
This is not an argument for large buffers. Unused capacity is expensive and an operation cannot carry much of it. It is an argument for the amount of slack being a decision rather than an accident.
Three things make slippage manageable rather than chaotic.
Knowing which commitments have flexibility. Some deliveries have a window of days and some have an appointment. Treating them identically means the rigid ones get moved when the flexible ones could have been.
Knowing what a change displaces. Moving a commitment to accommodate an urgent one is a reasonable decision, and it is only reasonable if the person making it can see what they are moving and tell that customer.
Telling the customer early. A date that looks likely to be missed is worth communicating when that becomes apparent rather than when it arrives. This is among the most valuable outputs of a forward schedule and it depends on the schedule being current.
Recording what changed and why also gives you the picture over time, in the same way the dispatch change log does for the day. If most schedule changes originate with customers rather than with your operation, that is a commercial finding and it belongs in contract conversations rather than in an internal process fix.
Where scheduling looks different by business type
- Packers and Movers Software, where crews as well as vehicles are scheduled and jobs concentrate at month ends.
- Container Transporter and CFS Software, where scheduling runs against free time and gate timings you do not control.
- Bulk and Tanker Transport Software, where product compatibility narrows capacity before availability does.
- City Distribution Software, where routes are fixed and the scheduling question is crews and vehicles against route-days.
- Transport Contractor and Fleet Owner Software, where hired vehicles are the flexible capacity that absorbs the gap.
- Freight Forwarder and CHA Software, where the schedule is built around dates set by carriers and ports.
Why operators choose Pentoggle for scheduling
Capacity held by dimension
Vehicle type, location, driver, documents and existing commitments, so the reconciliation names the actual constraint.
Provisional and confirmed kept apart
Two views, a firm position and a fully-loaded one, so the schedule is neither over-committed nor pretending capacity is free.
Visible where commitments are made
The current position available to whoever is talking to the customer, so a date is a check rather than a guess.
Changes recorded with reasons
What moved, at whose request and what it displaced, which over time shows where the disruption originates.
Sits around your accounting
Tally and comparable systems continue handling accounting, invoicing and GST. Pentoggle adds the operational layer around commitments and capacity.
A useful number for scheduling
Commitments met on the committed date, against commitments made.
It measures the thing the customer experiences, which is whether you did what you said you would do when you said you would do it.
Record a reason whenever a commitment is missed, from a defined list, because the reasons separate into different owners in the same way dispatch changes do. Capacity genuinely short, vehicle unavailable on the day, driver unavailable, customer moved it, customer was not ready on arrival, and planning error are all different findings. Without reasons, a single adherence percentage tells you there is a problem and nothing about whose.
Measure it against the date committed at the time of booking rather than against a date revised later, or the number will improve every time a commitment is quietly moved. If revisions are common, track them separately as commitments changed after confirmation, which is its own useful figure.
Ready to build scheduling software?
Your team knows what is committed for next week.
Whether the capacity exists to serve it, and which specific thing is short, is usually discovered on the day.
Describe how commitments are made and what your capacity actually depends on to Pentoggle in plain English and generate a working first version in hours, then refine it around your process.