This support area keeps the commercial side clear: system requirements, setup flow, simulator compatibility, launch limits, checklist PTT behavior, and the roadmap for future aircraft coverage.
What Cabinflow is, what it does, and how the commercial portal and desktop operator work together.
Windows, simulator, internet, and account expectations before the first operational flight.
How monthly generations, checklist packages, seats, billing, and cancellations behave.
The exact order for account creation, desktop installation, license validation, and first package generation.
What each area of the desktop application does and how operators should use each control.
A full end-to-end flight workflow from portal setup to package playback and post-flight handling.
What each announcement does, who speaks it, and when it is expected during the flight.
How PTT works, how English voice commands are detected, and how native or custom checklist packages are used.
What is supported now, what is partially supported, and what still belongs to the roadmap.
Technical trigger map showing what Cabinflow detects, which audio is released, and where pauses are applied.
Answers for the most common customer questions around licensing, caching, updates, checklists, and simulator playback.
Aircraft and product layers planned after the current commercial baseline.
The product is built to separate billing, account access, licensing, and support from the local simulator execution layer. That makes the customer journey cleaner and keeps the live operational workflow focused inside the Windows desktop app.
Cabinflow is intentionally split between a web portal and a Windows desktop application. The portal handles account creation, billing, plans, license state, support content, and custom checklist package management. The desktop app handles local simulator monitoring, package generation requests, playback, checklist PTT, and live operational execution.
Cabinflow is not a generic soundboard. It prepares a structured set of captain, cabin crew, and pilot monitoring audio flows, then releases them according to simulator-side aircraft logic such as doors, beacon, altitude transitions, turbulence thresholds, and after-landing states.
Each click on Generate audio package creates one complete operational package for the active flight profile and counts as one monthly generation. Language or the number of internal audio files does not change that count. If a generation fails due to a technical system error, it should not count as a completed generation.
Cabinflow uses natural voice generation for announcements and checklist assistant playback. Files that do not depend on flight variables can be reused from cache, reducing cost and making repeat flights faster. Cache is specific to the selected language and voice context.
Cabinflow is designed as a hybrid product. Billing, access, and account management stay in the portal, while playback and simulator monitoring run locally in the desktop operator.
Cabinflow plans are based on monthly package generations and checklist package allowance, not on the raw count of internal audio files. Every individual plan currently includes one desktop seat.
Includes 20 package generations per month, one desktop seat, native checklist assistant with PTT voice command, and 2 custom checklist packages.
Includes 50 package generations per month, one desktop seat, native checklist assistant with PTT voice command, cached announcement and checklist audio, advanced automation profiles, and 8 custom checklist packages.
Includes unlimited package generations per month, one desktop seat, native checklist assistant with PTT voice command, cached announcement and checklist audio, advanced automation profiles, priority support, and 20 custom checklist packages.
One full package generation counts once per click on Generate audio package. Reprocessing the same flight manually counts again because it creates cost again. Internal files, number of announcements, and language do not multiply the count.
Custom checklist limits are based on checklist packages, not on single commands alone. A package can contain multiple checklist commands for one aircraft family, and each command can contain multiple item lines. Line limits are enforced inside the package editor.
Individual plans are designed for one desktop seat. The desktop validates both the account email and the license key. Device binding is used so one customer cannot casually share the same seat with multiple machines.
Most early issues come from doing the steps out of order. The cleanest path is account first, billing second, desktop installation third, and simulator automation only after the license has been refreshed.
Start in the web portal. Create the Cabinflow account using the email you want tied to the desktop seat and future billing records.
Select the appropriate commercial plan and complete Stripe checkout. The portal becomes the source of truth for monthly generation allowance, custom checklist quota, and subscription status.
Open the Download page and install the current desktop release on the machine that will be used for simulator playback.
Before the first flight, open the Settings page inside Cabinflow Desktop. Confirm the portal URL, user email, license key, simulator defaults, playback volume, and optional HF effects.
Use the Refresh license action so the desktop can validate the user email plus license key pair and retrieve the commercial state, current plan, renewal window, and monthly usage.
Open the dashboard, select the simulator, and test the connection before relying on automatic playback. This helps confirm that the local simulator bridge or SDK source is active.
Load a real or test flight profile, generate an audio package, and confirm that the activity log shows a successful result before flying live.
Cabinflow Desktop is the operational surface of the product. Use this section as a control-by-control guide for the interface before your first live use.
The product is intentionally split into a commercial flow and an operational flow. Use the portal first, then move into the desktop once the account and plan are already active.
Start in the web portal, create the Cabinflow account, and finish Stripe checkout before relying on the desktop for real flight operations.
Install the current Windows desktop release, launch the app, and move directly to Settings before the first live test.
Enter the same account email used in the portal plus the matching license key. Refresh the license so the desktop can load plan, status, seat state, and monthly usage.
Choose the default simulator, confirm the local simulator bridge URL if needed, and test the connection before a real flight session.
Use SimBrief import when possible, or fill the flight form manually with captain, airline, flight number, aircraft, departure, arrival, duration, language, and weather summary.
Weather summary is used for the destination-side customer messaging. Keep this field focused on arrival weather if you are entering it manually.
Confirm which announcement phases should be included. By default, operational phases are intended to stay enabled unless you have a deliberate reason to suppress one.
Click Generate audio package once and wait for completion. Do not click repeatedly, because each successful generation is a commercial generation event and the desktop now exposes loading state to avoid double clicks.
Select the checklist profile, configure the PTT hotkey, and verify whether you want to use native or custom checklist packages for the active aircraft.
Use Start auto playback for the live flight or Watch simulator only if you want to validate trigger behavior before exposing audio to the cabin flow.
Keep the log visible to confirm trigger releases, checklist voice commands, and any simulator or connectivity anomalies during the operation.
If needed, open the cache for review, save the profile for a reusable route, update the weather for another run, or generate a new package for the next flight.
A generated package is made of structured phases, each one designed for a specific moment in the flight. Some are pilot calls, some are cabin crew advisories, and each can be enabled or disabled in the flight profile before generation.
Initial passenger welcome before departure using the flight route, aircraft, airline, duration, and destination weather context.
Cabin procedure call that begins the secured departure flow when the doors-closed trigger sequence starts.
Departure cabin advisory after boarding has ended and the aircraft is moving into a secured departure state.
Full safety briefing generally associated with pushback or the dedicated pre-departure safety trigger.
Takeoff preparation command for the cabin crew when the aircraft enters the takeoff-ready phase.
Cabin ready confirmation paired with the takeoff preparation trigger.
Captain call when climbing through ten thousand feet after departure.
Passenger comfort and seat belt reminder after climb stabilization logic crosses ten thousand feet.
Cruise-phase service or comfort message once the automation engine detects a stable cruise window.
Passenger advisory used when the profile detects turbulence above the caution threshold.
Initial arrival announcement with destination weather context when descent starts.
Cabin preparation message for arrival immediately after the descent pilot call.
Landing preparation command during the arrival phase when descending through ten thousand feet.
Cabin landing-ready confirmation paired with the lower arrival trigger.
Arrival and remain seated advisory once the aircraft has landed and the after-landing state becomes valid.
Final post-arrival doors procedure call once the aircraft is parked and the beacon-off trigger confirms the shutdown arrival state.
Cabinflow now includes a native pilot monitoring workflow inside the desktop app. The user assigns a PTT hotkey, presses it, speaks the command in English, and the system matches the correct checklist for the selected aircraft family.
Checklist voice commands are recognized in English even if the operator uses a Portuguese, Spanish, French, or German airline context. This keeps the cockpit command structure consistent while the PM voice can still carry the selected accent or delivery style.
The user assigns one PTT hotkey in Settings, presses it, and then speaks a command such as preflight checklist, before start checklist, before takeoff checklist, approach checklist, or secure checklist.
The current operating concept is pilot monitoring challenge reading. Cabinflow reads the checklist item names in order and the simulator user answers manually. The system does not need to speak the response side of the checklist.
At the end of the checklist, the PM closes the flow with the checklist name followed by completed, such as Pre-flight checklist completed.
Cabinflow supports built-in checklist families and user-created custom checklist packages. The operator can choose the checklist profile manually in the desktop app instead of depending only on automatic aircraft-family matching.
Checklist lines are generated the first time they are needed and then reused from cache when they do not depend on variables. This avoids unnecessary TTS cost and keeps repeated checklist flows fast.
A custom checklist is treated as a package for one aircraft family or operational concept, not as a single standalone command only.
A package can contain multiple commands such as preflight, before takeoff, after landing, and secure, all under the same custom aircraft package.
Each package is limited by total line usage rather than only the count of command blocks. Each command title and each item line contributes to the package line budget.
Starter 20 includes 2 custom checklist packages, Pro 50 includes 8, and Unlimited includes 20. These are commercial limits tied to the active subscription tier.
Custom checklist packages are created in the commercial portal and then synchronized to the desktop app, where the operator can choose them as active checklist profiles.
If you create one Boeing 787 custom package containing many commands, it still counts as one package, not one package per individual checklist command.
Cabinflow grows by certified aircraft profiles. A simulator may be supported while individual aircraft remain in validation or roadmap until their trigger mapping and event behavior are production-ready.
This is the operational view of the automation engine. Each row shows the internal trigger name, what the desktop watches for, the typical switch or signal family behind it, which audio is released, and the pause rule applied when more than one audio belongs to the same trigger.
| Trigger | What the system detects | Typical switch / signal | Audio released | Pause behavior |
|---|---|---|---|---|
WelcomeReady | The aircraft remains on the ground and the welcome-ready signal becomes active. | Aircraft-profile signal. On Boeing profiles this is typically tied to the welcome or no-smoking gate logic. | Welcome | No extra pause |
DoorsClosed | Cabin changes from boarding or open state into secured or ready-for-departure state. | Usually door-closed or cabin-ready state from the active aircraft profile. | Door check, then Doors closed | 3 seconds between the 2 audios |
PushbackStarted / SafetyBriefing | Pushback begins, or the safety-briefing condition becomes active while still in the pre-departure flow. | Pushback active state, or dedicated safety-briefing condition in the aircraft profile. | Safety briefing | No extra pause |
BeforeTakeoff | Departure sequence enters the before-takeoff phase. | Aircraft-profile departure logic using runway, taxi, and takeoff readiness conditions. | Before takeoff - pilot, then Before takeoff - cabin crew | 4 seconds between the 2 audios |
PassingTenThousandClimb | Aircraft climbs through 10,000 ft after departure. | Altitude threshold crossing based on climb phase. | 10,000 ft climb - pilot, then 10,000 ft climb - cabin crew | 3 seconds between the 2 audios |
CabinService | Aircraft reaches the cruise-service window defined by the automation flow. | Cruise stability logic from the active profile. | Cruise service | No extra pause |
TurbulenceDetected | Turbulence rises into the caution range configured for that aircraft profile. | Profile-specific turbulence threshold based on simulator motion or air data. | Turbulence advisory | No extra pause |
DescentStarted | A meaningful descent profile begins and the arrival sequence starts. | Descent-rate and arrival-phase logic from the automation engine. | Top of descent - pilot, then Top of descent - cabin crew | 15 seconds between the 2 audios |
PassingTenThousandDescent | Aircraft descends through 10,000 ft during arrival. | Altitude threshold crossing based on descent phase. | 10,000 ft descent - pilot, then 10,000 ft descent - cabin crew | 7 seconds between the 2 audios |
AfterLandingFlapsUp | Post-landing cleanup reaches the after-landing state. | Typically flap cleanup or rollout completion logic from the aircraft profile. | After landing | No extra pause |
BeaconLightsOff | Aircraft is parked and beacon lights are switched off. | Beacon light switch state from the aircraft profile or simulator adapter. | Beacon off / doors | No extra pause |
This section is written to reduce support friction and explain the behavior that most often feels surprising during the first weeks of use.
Yes. The portal is the commercial and account layer. The desktop app is the operational and simulator layer. The product is designed around both parts working together.
One full click on Generate audio package counts as one generation. It does not matter how many internal audio files are inside that package. Reprocessing the same flight later counts again because it generates cost again.
A technical system failure should not count as a successful completed generation. The desktop and portal logic should treat only successful package creation as commercial usage.
Not necessarily. Files without flight variables can be reused from cache after the first successful generation for that language and voice context. Variable-dependent content still needs a fresh generated version for the current flight context.
The current operational focus is the arrival-side customer message. The editable weather summary in the desktop should be treated as destination weather for the announcement package.
Yes. The desktop checklist command selector allows manual checklist execution even if the user does not trigger the flow through spoken PTT recognition.
Checklist command phrases are spoken in English for consistency, such as preflight checklist, before start checklist, before takeoff checklist, approach checklist, or secure checklist.
No. The commands remain in English. What changes is the pilot monitoring voice character, accent, or language context used for playback.
Yes. The desktop app supports manual checklist profile selection so the operator can force a specific aircraft checklist package without depending only on automatic aircraft matching.
Cabinflow validates the desktop seat against both values so a customer cannot simply use someone else’s email and inherit commercial access without the matching license key.
The portal exposes the current recommended desktop version. The desktop app can check for updates and compare its installed version with the latest published release. Download and install the newest release when prompted.
Open the activity log in the desktop app. It is the primary place to confirm license state, SimBrief import, package generation, checklist recognition, trigger release, and simulator watcher behavior.
The roadmap is focused on additional aircraft adapters, more polished support content, and the future Virtual Airline commercial layer.
