Why deposits stall (and it’s rarely the client)
- The ask is vague: "we’ll invoice you" vs "pay $250 now to hold the Landcruiser and camp".
- Paying is work: bank details, a transfer, sending proof, someone matching it manually tomorrow.
- No deadline: nothing holds the rooms, so nothing motivates the client.
- No follow-up system: the balance chases live in someone’s memory.
The workflow that converts
- Quote → proposal: the client opens an interactive proposal (not an attachment) and accepts online.
- Payment request attached to the acceptance: exact deposit amount, what it holds, due date, and a pay-now button — M-Pesa STK push or card.
- Automatic matching: the payment lands against the booking; confirmation and receipt go out without a human reconciling.
- Balance tracked per booking: the system knows what’s outstanding and the request goes out before arrival, with the same one-tap payment.
- Everything visible on the shared calendar and the client’s timeline — no "did they ever pay?" messages in the team chat.
What a good payment request says
| Element | Example |
|---|---|
| Exact amount + currency | Deposit: KES 45,000 (or USD equivalent) |
| What it holds | Holds your 3-night stay at the camp and the 4×4 for 5–8 July |
| Deadline | Please pay by 20 June to keep the hold |
| One-tap method | M-Pesa prompt to your phone, or card — both live |
| What happens next | Balance due 14 days before arrival; you’ll get a request |
Timing rules we see work
- Send the payment request within minutes of acceptance — intent decays in hours.
- Peak-season deposits: shorter windows, clearer holds. Off-season: split into two smaller asks.
- Balance requests go out ahead of the arrival window, with a final-notice call task if unpaid.
All of this is the payments module in TravelBookingWidgets — deposits by M-Pesa or card matched automatically, balances tracked, requests one click away. On the Free plan, you can run your next booking through the whole flow today.