Four spreadsheets became one platform.
A booking system for group climbs on Kilimanjaro that runs the whole journey, from the first deposit to the manifest the ground team prints, for the admin team and every climber.
The problem
Complex by nature.
A group climb departure takes up to fifteen climbers. One booking can hold a trip leader who is not the payer, travellers who climb, travellers who only join the safari, people the leader has added but who have not signed up yet, staggered arrivals, add-on hotels and transfers, and several people paying their own share.
All of that lived in four or more spreadsheets with macros. Trip codes were typed by hand when a deposit arrived. The sixty-day balance date was tracked by memory. Reminders for waivers, passports, insurance and flights were sent by a person. Every change had to be emailed to the ground partner in Tanzania.
The brief was simple: make the whole process run itself, for the office and for the climbers.
What I built
The whole process, automated.
The trip leader picks a departure, adds every traveller (including ghost profiles for people who have not signed up yet), chooses routes, safaris and add-ons, and sees a live total from the same pricing rules as the old calculator.
Only a paid deposit holds a seat. A public departures API feeds a small WordPress plugin that shows spots left on the marketing site and embeds the wizard there.
Stripe deposits with a 30/70 split, the balance auto-charged sixty days before arrival, split payments across several payers, organiser-pays-all, manual payment recording and itinerary change fees.
Each traveller claims their profile, uploads passport, insurance and flights, signs the waiver, and sees exactly what is still missing. Passports expiring too soon are flagged, not blocked.
Thirteen reminder types scheduled from booking and arrival dates: waivers, passports, insurance, flights, balance due, overdue, pre-trip checklist. Admins see every send and can trigger or suppress any of them.
A dashboard that mirrors the colour statuses the team already used, booking detail, trip creation, CRM views, change-request approvals and a full audit log. Finalised bookings notify the ground partner automatically.
How it went
Real software from day seven.
Spreadsheets, macros and two recorded calls became a written spec. By day seven the booking flow, portal and admin were running on real client data.
An edge-case catalogue drove the next passes: safari-only arrivals, group shrinkage, passport expiry, placeholder flights, repeat organisers, linked bookings. Acceptance tests for each.
Historic bookings migrated from the client list, the WordPress plugin installed, the ground team given read-only manifests and PDFs, admins trained on the live system.
Outcome
to a working first version
spreadsheets replaced by one system
reminder types sent without a human
Contact
Have a process like this?
Tell me how it works today. I will tell you what a few weeks could do to it.
I read every message personally and reply within one business day.