5 Questions to Ask Your FDM Vendor Before Signing

Most flight data monitoring contracts get signed once and revisited only when something breaks. A support ticket that goes unanswered for weeks, a false-positive report that eats an afternoon, or a fleet expansion the system can’t keep up with. By then, you’re no longer choosing a vendor; you’re negotiating around one.

If you’re evaluating FDM providers, either for setting up a new program for the first time or just wondering if your current one still fits, these five questions tend to separate a system built for where you are now from one that was only ever built for where you started.

1. Is Your Dataframe Documentation Official, or is it Your Vendor’s Best Guess?

With a few minor exceptions, every FDM system runs on a dataframe or data map. This is a document that maps raw flight recorder data (the ones and zeros) into engineering units data (e.g. “airspeed” and “altitude”) that a human or a detection engine can interpret. The correct version of that document comes from your aircraft’s manufacturer. But sourcing it that way could take time and money, so some vendors skip the step: they pull a “close enough” dataframe from their own library, built from a similar aircraft or a previous customer’s setup, and quietly stand it up as yours.

Day to day, you may never notice. The system still ingests your flights, still produces reports, still looks like it’s working. The problem shows up later, either as subtly wrong parameter mappings that quietly skew your event data, or on the day you try to switch vendors and discover the dataframe you’ve been running on was never officially yours in the first place. Without manufacturer-sourced documentation, the new vendor may have to start the mapping process over, at real cost in time and money — not because the migration is technically hard, but because there was never a real foundation to hand off.

Ask directly: “Is my dataframe sourced and validated against manufacturer documentation, or built from your own library?” If the vendor doesn’t specifically ask you for this, that’s already a bad sign. A vendor who requires the official dataframe documentation for your aircraft separates themselves from one who could just be setting you up for significant problems down the road. For older aircraft where manufacturer documentation genuinely isn’t available, a good vendor will say so plainly and work from the best available alternative.

2. How much analyst time gets burned on events that aren’t real?

False positives are the quiet tax on every FDM program. A detection engine tuned loosely enough to be “safe” ends up flagging routine, non-exceedance flights as events. The problem is that every one of those has to be reviewed by a human before it’s dismissed.

Older detection logic, especially systems still running rules built a decade or more ago, tends to over-flag by default. We’ve seen operators spend 2-3 minutes, per event, validating their FDM data. That might not sound like a lot, but when 30% of those events (or more) turn out to be “non-events”, that’s time that your analyst will never get back. It can be such a problem that some operators (and even some vendors) only validate high severity events, leaving those false low and medium severity events to just blend in with all the others.

Ask directly: “What’s your typical false-positive rate for common exceedance categories, and can you show me de-identified charts or examples for my aircraft type?” If the answer is vague, that’s the answer.

3. Was this system built for a fleet of 5, or a fleet of 500?

Plenty of FDM platforms work fine for a small, stable fleet. Others were built for massive fleets and large Flight Data departments. Few hold up cleanly when serving a small to mid-sized operator who adds aircraft types, adds operational bases, or scales from a handful of tails to dozens. The proof isn’t whether the system technically supports more aircraft; it’s whether the workflow around it (event triage, trend reporting, user permissions, multi-fleet dashboards) was actually designed with growth in mind, or bolted on after the fact.

This matters more than it seems during a demo, because a system that feels adequate at your current size can become the bottleneck exactly when you can least afford one: mid-growth, with a safety team already stretched thin.

Ask directly: “Can you show me a reference customer who scaled from roughly my current fleet size to significantly larger on this same platform, without a system replacement in between?”

4. What happens to your safety program on day one of a switch?

This is the question operators worry about most and ask least because it’s uncomfortable to admit you’re even considering a switch, and because most vendors don’t have a good answer anyway.

The honest version of this question isn’t “will there be any gap at all”. With any vendor switch, there will be. Rather, it’s how that gap is structured. Some vendors take an all-or-nothing approach: nothing goes live until every fleet, every aircraft type, and every integration is fully configured, which can leave an operator waiting months before seeing any real reporting at all. Others induct fleet by fleet, so you get real coverage on your first aircraft type while the rest of the fleet is still being onboarded. Configuration itself can move quickly, often as little as one to two weeks per fleet, rather than dragging out over a quarter.

Ask directly: “Do I need every fleet fully configured before I get real reporting, or can fleets go live one at a time? And realistically, how long does it take to configure a single fleet from kickoff to live reporting?” A vendor who inducts fleet by fleet, and can turn around a single fleet in days rather than weeks or months, gets you real coverage sooner, even if your whole operation isn’t live on day one.

5. What does it actually cost you to leave, if you ever need to?

Multi-year terms aren’t inherently a red flag. Plenty of good vendor relationships run on them and you may be able to get a substantial discount on service by signing one. What matters is what happens if the relationship stops working: punitive early-termination fees, data held hostage until final invoices clear, or auto-renewal clauses that quietly extend a contract nobody reread.

Ask directly: “Walk me through, step by step, what happens if I want to leave in year two.” The clarity, or evasiveness, of that answer tells you most of what you need to know.

None of these questions are about finding the “best” FDM vendor in the abstract. They’re about finding out, before you sign, whether the vendor in front of you is built to earn your business year after year, or just built to make leaving hard enough that you never do.