Instead of looking at and understanding why customers were calling in, they decided to outsource management of support to a company that specialised in cutting down the costs.
The methods they employed had employees required to reduce the average support call duration, much like it suggests Expedia started out doing. Employees that didn't hit or beat their average call duration targets got put on a performance improvement plan, and then ultimately laid off.
That average call time was then steadily reduced in stages. It was a great success, the average call duration dropped rapidly. What was happening was employees would "accidentally" disconnect customers if they came close to the target call time. Or just randomly drop calls early on if they were worried their average was too high. Customer dissatisfaction was significantly higher. Call volume was higher (but not everyone bothered to call back). Average call duration was down though, so big success! Customer retention was getting worse, but that, of course, was tracked under a different silo by a different team who had nothing to do with the support org.
At one stage, they actually dropped the target average call duration to less time than it took to reboot a NTL router / set top box, which was the very first thing customers were advised to do by support agents. They did finally notice, then, but their only solution was to increase the time by 30 seconds or so.
Give the wrong people at the wrong level the goals, and you're going to get poor results.
Some metrics are plain wrong.
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"
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.
If there’s ever a problem, Expedia will claim time be “just a middleman” and you are screwed. I never got my money back and had to find another hotel at 11pm.
Otherwise you can just do a chargeback and claim services not rendered and you should get your money back that way.
P.S.: If you check their twitter feed, you'll know what I am talking about. It is also an engineering failure from the get-go. Not being able to retrieve your itinerary online is an engineering failure on so many levels.
At its core, it's the alignment between customer experience and product. Support as the customer facing representatives need to be empowered to convey the shortcomings of the product as it impacts customer experience. The product team in turn should then digest that information and relay it to the people building the product, the engineers in this case.
Good alignment/synergy etc. between those teams leads to good customer experience.
My support team calls it "support deflection" (in terms of how it impacts support). "Upstream solution" (from the article) is roughly equivalent, from a different perspective.
The challenge that we face as support professionals becomes existential, once we've mastered deflection. As the article points out, it is very hard to measure that type of success.
The less reliance customers have on support, the less important support is to the company's success. The less important support is to the company's success, the less support is valued.
If fewer support requests come in for an extended period, then the support team will be downsized.
If a company is around long enough, surely undervaluing support services will likely catch up with them as new features and eventually new products are rolled out, and support professionals can only hope that executives are far-sighted enough to recognize that.
The problem that I've been stuck on for a while is how to align company interests with the support team's best interests, long term. Solving customer problems "upstream" is essentially fighting against ourselves.
One of my flights was cancelled by Air France and Expedia informed me about it and offered 2 alternative flights or partial refund. To communicate my choice I had to call their support in IE or UK. This is not easy when one is in Indonesia in a remote place. They refused to communicate over email.
So I got a skype subscription and called them. I told them I wished to be refunded because none of the alternative flights offered were compatible with my schedule and they were not able to offer any other flights. They said ok but were unable to tell me how much I would get refunded. They also said I would be receiving an email confirming the refund in 2 days. I received no email, I called them back and asked if my refund choice was registered in their system and if I could get a proof of our agreement for a refund eg. via email. They assured me an email would be sent shortly. It has now been two weeks and I have so far received no refund nor any email or other proof that we have agreed on a refund nor do I know when to expect this refund or the amount.
Nevertheless, I was able to reschedule my non-refundable non-rescheduleable trip, and the support was great.
