Bike Tour Operator Software: What to Look For

01Departures: the unit your software must understand

In rental software the unit is a bike for a period of time. In tour software the unit is the departure. One departure holds a route, a date and start time, a meeting point, a price, a group size limit, a minimum, the guides and vehicles assigned to it, and the riders who have booked. Everything else in this guide hangs off that record, so test it first. If the system treats a tour as a bike hire with a longer description, it will not be able to answer the questions that matter on the day.

Three kinds of departure turn up in most tour businesses, and good bike tour scheduling software handles all three.

Recurring schedules are where time is saved or lost. You should be able to say "every Saturday and Sunday from April to October" once, and get the whole season. You should also be able to change or cancel a single date without touching the rest of the series, and move a departure that has riders booked without losing their details. Ask to see this done with real bookings on the departure, because an empty calendar hides the problems.

Bikes and pace shape the departures too. Many operators run one route as two groups, for example an e-bike group and a mountain bike group, each with its own guide, pace and price. E-bike tour operator software needs to treat the bike type as part of the booking, because it changes the fleet you need and the group you put the guest in. Mountain bike tour operator software, including what many operators call MTB tour operator software, also has to record the grade or skill level the guest has chosen, so a beginner is not sold a seat on an expert descent. A guest should be able to choose these things at booking, and you should be able to see the mix at a glance before the day.

02Capacity: four limits, and the smallest one rules

A departure is limited by several things at once. The software should work out the lowest of them and show guests only the spaces that are really left. The usual limits are:

• Guides. One guide can look after only so many riders, and your insurer, your leader award or the landowner may set the ratio.
• Bikes. Free bikes of the right type and size for that date, not just a total count.
• The shuttle. Seats in the van, and places on the bike trailer or rack.
• Anything else with a ceiling. A lunch booking, a permit, a landowner’s cap on group size, a ferry.

To see how this works, take a mountain bike day tour with invented numbers. Two guides at six riders each allow 12 riders. There are 10 suitable bikes free. The trailer carries 8 bikes. The van has 8 passenger seats, and one of them goes to the second guide, which leaves 7 for riders. The lowest of the four is 7, so that is what the guest page should offer.

Buying more bikes or hiring a third guide changes nothing for this departure. Only a bigger vehicle does, and that is the kind of fact a system should surface for you. A system that shows only the bike count would sell ten seats and leave three guests on the pavement.

The limits also move. If one of the two guides falls ill, the guide limit halves to six and the sellable number should drop with it, immediately, not when you remember to edit the departure. If a bike goes into the workshop, the same applies. Test both in a demo, and watch the spaces-left figure on the guest-facing page rather than on the admin screen.

03Guides: scheduling people, not just slots

A guide is a resource like a bike, with one difference: guides have days off, other jobs and certificates that expire. Guide scheduling software for tour operators should treat each guide as a record with three things on it.

• Availability. Days they can work, days they cannot, and the departures they are already on. The system should refuse, or at least warn, if you put one guide on two overlapping departures.
• Skills. Which routes and grades they can lead, whether they are happy leading e-bike groups, and whether they can drive the shuttle. This is what lets the system suggest only the guides who can actually run a given departure.
• Qualifications with dates. A first aid certificate, a leader award or a driving entitlement has a renewal date. Ask whether the system stores it, warns you before it lapses, and flags a departure that is staffed by someone whose certificate has expired. The renewal period depends on the awarding body, so the system should hold the date you enter instead of assuming one.

The test that matters is what happens when a guide drops out the night before. A good system marks the departure as uncovered, shows you which guides are free and qualified for that route, and lets you swap one in without re-entering the group. A poor one leaves the departure looking healthy until someone notices.

Guides also need the right information on the day. On a phone, in a van or at a trailhead, a guide should be able to see the riders on their departure, the meeting point and time, who has not signed the waiver, and any notes riders chose to share, such as an injury or a mobility need. They should see only their own departures, not your whole customer list. Ask who can see what, and whether a guide can check riders in on the spot.

If you pay guides by the day, a report of days worked per guide saves an hour at the end of every month. It is a small feature, but it is a good sign that the software was built with tour operators in mind.

04Shuttles and vans: seats, bikes and who may drive

Shuttle van capacity for tours is rarely just a seat count. A van has seats, a limited number of places for bikes on a trailer or rack, and a driver who needs the right licence. Shuttle booking software for tours has to treat the vehicle as a resource with those limits, then check every departure against them.

In practice that means the following.

• Vehicles as records. Each van or trailer has its own seats and bike places, and the system will not assign the same vehicle to two departures that overlap.
• Legs and timings. A shuttle has an outward run to the start, and often a pick-up at the finish or at a second point. The system should show the legs, the times and where riders get on and off.
• Seats shared with guides and drivers. A guide who rides in the van takes a seat that a guest cannot have. The sellable number on the booking page should already allow for that, as in the capacity example above.
• One-way and shuttle-only seats. Some operators sell a seat on the van to riders who want a lift up and a ride down. If you do, the shuttle needs its own count separate from the bikes.
• A qualified driver. The system should know which staff may drive which vehicle, so a departure is not staffed with a driver who cannot legally take the van.

