Reducing customer service call volume at Expedia

For example, if 58% of your customers are calling in to have their itineraries resent, that's awesome for the company because that's a lotta volume (and volume is money!) and it's really easy to hit KPIs for call length, satisfaction etc. They are thus doubly negatively incentivized not to do any upstream resolution: not only would they get paid less, but all their KPIs would plummet, because the remaining calls are now on average harder to resolve, take longer, and have more grumpy customers leaving bad CSAT scores!

I have a particularly complex set of service combinations with T-Mobile. Any changes to my account configuration or devices can result in downstream breakages, especially when one promo crowds out another.

I used towork in support, and I was the first person in the company to carry the title Advanced Support Engineer. I know the initiative and the depth of knowledge it takes to be a truly effective support engineer. I have been consistently impressed by the personnel in T-Mobile's Eugene, Oregon support operation, which I tend to encounter when calling during conventional business hours in my time zone.

in contrast, the overseas support operation that I land on if calling off hours has been worse than useless, so much so that I generally give up and live with whatever breakage has occurred until business hours if it all possible. They are just that bad. They may execute the most basic, redundant, rote solutions, generally, but they demonstrate no discomfort in flat lying about both solutions and what steps they've taken... especially account credits. One of these screwups was so severe that it took a dedicated rep in Oregon hours of research and numerous tasks spanning a week to repair (plus follow-up three weeks later to make sure the fixes "took").

It's absolutely night and day -- awesome or excruciating.

I used to work for an ISP. Some genius high up in the support management chain decided that tickets were taking too long to resolve, and the touch rate was too high. So they implemented a way to measure how many times a ticket communicated on before it was resolved, and somehow turned that in to what they called a "conversion percentage". Percentage of what was never expressed.

The result, naturally, is that customers started talking to a void. Tickets took longer to resolve because the support engineers would waste time not asking clarifying questions because that would hurt their conversion percentage. Customer dissatisfaction soared.

A week or two after it went live, some engineers in the NOC team figured out that if you took a ticket, resolved it, and then re-opened it, you'd hit a 100% conversion rate, regardless of how you then communicated on it. Slowly but surely that started spreading through the company and things pretty much got back on track and customer satisfaction returned.

When I left, they were still tracking that conversion percentage, even though every support engineer was now taught during on-boarding that the way to handle a ticket was to resolve it and re-open it. Firmly on its way to becoming "it's just the way things are done"