What breaks when a charter fleet outgrows the whiteboard

Most small charter and fleet operators schedule on a wall — a whiteboard, sticky notes, and a dispatcher who can turn round and say something over the cube partition. It works, and it keeps working until somewhere around twelve aircraft.

Past that it stops, and not because anybody got worse at their job. A whiteboard records where everything is. It has never shown how much margin is left — in a crew's duty day, in an aircraft's hours before maintenance, in the twenty minutes a turn was supposed to take — and past a dozen aircraft nobody can hold that in their head alongside it either. This page answers the questions that follow, in the order they tend to arrive.

• How many aircraft can a whiteboard handle?
• Why does a whiteboard work at all?
• What is a charter dispatcher actually solving?
• Why can a legal schedule still be one you must not publish?
• What does moving one trip actually touch?
• Whose trip slips when an aircraft runs late?
• Why would an operator forbid chartering a particular customer?
• Is this a Gantt chart like Microsoft Project?
• What does GanttOps do, and what does it not do?
• Is there a product I can sign up for?

How many aircraft can a whiteboard handle?

About twelve. Schedulers and dispatchers really struggled to be optimal once a fleet passed roughly a dozen aircraft. Below that a whiteboard is genuinely sufficient; above it, the same people doing the same job stop being able to see whether the schedule they have written is a good one.

The reason is combinatorial rather than clerical. Every trip could go on several aircraft, each of those aircraft is already carrying other trips, and each of those has consequences for crew and maintenance that do not show up until later. Adding an aircraft does not add one thing to keep track of. It multiplies them.

Why does a whiteboard work at all?

Because it is shared state. One surface, one room, one version — and anybody who changes it changes it for everyone, immediately, in front of the people affected. That is why the wall survives long after it should have been replaced.

Which sets the bar for anything replacing it. Software that shows one dispatcher a change the others cannot see is not an improvement on a whiteboard, it is a step backwards from one. Everyone seeing the change is not a feature worth listing. It is the entry requirement.

What is a charter dispatcher actually solving?

Positioning, outside lift, upgrades, maintenance and crew — almost none of which the customer sees or pays for. The trip that got booked is the small part.

• Positioning. An aircraft is rarely where the next customer is. The empty legs flown to collect them and to leave afterwards are the operator's cost, not the customer's, which makes them the largest single thing worth optimising.
• Supplemental lift. When there are not enough aircraft or crew to cover demand, a third-party charter operator fills the gap — at a higher price, and with a different aircraft, a different crew and a different standard. The cost shows up in the accounts. The experience shows up in the renewal.
• Upgrades. Putting a customer on a larger type than they booked is often cheaper than buying lift from outside. It also removes that aircraft from everything else you might have done with it.
• Maintenance, in three dimensions at once. Not a date in a calendar: hours flown, cycles — landings and engine starts — and days since the last service. An aircraft can be comfortable on two of those and out of margin on the third, and the schedule is what consumes all three.
• Crew. Duty periods have ceilings, flight time within a duty period has a lower one, and rest has to be a genuinely continuous block rather than the sum of the gaps in a day. Crew and aircraft are separate resources that have to be solved together.

Why can a legal schedule still be one you must not publish?

Because legal and survivable are different tests. If a flight is already airborne and the crew runs past their duty limit, that is dealt with. You cannot build a schedule that assumes it.

So a schedule can be entirely legal and still be one you must not publish, because it is only legal if nothing slips. The quick turn that works on paper needs the inbound on time, the fuel truck already there, and the passenger walking out to the aircraft rather than finishing a meeting. Each of those is fine alone. A schedule that needs all of them to hold is a different kind of object from one that does not, and no feasibility check will tell them apart.

Which is why comparing two options matters more than finding one. The question is rarely whether a schedule is allowed. It is how much has to go right.

What does moving one trip actually touch?

Everything ordered against that aircraft's tail number. The catering, the car, and on an overwater leg the life rafts, which have to be physically shipped to wherever the aircraft now is and have a lead time that has nothing to do with flying.

The tail number is what turns a tidy abstraction into a real failure. Put two of your own aircraft on the same ramp and "the aircraft at nine o'clock" has stopped identifying anything. Catering ordered against one tail does not follow the trip when the trip changes tail — it goes to the aeroplane it was ordered for, which is now doing something else, and nobody finds out until it is expensive.

