Pilots & Ops folks—What’s your honest take on SMS tools?

twrightflyer

New Member
Hey folks—I'm a former Army pilot and now work in aviation consulting. I'm considering building a lightweight, modern SMS platform for smaller Part 91 and 135 operators.

Before writing a single line of code, I’m gathering input from pilots, ops directors, and safety managers to understand what really works and what doesn’t in your current system.

👉 Survey link (3 minutes, anonymous) or copy/paste: Part 91/135 Operator SMS Survey

I’ll gladly share back a summary of insights for anyone curious.

Really appreciate any time you can give!
 
We are a 91 “Small” department as you will.

I’ll be 100% honest, and SMS system which is not directly tied to our dispatch and planning software is not of interest to us. We have an SMS/TEM program but most off the shelf programs require more positions than we have for effective management.

I anticipate AI analysis of our QAR/DFDR tied to sms/ reporting will eventually be a thing, but until then it often feels like the work involved doesn’t justify the returns honestly.
 
Hey folks—I'm a former Army pilot and now work in aviation consulting. I'm considering building a lightweight, modern SMS platform for smaller Part 91 and 135 operators.

Before writing a single line of code, I’m gathering input from pilots, ops directors, and safety managers to understand what really works and what doesn’t in your current system.

👉 Survey link (3 minutes, anonymous) or copy/paste: Part 91/135 Operator SMS Survey

I’ll gladly share back a summary of insights for anyone curious.

Really appreciate any time you can give!
Here's your competition. This is what we use.

 
Hey folks—I'm a former Army pilot and now work in aviation consulting. I'm considering building a lightweight, modern SMS platform for smaller Part 91 and 135 operators.

Before writing a single line of code, I’m gathering input from pilots, ops directors, and safety managers to understand what really works and what doesn’t in your current system.

👉 Survey link (3 minutes, anonymous) or copy/paste: Part 91/135 Operator SMS Survey

I’ll gladly share back a summary of insights for anyone curious.

Really appreciate any time you can give!
I don't fly anymore (I also write code for money), but I found most of the ops software and SMS tools were either too general or too bespoke to some other customer's needs. I don't really think there's a "one size fits all" solution to this problem because so many operations are so different. If it were me (and I guess maybe it should be), I'd be building these tools for individual operations.

"Hey, let me build you this, I'll build it the way your operation works, and when I am done, the only monthly costs will be to host it." Some of these products are hundreds or even thousands of dollars per month. That's absurd for what most of them are offering.
 
I don't fly anymore (I also write code for money), but I found most of the ops software and SMS tools were either too general or too bespoke to some other customer's needs. I don't really think there's a "one size fits all" solution to this problem because so many operations are so different. If it were me (and I guess maybe it should be), I'd be building these tools for individual operations.

"Hey, let me build you this, I'll build it the way your operation works, and when I am done, the only monthly costs will be to host it." Some of these products are hundreds or even thousands of dollars per month. That's absurd for what most of them are offering.

Just thought, since I used to impersonate product managers from time to time in my sales engineering days...

Instead of building for individual operations - which will inevitably suffer from scope creep - what if you built a modular toolset? In other words, give them tools to build their own. I've got a hazy idea of a set of features built on whatever APIs are out there and let them Lego their way into something that works for them.
 
Just thought, since I used to impersonate product managers from time to time in my sales engineering days...

Instead of building for individual operations - which will inevitably suffer from scope creep - what if you built a modular toolset? In other words, give them tools to build their own. I've got a hazy idea of a set of features built on whatever APIs are out there and let them Lego their way into something that works for them.
eh- in theory sure, but once you go through an Is-bao audit for compliance you end up getting sold on the same product that everybody else has. Ideally SMS/TEM etc is based on a global best practices/safety criteria.

not a huge help if you let me build say “airport/weather” threats into my SMS- but then pull out schedule/duty/circadian disruption. (Yes I’m only talking about parts of a FRAT) but same idea to the larger legos if you will.
 
How much does this cost you guys?

I mean, like, this looks expensive, and frankly, not very good...
I have no idea what we pay for it. Above my pay grade.

It has some holes and some things I don't like for sure. But it handles FRATS and ASAP and Hazard/Incident reports well enough for our operation.
 
I have no idea what we pay for it. Above my pay grade.

It has some holes and some things I don't like for sure. But it handles FRATS and ASAP and Hazard/Incident reports well enough for our operation.
I should start building these for people... I bet I can be a lot cheaper than these kinds of guys and do it custom for their operation, all of the ones I've used have been trying to do too much it felt like? Maybe someone of them were good, but it always felt like they were trying to do everything instead of one or two things that I needed well. Also, the numbers in most of the frats were just totally pulled out of people's ass lol.
 
Just thought, since I used to impersonate product managers from time to time in my sales engineering days...

