Parsing a Messy Enquiry Into Legs, Dates and Passenger Needs

The message lands at 18:42 on a Friday and contains exactly one unambiguous fact: the client wants to leave from Farnborough (EGLF). The rest is a forwarded note from a personal assistant: "Nice next Friday, back the Sunday, four of us, possibly five, one with a dog."

A human broker reads that and silently fills in a dozen blanks. Software has to make every inference explicit and recorded, which is where most back offices quietly fail. Our own desk runs on villiersOS, so this is the first place the system earns its keep.

The parser turns the message into a structured trip of two legs: EGLF to Nice (LFMN) on Friday, and LFMN to EGLF on Sunday. The gap between them gives two nights on the ground, which matters for crew duty and parking charges later. The sector is roughly 540 nautical miles, about 1 hour 45 minutes in the air.

What the parser does not do is guess. Passenger count is stored as a range of four to five, and the dog is stored as a requirement, not a footnote. Departure times are left empty and flagged, because "Friday evening" and "Friday lunchtime" open up different aircraft. Passenger names, dates of birth and passport numbers become empty required fields, never plausible-looking placeholders.

The output is a short clarification, drafted for a person to send: confirm five seats, confirm the dog's size, ask for preferred departure windows. Nothing goes to the client until someone on the desk has read it. The point of this stage is not speed for its own sake; it stops a wrong assumption from travelling through the next four stages, where it becomes expensive.

Sourcing Operator Options and Costing the Positioning Legs

The headline hourly rate is the least useful number in a charter quote. What decides the price is where the aircraft starts the day, because an empty flight to reach the client is billed like a full one.

With the trip parsed, villiersOS queries the operator fleet data for aircraft that can seat five and reach LFMN without a fuel stop. It applies hard filters first. Cabin must seat at least six, leaving room for luggage. Positioning distance to EGLF must be under 250 nautical miles. The operator must hold a current air operator certificate and insurance on file. Anything failing those three tests is dropped before a price is calculated.

What remains gets costed on the whole trip, including the empty flights at each end. A London-area Embraer Phenom 300E, with a 5 ft 1 in cabin width and up to eight seats, might position 40 nautical miles to Farnborough at negligible cost. A Cessna Citation Latitude, at 6 ft 5 in wide and 21 ft 9 in long, offers a noticeably larger cabin for five with luggage and a dog. If it is based at Paris Le Bourget, roughly 200 nautical miles away, the positioning legs add real money.

For a return of this shape with two nights away, realistic all-in figures run from about £14,000 to £19,000 on a light jet and £20,000 to £26,000 on a midsize aircraft. These are indicative ranges; actual quotes move with season, crew availability and Nice handling fees.

The system also checks for empty legs that happen to line up, such as an aircraft that must return to the UK from the Côte d'Azur on the Sunday. Those are surfaced but never assumed. Each option is ranked on total trip cost, positioning distance, cabin fit and operator safety record, and presented with the arithmetic visible. A desk can see why option two beat option three, which is what lets a person trust the ranking enough to challenge it.

Where a Human Still Signs Off: The Approval Gates Inside the Workflow

The interesting design question in charter operations software is not what to automate; it is where to stop. In our workflow the software prepares, and a named person decides.

There are three points where the system deliberately halts. The first is the shortlist: someone on the desk chooses which two or three options the client sees, and can drop a cheaper option because the operator's response times have been poor. The second is the price. The software calculates cost and a suggested margin, but a person sets the figure the client pays, because that depends on the relationship, the season and what else the client has booked.

The third gate is any client-facing wording. Drafts are written by the system and posted for review; they are not sent. A message that reaches a high-net-worth client with a wrong aircraft name or an optimistic timing is a trust problem no software cost saving repays.

Timing is a gate too. Outbound messages are held for a send window, typically late morning the next business day, so a Friday-evening request does not produce a Friday-night reply that looks hurried. The system can be overridden, but an override is a recorded act by a person, with a reason attached.

The discipline is that each gate has a named owner and a visible state. "Awaiting approval" is a status on the trip, not a feeling in someone's head. Judgement calls stay with people; the checking around them does not.

Paperwork Before Progress: Why a Trip Cannot Advance Without Its Documents

On most desks, a booking moves forward because someone remembers that it should. In villiersOS a trip moves forward only when the documents that justify the next step exist in the system.

The trip has stages: enquiry, options presented, quote accepted, contract issued, contract signed, confirmed, flown. Each transition has a checklist. Moving from "quote accepted" to "contract issued" needs the operator's written confirmation of aircraft and price. Moving to "confirmed" needs a signed charter agreement stored against the trip, along with proof of payment.

The reason is blunt. A client told "you are confirmed" without a countersigned agreement holds a booking that does not legally exist, and the operator may still release the aircraft to another customer. A gate that checks for the actual document, not a ticked box, prevents that. A status change without its file attached is refused.

Passenger paperwork follows the same rule. For the Nice return, passport details for all five travellers are needed before handling requests go to LFMN, and the dog's travel documents go on the checklist for both directions. The system tracks which items are outstanding, who was asked and when. If the fifth passenger's passport is still missing 48 hours before departure, that surfaces on the desk's board as a named blocker.

The same logic covers operator-side documents. The certificate, the insurance and the crew details for the specific aircraft are stored with the trip, so if a question arises after the flight there is one place to look. Nothing here is glamorous. It is the difference between a desk that can prove what happened and one that has to reconstruct it from inboxes.

What Running Our Own Charter Desk on villiersOS Has Taught Us About the Software

Building back-office software for a charter desk is easy to get wrong when the builder has never had to chase a missing passport at 17:00 on a Thursday. Running our own desk on it has changed what we build.

The first lesson is that parsing pays back most. Our working assumption is that a manually built quote pack, with legs, availability checks and positioning costs, takes a broker 30 to 45 minutes. The structured version arrives in a fraction of that, so the human's time goes on the shortlist and the price, not on retyping dates.

The second lesson is that ambiguity should be surfaced, never resolved silently. Every early bug we found traced back to a system that guessed: a "Sunday" interpreted as the wrong Sunday, a passenger count of "four-ish" rounded down. A field marked uncertain costs one question to the client; a wrong guess costs a repositioned aircraft.

The third lesson is about what to leave alone. Relationship judgement, negotiation and the decision to decline an enquiry remain with people. The software should make those decisions better informed, not make them for the desk.

There is a wider point for anyone assessing this category. The agent model, where software handles structured work while people hold the approvals, is not specific to aviation. The same architecture could run a yacht charter desk, where legs become itineraries and operator paperwork becomes crew and safety certificates, or an executive concierge operation with the same need for held-back client messages. That is an extension of the model, not something villiersOS does today; our live operation is private aviation.

For brokers and operators weighing what their own back office should do, a practical test works. Automate anything that is a lookup, a calculation or a checklist. Keep for a person anything that involves a price the client will see, a promise on the firm's behalf or a judgement about a relationship. If the software cannot show its working on the first group, and cannot stop cleanly at the second, it is not ready to run a desk.