Each of those orders has a cutoff, and the cutoff differs by vendor and by field. A change landing ninety minutes the wrong side of one costs money that never appears in a positioning calculation. Seeing that at the moment of the drag, rather than in an email the following afternoon, is most of the argument for doing this on a timeline at all.

Whose trip slips when an aircraft runs late?

Whoever's contract says they can be moved. A customer running two hours late is not one customer's problem: the same aircraft is carrying somebody else later, and their quick turn has just evaporated, the crew margin with it.

So the dispatcher is not choosing the cheapest recovery. They are choosing who absorbs the disruption, and the customers are not equivalent. A share owner, a card member buying hours in bulk, and a charter booking are commercially different things carrying different notice terms and different guarantees. Operationally they are one fleet and one desk. Contractually they are a hierarchy, and the hierarchy decides who gets moved.

It is explicit enough that the predictable peaks are written into the contracts in advance: around an event like the Super Bowl, card members are blacked out and cannot fly at all. The rest of the year the same judgement is made one trip at a time, at speed, by somebody who has to see the whole fleet to make it.

Why would an operator forbid chartering a particular customer?

Because the account is up for renewal, or had a bad experience and is owed a good one. An operator can flag a customer as ineligible for outside lift — own aircraft only — and the flag binds the schedule exactly as a fuel range would.

It is the most interesting constraint in this problem because there is no physics in it. It is a commercial fact expressed as a scheduling rule, and it is the whole argument for a scheduling control that does not understand your business. No control could know what "up for renewal" means, and none should try. It enforces a flag whose meaning lives entirely in the operator's own system — and because it never learns what the flag means, the next operator uses the same mechanism for something else.

That genericism was not a preference. It is what was left after building this for operators who each needed something different. It is also why two schedules with identical cost are not interchangeable: one of them may put the account you are about to lose onto somebody else's aeroplane, and nothing in the money says so.

Is this a Gantt chart like Microsoft Project?

No. The rows are resources, not tasks. A project Gantt draws work broken into tasks, linked by dependencies, rolled up into a plan you baseline and then measure against. This draws aircraft and crew down the side, and what each of them is doing across the day.

There are no predecessors, no critical path, no percent complete and no plan to be behind. There is a fleet, a day, and a set of trips that have to be assigned to it — where the constraints are not "this task follows that one" but that an aeroplane can only be in one place, a crew can only be awake for so long, and an airframe has only so many hours before it is due.

The gesture that matters here is the one a project chart barely has: moving an item from one row to another. Reassigning a trip from one aircraft to another is not an edge case, it is the operation. And where a project plan is a document maintained over months, this is redrawn as the day happens — the schedule for this afternoon is being changed this morning by somebody who has to see the consequences before they let go of the mouse.

What does GanttOps do, and what does it not do?

It is where the schedule gets changed, not only where it gets looked at. It has no persistence, no optimiser of its own, and it does not order catering.

What it does: draws resources and the items assigned to them, and lets a dispatcher rearrange them by hand — give a trip to another aircraft, slide it to a different time, stretch it to a different duration — one drag at a time, against a fleet drawn at once. What a move implies is computed by the operator's system and drawn straight back onto the timeline, so the empty legs that a reassignment creates before and after the trip appear as part of the same gesture rather than in a recalculated schedule half an hour later.

It also refuses. A gesture that would break a rule the operator has declared does not complete and then get reported; it does not complete. Margin thinning short of that shows through shape, colour and what appears on hover, and when a change crosses a limit the control logs it and raises a warning. A human decides what to do next, because working out that the second customer has to be told is judgement rather than arithmetic.

What it does not: it is a control rather than an application, so it holds no data of its own and is not something an operator logs into. In the original system, catering and cars and rafts sat with a department running its own workflow for every vendor and every location, and the software tracked what they did rather than placing it. Most of those vendors have portals now and some have interfaces worth connecting to, so an operator building this today would integrate where the vendor allows. That integration belongs to the operator's system. The timeline's job is to be the place the change is made and the consequences become visible.

Is there a product I can sign up for?

Not yet. There is no generic version of this — no board you open in a browser, drag a few things around on, and start running an operation from. The timeline is a component, and it becomes useful when it is wired to one operator's aircraft, one operator's crew rules and one operator's definition of what may not be moved.

So it arrives as part of a system rather than as a subscription, and Bitwise builds that system with you — which is the honest answer to the awkward version of this question. An operator whose current scheduling tool is a wall has no software to embed a control into. That is the work, not an obstacle to it.

For more information, or to arrange a demonstration, email info@ganttops.com.