Instead of building for individual operations - which will inevitably suffer from scope creep - what if you built a modular toolset? In other words, give them tools to build their own. I've got a hazy idea of a set of features built on whatever APIs are out there and let them Lego their way into something that works for them.
Love this idea. You'd have to be smart about it so that (because of scope creep again) you didn't cover every usecase... but like, getting an operation something like 80% of the way there with boilerplate stuff and being like, "oh, you want to add X? Well, I can put that together from these other two modules."
 
eh- in theory sure, but once you go through an Is-bao audit for compliance you end up getting sold on the same product that everybody else has. Ideally SMS/TEM etc is based on a global best practices/safety criteria.

not a huge help if you let me build say “airport/weather” threats into my SMS- but then pull out schedule/duty/circadian disruption. (Yes I’m only talking about parts of a FRAT) but same idea to the larger legos if you will.
The FRATs I've used have all been kind of garbage except for one company I worked at to be honest... Every place I worked had some scoring system except for one and there was no actual reason for the scores under the hood, it was kind of funny...

The place that did it right broke the FRAT down by each phase of flight down and looked at the risks in each segment. It was really cool, because let's say the weather sucked at the departure airport, but everything around the departure was fine, why should that drag down the rest of the flight? If it was borderline, you'd note it in the FRAT, call the CP or DO or their designee, "hey man, the weather sucks here, and if I leave I won't be able to get back in, but if something happens there's like 6 airports within 20 minutes, and the weather is good for the rest of the flight?" They'd ask a few questions, then either choose to accept your strategy or not. You didn't end up with really bizarre situations where the flight was moderately sketchy the whole time because you were borderline the whole way (if you needed too many mitigations, it was an automatic scrub), and then also like if you were having a bad day for something, there was a mechanism to put a guy on easier trips. "Bob has flown 40 hours this week, it's been bananas, he's fatigued - ok, he can't accept any mitigation then."

I liked this a lot better than a points system where the numbers were clearly made up by how scary whoever made the FRAT thought that particular thing was but you could end up with a crazy situation where you'd be mashing ice on the whole flight, land at mins at both airports, have to hand deice from some shack, are flying in your region of circadian low, and are 2 points away from scrubbing but there's a thunderstorm 40 miles away from you, moving away from you on a clear VFR day and you have to add +6 or whatever because the "convective weather within 100NM? - +6" or whatever.

As far as I can tell though, literally none of the FRATs I have ever used (and in my career I used maybe 10 different methods for mitigating risk?) had any basis in any statistics.
 
The FRATs I've used have all been kind of garbage except for one company I worked at to be honest... Every place I worked had some scoring system except for one and there was no actual reason for the scores under the hood, it was kind of funny...

The place that did it right broke the FRAT down by each phase of flight down and looked at the risks in each segment. It was really cool, because let's say the weather sucked at the departure airport, but everything around the departure was fine, why should that drag down the rest of the flight? If it was borderline, you'd note it in the FRAT, call the CP or DO or their designee, "hey man, the weather sucks here, and if I leave I won't be able to get back in, but if something happens there's like 6 airports within 20 minutes, and the weather is good for the rest of the flight?" They'd ask a few questions, then either choose to accept your strategy or not. You didn't end up with really bizarre situations where the flight was moderately sketchy the whole time because you were borderline the whole way (if you needed too many mitigations, it was an automatic scrub), and then also like if you were having a bad day for something, there was a mechanism to put a guy on easier trips. "Bob has flown 40 hours this week, it's been bananas, he's fatigued - ok, he can't accept any mitigation then."

I liked this a lot better than a points system where the numbers were clearly made up by how scary whoever made the FRAT thought that particular thing was but you could end up with a crazy situation where you'd be mashing ice on the whole flight, land at mins at both airports, have to hand deice from some shack, are flying in your region of circadian low, and are 2 points away from scrubbing but there's a thunderstorm 40 miles away from you, moving away from you on a clear VFR day and you have to add +6 or whatever because the "convective weather within 100NM? - +6" or whatever.

As far as I can tell though, literally none of the FRATs I have ever used (and in my career I used maybe 10 different methods for mitigating risk?) had any basis in any statistics.
That’s because data costs money, and, nobody wants to pay for access/ so much data is stuck behind gatekeepers (cough 121, alpa etc)

We also have a remarkably low incident per flight hour rate- so hard “risk” data is hard to come by.

QAR’s can give you what your looking for- but it’s hard to develop trends in your own department if you only fly 100-200 hours a year.

Get some 50,000 hours of flying a month, and you can correlate. It gets a lot easier to look at all landings that were say- out of the touchdown zone, and then pull casuals like weather, winds, fatigue, airport familiarity etc.

Ideally with SMS the fray scores get adjusted as risks are identified… but there’s never enough feedback. The number of pilots that will drop a risk/threat/SMS report when they make a mistake because of small factors like an early/ late day is slim. Nobody wants to do the paperwork etc. they just want to park the plane and go home.

Regardless IMHO FRATS should mostly serve to identify risks- and make the crew aware + give them a solid and informed reason to scrub a flight. A frat should never be used to justify why a flight can go.
 
Back
Top