Why Your SMS Should Flex Around Your Operation, Not the Other Way Around

by: Gary Tougas, Chief Product Officer of AirTera

I’ve spent my career as a product person. Before aviation, I worked at tech companies in fintech, real estate technology, and mortgage technology: complex, heavily regulated spaces where workflows are complicated and the stakes are real.

I was never the domain expert in those industries. What I was good at was sitting with the experts, listening closely, and translating what they knew into software that made their lives simpler.

That is the lens I brought to aviation safety management when I co-founded Soar. It is also the same philosophy that drives what we are building today at AirTera, which acquired Soar and brought me on as Chief Product Officer.

Here is what I noticed pretty quickly about the aviation safety software space: many SMS tools were built from deep safety expertise. That expertise matters. It is necessary. But when safety knowledge gets translated into software without the same level of product and design discipline, the result can be a system that reflects one person’s very specific interpretation of what compliance should look like.

Rigid workflows. Non-intuitive interfaces. Required steps that may make sense for one operator but not another. A system that assumes every organization runs safety the same way.

The problem is, they do not.

And the FAA knows that.

Part 5 is not written as a one-size-fits-all operating manual. The requirements are real, and they matter. If Part 5 requires you to retain certain safety assurance records for a minimum of five years, that is not a suggestion. You retain them for five years. Those lines exist for a reason.

But Part 5 also leaves room for operators to design an SMS that fits the size, scope, and complexity of their operation. The “what” is defined. The “how” is where your operation matters.

Take §5.55(b), which requires operators to define a process for conducting risk assessment that allows for the determination of acceptable safety risk. The regulation does not prescribe a single universal workflow, risk matrix, approval chain, or meeting structure. That is intentional.

Your aircraft, routes, people, operating environment, hazards, and organizational structure are not identical to everyone else’s. So when someone walks in and tells you that your SMS has to be built a very specific way, it is worth asking: says who?

The what is in the regs. The how is yours.

At its core, SMS is a loop. You need to get safety data into the system. You need to use that data to identify the risks in your operation. You need to act on what you find. And you need to promote a culture where people trust the process enough to keep feeding it.

The documentation, training, oversight, and accountability all matter. But they should support that loop, not bury it.

That is where product design matters.

If the software is hard to use, people avoid it. If the workflow does not match how the operation actually works, people create workarounds. If the system is too rigid, compliance becomes something the organization has to fight through instead of something the system helps sustain.

What sets AirTera apart is that we have product and design people building alongside aviation safety experts. That combination matters. It means the software is not built around how one person thinks an operator should work. It is built around the reality that different operators need different workflows, different risk structures, different reporting paths, different corrective action processes, and different ways of managing safety assurance.

For one operator, a hazard report may need a simple review and assignment process. For another, it may need multiple levels of evaluation, a formal risk assessment, executive visibility, and follow-up verification. Both can be valid. The software should support that difference instead of forcing both organizations through the same path.

Our customers tell us consistently that what they value most is the flexibility.

When their operation changes, their SMS can change with it. When their team grows, their workflows can grow with them. When they need to adjust how reports are routed, how risk is evaluated, how corrective actions are tracked, or how safety meetings are documented, the system can adapt.

That is not an accident. It is an architectural decision.

A lot of what is out there is “what you see is what you get.” The workflows are baked in. The assumptions are already made. And if they do not fit how you operate, you are the one expected to bend.

We built AirTera the other way around.

The platform should make compliant behavior easier to follow, easier to document, and easier to sustain. It should be intuitive enough that your team actually uses it, structured enough to support the requirements, and flexible enough to reflect the way your operation actually runs.

For Part 135 operators, that distinction matters more than it might seem.

Your operation is yours.

Your SMS should be too.