That last point depends on licences, and the rules are specific. In Great Britain, gov.uk says a category B car licence covers vehicles with up to 8 passenger seats, while a D1 minibus entitlement covers up to 16 passenger seats, with trailer limits that differ by category. If a vehicle is designed to carry nine or more passengers and payment is taken for carrying them, gov.uk’s operator licensing guidance says you will usually need a PSV operator’s licence. For smaller vehicles, it says a local authority private hire or taxi licence is likely to be needed in some cases. Whether your shuttle falls under any of this depends on the vehicle and on how you charge for the transport, so ask your licensing authority or an adviser. Software cannot answer that question for you, but it should let you record who holds which entitlement.

When you test a system, ask it to put a departure of ten riders onto a van that seats eight. A good system refuses, or tells you a second vehicle is needed and what that does to the cost, which the minimum numbers section below shows.

05Minimum numbers: set a policy, then let the software enforce it

A tour with two riders can lose money, because the guide and the van cost the same whether two people turn up or seven. That is why most operators set a minimum number: the fewest riders at which a departure runs. Minimum numbers tour booking software should hold that number on each departure, count bookings against it, and tell you in good time when a departure is short.

The maths is short. Your fixed cost for a departure is what you pay whatever the group size, such as the guide and the van. Each rider adds a price and a small cost of their own, such as lunch or a hire charge. The riders you need to cover the fixed cost is the fixed cost divided by the gap between the two, rounded up.

Here C is the fixed cost of the departure, p is the price per rider and v is the cost of each extra rider.

Take invented numbers: a seat costs £75, the guide is £150 for the day, the van and fuel come to £90, and each rider costs you £10. The fixed cost is £240 and each rider adds £65, so the departure breaks even at 240 ÷ 65 = 3.7 riders, which rounds up to 4. The chart shows what that looks like for one to eight riders.

Two things stand out. Below four riders you lose money, and that is the number you would normally choose as your minimum, or a little above it to leave a margin. And capacity has a cost of its own: if the van takes seven riders, the eighth needs a second van, which brings profit down from £215 to £190. Software that knows about the vehicle limit lets you see that before you sell the seat.

What a minimum numbers policy must say

A tour minimum numbers policy needs five decisions, and the software should be able to carry out each of them.

1. 1The minimum. The number of riders below which the departure does not run.
2. 2The decision date. The last day you will make the call, and when you will tell guests. Pick it with your supplier deadlines in mind, such as a van you can cancel or a guide you can release.
3. 3What happens when you miss the minimum. Cancel and refund in full, offer another date, merge two departures, run it anyway at a higher price, or turn it into a private tour.
4. 4Who decides. The best systems show you which departures are at risk and the deadline, and let you choose. Be wary of any that cancels by itself without asking.
5. 5What guests are told, and when. The minimum and the decision date should be on the booking page before the guest pays, and the notice and the refund should follow automatically when you act.

06A 20-minute test for any demo

Do not let the demo run on a tidy example. Ask the person showing it to set up your tour, with your numbers, and then break it. Run these eight steps on every system you shortlist, including ours.

07What to avoid

The score is simple. Every step the system does for you is a point, and every step you would handle in a spreadsheet or a message is a gap. Write the gaps down, and ask how each one is planned to be fixed and when. A gap in step 3 or step 6 is worth more than a gap in step 8, because those are the two that cost you money or a guest on the day.

These are the patterns that turn into a bad Saturday. Each one is easy to spot in a demo if you know to look.

• !Avoid: Tours treated as bike hire with a longer description. If there is no departure record with a group size, a guide and a minimum, the tour logic is living in your head.
• !Avoid: Capacity as a single number you type in. If the sellable figure does not come from guides, bikes and vehicles, it will be wrong the first time one of them changes.
• !Avoid: Guides scheduled somewhere else. A separate calendar or spreadsheet that the booking system cannot see means nobody notices a gap until the day.
• !Avoid: No minimum, or an automatic cancellation you cannot approve. You need to see the at-risk departures and the deadline, and to choose what happens next.
• !Avoid: Refunds and notices done by hand. If cancelling a departure means writing to each rider yourself, you will put it off, and the guest will notice.
• !Avoid: A guide view that shows the whole customer list. Guides need their own riders and nothing more.
• !Avoid: A minimum and a cut-off hidden in the small print. They belong on the booking page, before the guest pays.
• !Avoid: Seats that are shown but not real. If the guest page can show a space that the van or the guides cannot support, you will be the one who explains it at the trailhead.

08Common questions

09Where to go next

For the wider picture of what to look for, read Bike Rental Software: The UK Buyer's Guide. If you are choosing between providers, How to Choose Bike Rental Software: 12 Questions to Ask Before You Sign covers cost, data and exit. We would like you to put RideLoop through the eight-step test above, and the features page lists what is live today, including tour departures with headcount against the minimum and a portal for guides.