A club that started at one airfield, then picked up a second base through a merger or expansion, rarely plans for what comes next: members at Base B booking an aircraft that's sitting at Base A, instructors double-booked across two locations, and a maintenance grounding at one site that nobody at the other site knows about until someone turns up for their lesson.
Multi-base flying club management is a specific operational problem. The scheduling logic that works fine for a single-field club breaks down fast when you add geography.
Why Two Bases Multiplies Complexity Faster Than You'd Expect
At a single base, a scheduling conflict is annoying. At two bases, it can mean a member drives 40 minutes to find their aircraft isn't there. That's the kind of experience that ends memberships.
The core issues fall into a few categories:
- Aircraft positioning. If G-ABCD flies from Base A to Base B and stays overnight, every booking system that doesn't track physical location will show it as available at A the next morning.
- Instructor allocation. An instructor based at A who teaches an occasional slot at B needs to appear available in both locations - but not double-booked across them.
- Maintenance visibility. A squawk raised at B needs to be visible to whoever does your maintenance at A, and vice versa. A grounding at one base shouldn't be invisible to the other.
- Member access rules. Some clubs restrict certain aircraft or ratings to members at a specific base. Others have open access. Either way, the policy needs to be enforced at booking time, not discovered at dispatch.
- Billing and records. When a member based at A flies from B, where does the Hobbs time land? Who invoices them? Which instructor signs the flight record?
None of these are unsolvable. But they require deliberate decisions - and a system that can actually enforce them.
Decide Your Aircraft Assignment Policy First
Before you touch any software, you need a written policy on aircraft assignment. There are broadly three models:
Home-base assignment. Each aircraft is assigned a home base. It can be flown to the other base, but it must be returned before the next booking window (or before a defined cutoff). Members booking that aircraft always know where it starts.
Floating fleet. Aircraft can be booked from whichever base they're currently at. This gives flexibility but requires real-time position tracking and a clear handoff process when an aircraft moves.
Dedicated fleet per base. Each base has its own aircraft, and cross-base use requires an explicit transfer request. Simplest to manage, but it means you can't balance utilisation across bases when demand is uneven.
Most clubs that merged end up with a hybrid - some aircraft dedicated, some floating - because that's what the merger produced. If that's you, document it explicitly. Ambiguity is where the arguments start.
Instructor Allocation Across Bases
Instructors are harder to manage than aircraft because their availability is more granular and their time has a harder constraint: they can only be in one place.
A few things to establish:
- Which base is each instructor's primary location? This affects how you publish their availability and how you handle travel time between bases.
- If an instructor teaches at both bases on the same day, what's the minimum gap between the last slot at one base and the first slot at the other? Don't leave this to the instructor's judgment - build it into the schedule.
- Who covers instructor sick calls at each base? A club with two instructors total and two bases has almost no redundancy. Know that going in.
The scheduling system needs to treat an instructor as a single resource across all bases. If you're managing two separate calendars - one per base - you will get double-bookings. It's not a question of if.
The Dispatch Problem
Dispatch at a single base is already a checklist. At two bases, you add a layer: confirming the aircraft is actually where the booking says it is.
A practical approach: require the last pilot to fly an aircraft to log its end-of-day location explicitly, not just the Hobbs out/in. If your dispatch process includes a digital release, that release should reflect the aircraft's current base, not its home base.
Weight and balance, METAR/TAF, and NOTAMs all need to be pulled for the departure airfield, which may differ from where the booking was made. This sounds obvious but it's a common gap when dispatch is handled centrally by someone at the other base.
Planebooker's 1-minute dispatch pulls METAR/TAF and NOTAMs for the relevant airfield and generates a digital release tied to the specific aircraft and departure point - which matters when your aircraft aren't all in the same place.
Maintenance Visibility Across Bases
A squawk raised at Base B needs to reach the right people immediately, regardless of where your maintenance is coordinated. If your club operates under Part-CAO (EASA Part-CAO, applicable to most EASA-registered clubs doing their own continuing airworthiness), your AMP and AD/SB tracking apply fleet-wide. A grounding triggered by an AD compliance deadline doesn't care which base the aircraft is at.
In practice, the failure mode looks like this: a member at Base B notices a snag and writes it in the paper tech log. Nobody at Base A sees it until the aircraft returns. In the meantime, two more flights happen.
Squawk reporting needs to be visible across the whole operation, not siloed by location. Whoever holds your CRS needs to be able to see the full picture. Fleet maintenance tracking that centralises squawk reports and grounding logic across all aircraft - regardless of base - closes that gap.
Member Access and Booking Rules
If your two bases have different aircraft types, different runway characteristics, or different airspace complexity, you may have legitimate reasons to restrict which members can book which aircraft at which base. A member who's only ever flown from a grass strip at Base A might not be current for the controlled airspace operations at Base B.
Build those restrictions into the booking system. Don't rely on members self-policing or on a dispatcher catching it at the last minute. The rules should be:
- Documented (in your club operations manual or equivalent)
- Enforced at booking time, not at dispatch
- Reviewable by the member so they know why they can't book a particular slot
Document expiry tracking matters here too. A member whose medical or rating has lapsed shouldn't be able to book at either base. If your system only checks expiry at one base's dispatch, you have a gap.
Billing When Members Fly Across Bases
This is where multi-base operations get administratively messy if you're not careful. Questions that need answers before they become disputes:
- If a member pays into a prepaid wallet, does that wallet work at both bases?
- If different aircraft at different bases have different hourly rates, is that clearly communicated at booking?
- Who generates the invoice - the base where the flight departed, or the base where the member is registered?
- If a flight starts at one base and ends at another (a cross-country that doesn't return), how is Hobbs time captured and invoiced?
A unified billing system that treats the whole club as one operation - regardless of base - avoids most of these. Unified billing with auto-invoicing on flight debrief means the invoice is generated from the flight record, not from a manual process that depends on which base the member happened to fly from.
A Practical Setup Checklist
If you're setting up or restructuring a multi-base operation, work through these before you open bookings:
- Write down your aircraft assignment model (home-base, floating, or dedicated per base) and publish it to members
- Define each instructor's primary base and cross-base availability rules
- Establish a minimum gap between cross-base instructor slots that accounts for travel time
- Decide how aircraft positioning is logged at end of day, and who's responsible
- Confirm that squawk reports and maintenance records are visible across both bases in real time
- Document any base-specific booking restrictions and build them into your system
- Verify that your billing setup handles cross-base flights without manual intervention
- Test your dispatch process for a flight departing the non-home base of an aircraft - does it pull the right METAR and NOTAMs?
If you can answer all of those with a clear yes, your multi-base setup is in reasonable shape. If several of them currently depend on someone remembering to do something, that's where the problems will come from.
Planebooker's multi-base support is built to handle aircraft and instructor availability across locations in a single scheduling view - conflict detection runs across all bases, not per-base in isolation. If you're in the process of setting this up and want to see how it handles your specific configuration, join the beta and we can walk through it with your fleet and roster.