I’ve been kicking around issues and ideas related to customer support and product development lately. That used to be my day job when I worked on sales and support operations and infrastructure at Google. But since leaving that job over a year ago to start my own company, I’ve focused on other things. The issues we worked on back then keep coming up though. Especially when I see those same old challenges in other companies, and when I see that the tools commonly used still haven’t plugged the gaps we filed with manual processes and work-arounds.
Now, it could be that the gaps I see just aren’t important to most people, and that’s the reason why I don’t see many solutions targeting them. Or maybe they get a bit lost in the everyday shuffle to keep up with support volumes and growth in use base. Either way, there are a few themes I think point to some worthwhile problems to solve.
Theme 1: The disconnect between support and product development
This one is ironic, since the support team talks to users every day, and product teams build for users everyday. The disconnect happens in stages as a product and a team matures, and usually ends up being a more or less latent conflict between the two teams. From the support teams you will hear complaints about how the product team is only interested in building new features, not fixing the stuff that is broken for the current users.
On the other hand, the product team feels like their time is wasted hearing about minor glitches that affect a few loud customers (and by extension loud support people). Instead of the features or optimizations that they fell will benefit all users. There are definitely tools that help teams list and prioritize issues and features, but there is still something missing.
Theme 2: Teams don’t know what users are asking
Companies know a lot (sometimes too much to do anything with it…) about how their support teams operate in terms of response time, resolution rate, agent productivity etc. But they very rarely have more than a cursory understanding of what their users are asking. The occasional unicorn of a team may have some high level tagging of the user’s issue (e.g billing vs. login questions), but even when done, it’s rarely consistent or granular enough to give any insights.
And tying those insights back to actual improvements in the product itself and in the help that is offered in contextual tips, help articles and so on is the next challenge. When this whole process works, it is usually the result of a fairly complicated process and succeeds despite, not because of, the tools used.
Theme 3: Support does not equal a ticketing system
Most support systems used by both small and large companies are, at their core, systems designed to help teams efficiently answer incoming questions whether as emails or chats. To varying degrees they also offer things like a stand-alone knowledge base, maybe a chat widgets to embed in the product, in some cases even a help widget embedded in the product which gives access to knowledge base articles. What generally characterizes most of those functionalities is that they have been added on to a core that is the ticket management system.
That is fine (at least temporarily) if efficiently replying to questions is the main concern. But for very early stage teams quality of input into product development is usually more important than resolution rate or email response time. And at later stages, the efficiency gains from making systematic improvements at the top of the user’s question path, usually outweigh any local optimization of, what should already be, a well-oiled support operation. But ops people are great at optimizing agent workflows, so they keep hammering at the nails they see.