Why guests and hosts kept calling support to change a trip

Trip modifications were the largest driver of inbound calls to Customer Support, and the 7th largest category across contacts of every kind, counting calls and chats, inbound and outbound. The goal handed to a newly formed product team was to bring those contacts down.

Features already existed to let guests and hosts change a trip on their own, so the question was why so many people were still calling. I reviewed the calls to find out.

I analyzed 100 inbound calls and 50 chats in the trip-modification category, working from the agent notes attached to every call, plus transcripts I generated when a call needed a closer read. I affinity-mapped them into patterns. Reading a wide set of shallow records like these shows the range of reasons people call, and roughly how that range breaks down. No recruiting, no incentives, no waiting on participants: the evidence was already sitting in the support queue.

The chats settled a scoping question early: 61% of them did nothing more than tell the user to call in. Since chat was mostly a referral step on the way to a call, I focused the depth on the calls, where the issues actually got worked through.

Three-quarters of the calls came from guests, a quarter from hosts. Almost everyone had tried to make the change in the app first and called because they couldn’t.

The same handful of failures came up over and over: a start time that could no longer be edited because it had technically passed, an extension blocked because the host had snoozed the car, a request sitting unanswered until its window closed, a whole extra day charged for moving a pickup by an hour. Call after call traced back to the same short list of product gaps.

The product was generating the calls

Reading the calls as one body let me size the causes instead of only listing them. Of the calls with an identifiable reason, here is roughly how they broke down.

The largest share, 40%, came from the product actively blocking a change someone was trying to make. Host availability, snooze periods, buffer times, and calendar blocks stopped requests from going through. A vehicle restricted for today blocked a modification on a future reservation. A start time couldn’t be edited once it had passed, even by minutes. Often the block came with an error that gave no way to recover, so a guest who might have solved it alone ended up on the phone instead.

One trip change could pull in the guest, the host, and an agent, generating several contacts before it resolved.

This was the bigger driver of volume: fewer calls started here, but each one multiplied. The request-based system needed everyone to act in real time, so one change could set off a chain of contacts before it went through. Hosts drove this especially: a host calling on a guest’s behalf usually sent the agent off to reach the guest in turn.

The way to bring the number down was to remove the back-and-forth the system required, since each fix there would prevent more than one future call.

The recommendations followed the sizing.