I work on a hotel OTA and this and similar situations consume a disproportionate amount of our dev time, and I believe it should. So much travel software relies on third parties and problems with eventual consistency (read timeouts) mean that often either the customer is told their booking failed when it succeeded, or it fails after payment is taken.
We try to ensure that our support tools make these situations, and the resolutions, as clear as possible to our customer agents.
Ultimately, we are on the hook for this booking so it's in our interest to get it resolved for the customer so they are happy. Our stats show that this only happens to 0.5% of bookings, but if they aren't handled well, they take up a much larger amount of support time and then end up with an unhappy customer.
Over the last few years I've come realise that this is a fundamental cost of building travel software. You can't gloss over these problems or push them back on the customer, otherwise you simply won't have any customers left.
We try to ensure that our support tools make these situations, and the resolutions, as clear as possible to our customer agents.
Ultimately, we are on the hook for this booking so it's in our interest to get it resolved for the customer so they are happy. Our stats show that this only happens to 0.5% of bookings, but if they aren't handled well, they take up a much larger amount of support time and then end up with an unhappy customer.
Over the last few years I've come realise that this is a fundamental cost of building travel software. You can't gloss over these problems or push them back on the customer, otherwise you simply won't have any customers left.