Part 135 Charter Operations Software Problems: The 7 That Cost Real Money, and How to Avoid Them

Why does scoping a full operations platform in one go fail so often?

Because the obvious project is the wrong one. An operator frustrated with four disconnected systems writes a specification that replaces all four, which means rebuilding scheduling, crew rostering, trip management, maintenance visibility, quoting, invoicing and owner accounting simultaneously. That is a 9 to 15 month programme with a 14 week piece of genuine differentiation buried inside it, and the differentiation is the only part a product cannot already do.

The scheduling and rostering side of FL3XX, Avianis and Leon Software is mature. Rebuilding it consumes most of the budget to arrive at rough parity, and while that work is happening the sales desk is still quoting from a spreadsheet. Twelve months later the operator has a platform, a large invoice and the same quoting problem they started with, because the quote engine was scheduled last.

The fix is to invert the order. Build the commercial layer first: a quote engine that reads availability from your scheduler and due status from your maintenance tracker, then applies your own duty legality interpretation and your own pricing rules. That is a 14 to 20 week piece of work at $90,000 to $200,000 and the sales desk uses it on day one. Trip execution, crew apps and owner accounting follow once the engine has proven the data model. Operators who sequence it this way get value while the rest is still being scoped.

What goes wrong when you migrate owner agreements and historical pricing?

Owner agreements are the migration problem nobody prices. They exist as signed documents with individually negotiated terms: a different split on owner sourced trips, a management fee structure that changed at renewal, a maintenance reserve arrangement, a fuel allocation method that one owner argued for personally. Nothing about them is structured data, and turning fourteen of them into rules is a legal and commercial exercise before it is an engineering one.

Historical pricing carries a second trap. If quotes and statements are migrated without recording which rate card version produced them, every historical number becomes unreproducible the first time you change a rate. An owner queries a statement from eight months ago, the system recomputes it against today's rules, and the figure no longer matches what you sent. That single behaviour destroys trust faster than any billing error, because the owner now believes the numbers move.

Two fixes. First, model your three most common owner agreement shapes properly and treat genuinely bespoke terms as explicit exceptions with their own rule records, rather than trying to build one abstraction that covers everything. Second, pin every quote, invoice and statement to the rule versions that produced it at the time, and never recompute history. Statements should be reproducible byte for byte years later. Operators who do this stop having owner disputes about arithmetic and start having them about policy, which is a much better conversation.

Why do the maintenance tracker and scheduler integrations break after launch?

Because both are read integrations against systems that were not built to answer your question. Maintenance tracking services hold hours, cycles, calendar due items, component life limits and minimum equipment list entries, and they were designed for the continuing airworthiness team rather than a quote engine asking whether a specific trip fits. Interface quality varies sharply by provider, and some of the answers you need are only available in a report format rather than a data feed.

The failure after launch is usually staleness rather than an outage. The feed keeps working, the numbers keep arriving, and nobody notices that hours flown are being posted a day late so the projection is consistently optimistic by one flight. Or the scheduler's availability view stops reflecting a soft hold because a new trip type was introduced and nobody mapped it.

Two things prevent this. Build a freshness contract into the engine: every quote records the age of the data it used, and the engine refuses to return a clean answer when a feed is older than a threshold you set. That converts a silent wrong answer into a visible one. Second, reconcile weekly rather than continuously, comparing the projection your engine made against what the maintenance planner actually recorded, and treat divergence as a defect rather than as noise. Operators who skip this discover the drift when an aircraft goes out of service on a booked trip.

What happens when duty legality is not covered at quote time?

Part 135 flight, duty and rest rules constrain what a crew can accept, and the constraint depends on the real shape of the day including positioning legs and the report time before the first departure. Crew currency adds recent experience, required checks and any type or airport specific qualification on top. Most operators check all of this after the trip is sold, because checking it during quoting is too slow with the tools available.

Scheduling products do warn you once the trip is built, which is genuinely useful and is the wrong point in the process. By then a price sits with a broker and the remaining options are to absorb the cost of a larger aircraft, buy a hotel and a later departure, or decline and damage the relationship. Operators absorb it more often than they admit, because declining after acceptance is worse.

The fix is to run legality as part of the calculation rather than as a warning afterwards. The engine constructs the full duty day including positioning, applies both the regulation and the tighter company limits your director of operations actually enforces, and returns either a compliant crew assignment or a specific reason it does not work. Where a trip is only legal with a crew change or an overnight, that cost lands in the price. Build the company limits as editable rules, because they change after every safety review and you do not want a release each time.

Should you build custom or configure what you already own?

Under about six aircraft with straightforward ownership, configure. FL3XX or Leon will run scheduling and quoting adequately, Avinode will bring lead flow, and a build consumes money better spent on a second scheduler who can answer the phone at 16:40. We say this to operators regularly and it costs us work.

For many mid sized operators the right answer is a split rather than a choice. Keep the packaged scheduler for rostering and trip management, where the products are mature and you have already paid for the capability, and build only the commercial layer where your differentiation actually lives. That is a smaller, lower risk project than replacement and it leaves you free to change scheduler later without rebuilding pricing.

Full replacement is justified when the commercial structures are the business: a fractional programme with occupied hour accounting, a jet card with banked hours and peak day rules, or a managed fleet where charter, owner flying and a fractional pool share the same aircraft. Those describe an operation whose accounting logic cannot be configured into a product designed for simple on demand charter. The measurable trigger is simpler than any of that: count the requests where you responded after the trip had already been sold elsewhere. If that number is material, quoting speed is costing you revenue today.

How do hidden costs get into the quote?

Five items drive most of the overrun. Fractional and jet card programmes, because share accounting, exchange rules and peak day handling are intricate and every programme is different, so they behave like a separate project rather than a feature. International operations, which bring permits, customs and border filings, passenger documentation and per country handling requirements, each with its own data and tasks. Maintenance tracker integration, priced as a connector and delivered as an investigation when the provider's interface turns out to be thin. Aircraft type count, because performance and suitability limits are per type and that data has to be curated by someone who knows it. And owner agreements, where each genuinely unique commercial term is a rule to model and test.

Make them visible by asking for each as a separate line. Ask specifically which maintenance providers the developer has integrated with by name and what the interface looked like. Ask whether international is in phase one or phase two, and push it to phase two unless it is a large share of your flying. Then ask for a parallel quoting period in the plan, four weeks of running both, because the differences between the engine and your scheduler's judgement are the rules nobody wrote down.

What separates a build that works from one that fails here?

The working ones treat the quote as the central object and model it properly: request, itinerary with positioning legs, aircraft assignment, constructed duty day, cost model and price model as separate things. Legality and maintenance projection run before the price is returned, not after. Pricing rules are versioned and every quote is pinned to a version. The margin on a trip is visible before the number is sent, which changes how schedulers behave within a week.

The failing ones share two shapes. Either the developer drew bookings, aircraft and invoices, which is a reservation system and does not know what a duty day is. Or the operator scoped everything at once and the sales desk never got a tool, so the project was judged on a demo rather than on trips won.

The test to apply before signing is to ask the developer to model a quote on a whiteboard and watch whether they ask, unprompted, whether legality is evaluated before or after the price goes out. Then ask how a rate card change is handled without corrupting historical quotes and owner statements. Versioned rules with each quote pinned to a version is the only acceptable answer, because owner disputes surface months later and the rate card will have moved twice by then.