Fleet readiness board
Every bike shows ready, in repair or out of service for each day, with the reason written next to it.
SIZ Group builds a bike tour manager app that gives the general manager one view of fleet readiness, guide assignments and the open jobs that could delay a departure. It is designed for the owner who needs to know, before the first group arrives, whether every tour can leave on time.
A bicycle tour company runs on a fleet that changes every day. Bikes come back with flat tyres, batteries need charging overnight and a guide booked for Tuesday calls in sick on Monday evening. A spreadsheet can record each of those facts, but it cannot tell the owner which departure is now at risk.
A bicycle tour operations dashboard connects those facts to the departures they affect. A flat tyre on a bike booked for a morning group that leaves at nine shows up as an amber departure, and the owner sees it before breakfast. The point is not tracking for its own sake. It is getting warned in time to swap a bike or a guide.
The general manager usually starts the day by checking the booking inbox, asking the workshop what is ready and phoning the lead guide to confirm the group. Each check happens in a different place, and by the time all three are finished the first riders may already be standing at the meeting point.
The breaks come at the joins. A bike marked for repair on Monday never reaches Tuesday's fleet list, an e-bike battery swap is agreed by text but never recorded and a guide's day off lives in a personal calendar. Each gap is small, yet one missed link can leave a group waiting at the depot.
The general manager will want proof that a departure is safe to confirm before the guests arrive. Agree on a test in writing, such as a bike fleet work queue item marked for repair appearing as unavailable on the next day's board, and a guide's leave request blocking that guide's tour. Run it against the real fleet count and the real guide roster.
The second check is the owner's view of the week, which should come from the bike rental reporting app. Revenue per tour type, late repairs and tours with no second guide, shown by week, are enough to decide on the next bikes or the next hire. Keep the reports short, so the owner actually reads them.
Every bike shows ready, in repair or out of service for each day, with the reason written next to it.
Tours turn amber or red when a bike, guide or vehicle is missing, and the owner is notified in time to act.
Who is leading which tour this week, with leave requests and certifications visible to the owner.
Repairs, charging and servicing jobs with an owner, a due time and a note about parts on order.
E-bike battery levels and charging schedules, so a tour is never sent out on a flat pack.
Tours run, tours changed, late repairs and open tasks, reviewed together on one page each week.
At ten past seven the general manager opens the board and sees Wednesday's four departures. The gravel loop is amber because two of its eight bikes are waiting for brake pads. The manager opens the workshop task, sees the parts are due at noon, and moves one bike from the spare pool so the group still rides.
Next, the manager checks the guide view and finds that a guide has asked for Thursday off. The board shows the Thursday city ride has no second guide, so the manager makes a tour guide assignment from the roster and the guide's phone updates at once. The owner closes the board with every departure green and saves the Monday summary for the weekly review.
Few legal rules shape a dashboard directly, but several records must stay accurate. Insurance certificates, guide certifications and vehicle or trailer paperwork all expire, so the app should show dates and warn well before they lapse. Confirm the exact requirements for your city and any trail permits with your insurer or local authority.
Be careful with rider and staff data. A dashboard can end up holding health notes, phone numbers and pay details, so each field should be restricted by role. Owners see the fleet and the tours, while guides see only their own assignments and the riders on those tours.
The main drivers are the number of bike types and depots, the number of roles that need their own view and the connections to your booking platform and payroll tool. A single depot with one bike type is a far smaller job than several depots running e-bikes, trailers and shared guides. We set those numbers during the scoping call.
Keep the scope honest by writing the first board on one page before any design starts. Each tile should answer a question the owner asks every morning. Anything that fails that test waits on the later-phase list.
It replaces the copy-and-paste work, not the judgment. Fleet and roster data can be imported from your current sheet, and the board takes over the daily checks. The owner still makes the decisions, but with the warnings already in front of them.
It can be, if the repair status is linked to the booking system. A bike flagged for repair is removed from the next available list, and any tour holding it prompts a swap. Without that link the app is only a report, so we confirm the connection during scoping.
No. A guide sees their own tours, the riders on those tours and the bikes assigned to them. The general manager sees the whole fleet and the status of every department. Named logins keep that split in place.
The board keeps its last synced state, and changes made offline are sent once the connection returns. Staff should still keep a printed copy of the day's tour list at the depot as a backup. We test the depot's signal during the build.
Book a free scoping call and we will go over your fleet board, guide roster and departure warnings, then put scope and price in writing.