The client flies weekly. The CRM sees one deposit.
The request lands at 23:40 — Teterboro to Aspen, Friday, six pax — and two other brokers already have it. Whoever quotes first on the right tail usually books it. We build the desk's system around that clock: one record per trip request from sourcing through contract, with the ops platform left as the system of record for the flown leg.
The trip request lives in a text message.
The same trip arrives three ways: a broker's mobile, a WhatsApp thread with the principal's assistant, a web form nobody owns. It gets sourced in Avinode, quoted on three tails, and then the client shifts the date by a day and the whole thing is re-entered as a fresh request. Nobody can say how many distinct trips the desk lost last quarter, or to whom.
Ops owns the leg. The CRM owns the client.
Private aviation — trip requestsWhere a trip request becomes a flown leg.
A date change is not a new trip
A record keyed to the request, not the contact: legs, dates, pax count, aircraft category, every tail quoted, and the source. A date change amends the request instead of spawning a second one.
Contract signature is the handoff
FL3XX, Leon or Schedaero stays the system of record for the leg, the crew and the invoice. Contract signature is the handoff. Flown legs and invoiced totals come back into the CRM read-only, keyed to tail and trip.
Hours remaining, not the anniversary
Jet card and block hour programmes modelled as a deposit with dated draw-downs — hours remaining, rate escalation, expiry, unused balance. Renewal becomes a task with an owner, raised on the balance rather than the anniversary.
The relationship without the routing
Passenger manifests and itineraries stay out of the CRM by design. Team and property-level permissions so marketing sees the relationship and never the routing. Principals, assistants and family office staff kept as distinct roles on one account.
Owners and charter, on one board
A management company sells to aircraft owners and to charter clients at once. Separate pipelines, separate lifecycle stages, shared reporting — so owner acquisition and fleet utilisation sit on the same board as retail charter.
Time to first quote, measured
Time to first quote measured per request and routed by aircraft category, region and after-hours rotation, with escalation when a request sits unquoted past the threshold. The second quote out rarely wins.
How the system gets built.
Sit the desk
Two weeks with the charter desk. We watch requests land across phone, email and Avinode, trace where each one dies, and read the ops platform and accounting exports as they actually exist.
Write the trip sheet
We define the trip request object, the aircraft and tail records, the membership balance and the owner pipeline, then write down which system owns which field before anything is built.
Build and prove
Build in HubSpot: sourcing and quote stages, ops platform sync, membership draw-down reporting, permission scoping for discretion, and the response-time alerts the desk is measured on.
Release to the desk
Documented data model, named owners for every routing rule and threshold, the desk trained on the reports. We stay long enough to watch a full quoting cycle run without us.
The card sells once, then drains.
A jet card closes on the deposit. The flying happens over the next two years, drawn down hour by hour, while the deal sits closed-won and silent. Nobody sees a card at eleven hours remaining until the client rings to book. Model the balance as hours drawn down, so depletion, rate escalation and expiry each raise a renewal with an owner.
