Charter RFQ best practices for broker desks

A charter RFQ fails when the operator has to infer the trip from a forwarded email chain. The brief should stand alone: origin and destination with ICAO codes, local departure time and time zone, flexibility, passenger count, and any cabin or luggage constraint that changes the aircraft category. If the trip is a round trip, open-jaw or multi-leg, each leg needs its own local time. A single 'return Friday' line is how quotes drift apart.

Jet Intelligence keeps that brief on the mission record before a sourcing wave is sent. The operator then sees the approved request, not a personal reconstruction of it. The broker still decides who is on the wave and how wide it is.

The useful reply is not only a number. Ask for aircraft type, registration when the operator is willing to share it, passenger capacity, price certainty, what is included, what is excluded, and how long the price holds. A decline or a question is also a complete response. Treating silence as the only alternative forces the desk to chase the same trip in a second inbox.

Best practice is a response window that matches the client deadline, plus a hard stop so the comparison is not rewritten every time a late email arrives. Late offers can still be read. They should not silently reorder a proposal that has already been released.

The first sourcing wave needs passenger count, not passports. Names, contacts and travel documents belong later, on an accepted trip, and only with the operator who is actually performing it. Sending a manifest to a wide shortlist creates a confidentiality problem and does not improve the price.

The same rule applies to the broker's own supplier list. A client-facing document should not reveal which operator was asked, what the net cost was, or which relationship produced the option. That separation is what makes an RFQ safe to run at volume.

A large operator database is not a reason to email all of it. Rank by aircraft fit, known base, and whether the record is confirmation-ready, then cap the wave. Operators answer faster when the request looks intentional. Brokers keep more of the relationship when the same operator is not hit with every enquiry that shares a continent.

After the wave, store the outcome against the mission: quoted, alternative, question, decline, or no response. That history is the start of a sourcing system. The next similar trip should not begin from a blank search.