How to factor the ROI of resolving customer complaints into a development schedule.
Companies have gotten much better over the last year when it comes to customer service (really, they have!). Most major online players have installed customer service CRM software that allows them to manage trouble tickets when users call in, email, or use live chat to connect with a customer service rep (CSR). Turnaround time for answering questions and solving problems is slowly decreasing, and automated systems allow simple questions to be answered automatically. Many sites (such as Dotster.com) use a help system that allows users to view their past questions and track the progress of their current inquiry.
But there are still big problems: Customer complaints aren't reflected in new products companies produce. User experiences aren't improved in the new versions of the Web sites. Though the customer service experience is better, the same problems persist, and the same questions keep getting asked.
The issue has nothing to do with the software used by the CSRs or the CSRs themselves. The problem lies much higher in the company, at the director level. In many companies, the marketing director and product development (both physical products and the Web site) director are never aware of what customers are saying or the magnitude of the problems reported.
Often, the customer service director views his job as creating the most efficient ways to solve inbound problems. What he doesn't often get a chance to do (though I am sure he wishes to) is sit down with the product development team and review the problems that generate the most calls and cost the company the most money.
Compounding this are product development egos. They think their concepts for the site are the best ideas ever. The tech staff would rather work on new projects then revisit or rewrite older (less sexy) features. The attitude can spiral all the way up the ladder. One CEO I worked with went so far as to say he knew better than his customers. He prided himself on never reading customer surveys.
Organizations must realize new product features are only useful if they serve customer needs. Customers often choose the easiest, fastest site over the sexiest. Google certainly isn't sexy, but it is simple and direct. If Google built its site with complicated Flash, used crazy visual metaphors, and had a bloated feature set (anyone from Yahoo reading this?), people would stop using it.
I know several "customer-centric" companies that only started passing customer complaints to product developers within the last year or so. In other words, they ignored their customers for 5 or 10 years.
When properly implemented, every staff member who "owns" a product or feature (e.g., a site "wish list," a product manual) should receive a comprehensive list every week that summarizes every relevant customer complaint, the channel it came from (Web, call center, etc.), and the resolution.
These product managers (with the permission of the customer service VP, of course) should actually call or email some of these customers to hear their frustration firsthand. There's nothing more effective than having the person who created a feature on your site talk to someone who wasn't able to use it.
After the weekly customer service loop has been closed, problem areas must be divided into two categories: feature fixes and feature requests.
Every company I've worked with has a master production schedule. Somewhere in the research for each feature, the tech team estimated the costs to build it, and business managers estimated all other associated costs. Added to these must be the current cost of not fixing the problem (a combination of current call center costs incurred by answering the same questions regarding the same feature repeatedly and an estimate of revenue lost because people couldn't use the feature).
When the once-hidden cost is itemized on the production schedule, it should be easy to prioritize new features and products. Everyone in the company may love the sexy new feature that should launch later in the year. But it's more likely a very unsexy bug or missing feature costs your company much more than the new feature is forecast to make.
Let's be more concrete. A general e-commerce site wants a sexy new feature that allows a user to hum a melody into the system. The site then returns the CD containing that song. Pretty cool, huh? Opportunity to sell music to people who don't remember a song's name seems like a great way to boost revenues. Compared to a mundane "shopping cart times out after one hour" problem, the new feature is a clear winner. It's certainly more headline-grabbing than a back-end software glitch.
After researching the shopping cart bug with customer service reports, a different picture emerges. The reports show 20 percent of users shop over their lunch breaks at work and are interrupted before they conclude their purchases. When they return to their computers, the shopping cart is mysteriously empty. Seventy percent of these customers get frustrated and stop using the site. Twenty percent find everything again and check out. The remaining 10 percent call customer service to find out where their carts are. Customer service spends an average of four minutes on the phone with 300 people addressing this problem, five days a week. And there's no resolution. That's 100 hours a week, or the salaries of 2.5 full-time employees.
The cost of adding more servers (to store extra data as more carts will be open simultaneously) may be high. But the company can pretty easily determine the return on investment (ROI) of buying the hardware, keeping the carts open, and reclaiming 70 percent of those lunchtime customers. It'll retain them not only for their current purchase but also for future buys because they didn't abandon the brand in frustration.
Product and feature development must include the customer feedback loop. It must include feedback not just anecdotally (hearing over the water cooler that customers are having a problem), but with real costs, projected costs, and projected lost revenue. These numbers must be added to the equation the company uses to prioritize projects. Once accomplished, you'll finally achieve many goals your company strives for: increased revenue, reduced customer service calls (and expenses), improved customer experience, and increased customer loyalty.
What more could you possibly want?
Until next time...
Jack Aaronson, CEO of The Aaronson Group and corporate lecturer, is a sought-after expert on enhanced user experiences, customer conversion, retention, and loyalty. If only a small percentage of people who arrive at your home page transact with your company (and even fewer return to transact again), Jack and his company can help. He also publishes a newsletter about multichannel marketing, personalization, user experience, and other related issues. He has keynoted most major marketing conferences around the world and regularly speaks at Shop.org and other major industry shows. You can learn more about Jack through his LinkedIn profile.
2015 Holiday Email Guide
The holidays are just around the corner. Download this whitepaper to find out how to create successful holiday email campaigns that drive engagement and revenue.
Three Ways to Make Your Big Data More Valuable
Big data holds a lot of promise for marketers, but are marketers ready to make the most of it to drive better business decisions and improve ROI? This study looks at the hidden challenges modern marketers face when trying to put big data to use.
December 2, 2015
1pm ET/ 10am PT
Wednesday, December 9, 2015
5pm HKT / 5am ET