How Leon Software Provides 24/7 Support for Flight Operations

Available around the clock

Leon Support operates 24/7. Flight operations don’t stop at 5 p.m., and neither do we. Whether a dispatcher in Singapore hits a problem at 3 a.m. CET or a crew planner in São Paulo needs help on a Sunday, there is always a person on shift — not just an autoresponder promising a reply “within one business day.”

A month in numbers

To make this concrete, here’s what July 2026 looked like:

• 1,056 tickets handled
• 19 minutes — median time to the first non-automated response (a real person, not a bot acknowledgment)
• 47.4 hours — median time to ticket resolution
• 2,795 messages exchanged between Support and clients

The gap between 19 minutes and 47 hours tells its own story: a human engages quickly, but resolution often involves investigation, testing, or back-and-forth with the client — we’d rather close a ticket properly than close it fast.

What Support is responsible for

The obvious part: helping users solve problems, answering questions about how Leon works, and handling requests for configuration changes. The less obvious part is that our Support team is a full member of the product organization. Support at Leon:

• gathers requirements and analyzes real-world use cases coming from operators,
• tests new features and changes before they reach production,
• maintains and updates the product documentation,
• runs training sessions for users,
• helps integrators work with the Leon GraphQL API and reviews and accepts new integrations,
• feeds operational knowledge back into product decisions.

This is why we deliberately hire people with aviation operations backgrounds — many of our support specialists are former flight dispatchers or crew planners. When you describe a problem with FTL calculations, crew rostering, or a Journey Log workflow, the person on the other side has very likely done that job themselves.

How to reach us

The channel for all support requests is the Customer Portal at customer.leon.aero, available 24/7. It’s tied to your Leon account and organization — which, as you’ll see below, is exactly what makes fast and secure request handling possible. The official support language is English.

You may notice one channel is conspicuously missing: email. That’s deliberate — here’s why.

Authentication and authorization: why we’re strict

A significant part of how we handle requests revolves around one question: who is asking, and are they allowed to ask for this?

Every request goes through verification of both the person and the organization they represent. This may occasionally feel like friction — but it exists for a reason. In a world of phishing and social engineering, a support desk that makes account or configuration changes based on a convincing-sounding message is a security hole. Requests that affect an organization — access changes, data exports, configuration modifications — must come from someone actually authorized to make them within that organization. A user being a member of an operator does not automatically mean they can request every kind of change on its behalf.

This is also why:

We don’t accept requests by email. Email is trivially easy to spoof and gives us no reliable way to verify identity or authorization. All requests go through channels where we can confirm who you are and what your role in the organization is.

We don’t allow anonymous access to support. If we can’t establish who you are, we can’t establish what we’re allowed to do for you. It’s not gatekeeping for its own sake — it’s the same logic that stops a bank from discussing your account with a stranger on the phone.

Automation behind the scenes

When a request arrives, automated verification kicks in before a human even opens it. We automatically verify the requester’s organization and email domain against Leon itself. Combined with our support policy, this lets us instantly identify the correct handling path for a request based on its type and the requester’s permissions — without a back-and-forth of “can you confirm which company you work for?”

The result: legitimate requests move faster, and unauthorized ones are caught early.

When we say no

Some requests get declined — always for the same handful of reasons. Here’s the list, so a “no” from us never comes as a surprise:

1. Permission or access changes requested by a regular user. If you’re not an admin of your organization, we won’t grant you access to a module or reset someone else’s account — we’ll point you to your admin. Your organization decides who can do what, not us.

2. Sending organization data outside a verified channel. No data exports “to my private email, please” — no matter how plausible or urgent the request sounds. Urgency, by the way, is a classic phishing signal.

3. Organization-wide configuration changes without confirmation from an authorized person. Changes to FTL settings, integrations, or account structure — even small ones — require authorization under our support policy.

4. Skipping verification “because we know each other.” Even a long-standing client we talk to every week goes through the same checks. Consistency is the safeguard — attackers count on exceptions.

5. Disclosing account or organization information to anyone outside it. Just like a bank, we won’t even confirm which modules an organization uses to someone who isn’t its verified member.

None of this is bureaucracy or unwillingness to help — it’s compliance and security working as intended. And there’s a useful flip side: if someone claiming to be Leon Support ever doesn’t follow these rules, that’s your signal something is wrong.

No silos, no bottlenecks

The structure of the team is deliberately flat, and it’s built around one principle: any support specialist should be able to handle most requests about most areas of the application.

To make that real, the whole team trains together once a week. New features across OPS, Crew, and Sales, tricky edge cases, lessons from recent tickets — everyone gets the same knowledge. The payoff is practical: your request doesn’t sit in a queue waiting for “the one person who knows the Sales module or SCHED” to come back from holiday. Average response times go down, and single points of failure disappear.

Tech Support: the second line

Behind first-line Support sits Tech Support — engineers who assist with error analysis, deep dives into system behavior, customizations, and work with API integrators building on Leon’s GraphQL API — from schedule data exchange to flight brokerage platforms. The point of this setup is to keep the feedback loop as short as possible: when a question requires looking at how the system actually behaves under the hood, first-line Support doesn’t have to file a ticket into a distant engineering backlog and wait. The answer comes back quickly, and so does yours.

AI as a tool, not a replacement

Our team uses AI assistants with access to Leon’s public documentation, internal knowledge base, and — as a last resort — Leon’s source code itself. This means that when documentation is ambiguous about an edge case, we can check what the code actually does rather than guess. AI supports our people; it doesn’t replace them. Every answer you receive still goes through a human who understands aviation operations.

How a request flows

Putting it all together, the short version of the process looks like this: a request arrives through the Customer Portal — whether it’s a question about crew duty limits, a checklist configuration, or an integration issue — automation classifies it and confirms authorization, a support specialist picks it up (any specialist — see above), and if it needs deeper technical analysis, Tech Support joins in. Throughout, the guiding rules are the same: verify first, avoid handoffs where possible, and close the loop fast.

From ticket to feature

Support requests don’t end when the ticket closes. Beyond solving the immediate problem, our specialists look at the underlying use case — what the operator is actually trying to achieve — and recurring patterns are written up as requirements and brought into product planning. Several features in recent releases started exactly this way: as support tickets. And if a requested change can’t be built right away, it’s not a dead end — Support will often propose a workaround using existing features, while the request itself still feeds into planning.

Why it works this way

Everything above comes down to two design goals. First, remove operational silos and bottlenecks — universal specialists, flat structure, short feedback loops with Tech Support and the product team. Second, take security seriously — verified identities, authorization checks, no email requests, no anonymous access.

Sometimes the second goal means we say “no” or “please ask your admin.” We’d rather explain that occasionally than be the weak link in your organization’s security.

Written by Paweł Szmagaj, CTO of Leon Software

Not yet a member of Leon community? Contact our Sales team to find out more or jump straight into the 30-day free trial.