One person in the group wants their money back.

It always starts as a small, reasonable email. Someone in a group of eight has had to drop out. Work thing, family thing, doesn't matter. They want their money back, and fair enough — they're owed it. You go to sort it, and that's when you notice the booking doesn't really belong to one person. It belongs to a organiser, three deposits, two top-up payments from different cards, and one instalment that came in from someone's partner because the original card had expired. Somewhere in that mess is the answer to "how much does this one person get back", and it is not obvious.

Here's the bit that catches people out: by the time someone asks for a refund, their money usually isn't in your account any more. It's gone out as a deposit to the coach company, the venue, the accommodation block — booked and paid for on the assumption that eight people were coming, not seven. So the refund isn't really a refund. It's a decision. Do you eat the cost of the empty seat? Do you claw it back from the supplier, who has their own cancellation terms and no interest in your group dynamics? Do you quietly redistribute it across the remaining seven so the maths still works?

We used to make that decision fresh every time, on the phone, under pressure, with someone waiting for an answer. It's a bad way to run a business, not because the decisions were wrong, but because nobody had agreed the policy in a calm moment — so every refund became a negotiation with ourselves.

The other thing group bookings do is scramble who paid for what. The organiser often fronts the deposit and gets reimbursed by the group later, off-platform, in a WhatsApp chat you'll never see. So when someone drops out, the instinct is to refund them directly — except they might not be the one who actually paid in. You end up refunding the wrong person, or refunding correctly but confusing everyone, because your system only ever recorded "booking paid", not "who paid how much, when, on what card, for whose seat".

That level of detail feels like overkill until the day you need it. Then it's the only thing that matters, and if you don't have it, you're reconstructing it from bank statements and memory while a customer waits.

The fix isn't a refund policy on a PDF nobody reads. It's a ledger that follows the money at the level of the individual payment, not the booking — who paid it, which seat it was against, and which supplier commitment it had already funded. Once that exists, a partial cancellation stops being a scramble. The system can tell you, before you've even picked up the phone, exactly what's recoverable, what's already spent, and what the fair number is. The conversation with the customer gets shorter and the answer gets more consistent, because it isn't being invented under pressure any more.

None of this shows up in a demo. It only shows up on the day someone drops out of a group booking three weeks before departure, and by then you either have the answer or you're building it live. If your booking system can tell you who booked but not who actually paid what and when, that's worth a proper look before it costs you a refund you can't quite justify. Happy to have that conversation if it's useful.