In our dealings with various SaaS vendors, it is interesting to see cultural differences translating into behavioral patterns. You can fathom from the outside which functions have heft, which ones are afterthoughts, and where are the missing integration points. A behavior that I see pretty often is a good level of quality in customer support, but a failure to properly integrate it with other parts of the company. That is sub-optimal both internally for these companies, and from the perspective of the customer. Vendors miss opportunities to learn and improve, while the customer feels he’s dealing with well-meaning professionals hindered by a poorly designed organization.
In my experience two scenarios often play out that give the customer an overall “meh, whatever” feeling no matter how great the work done by support.
1. Documentation, what documentation?
File this under “great customer support interactions that I would rather have avoided.” Most of our support requests are due to documentation that is either hard to locate, inconsistent, too abstract, or out of date. I’m thankful to the customer rep who knows what they are doing and gives me a fast, accurate answer that solves my problem, but I still had to spend more time than I’d have in the case of well-maintained documentation.
Once you become familiar with a vendor, you start to see that you didn’t run into an edge case, but rather that not only documentation was poorly written and delivered from the start, but nothing is done to tap customer support and improve documentation as a continuous improvement process either. I feel for the poor reps tasked with baling out water out of a leaky boat, and net net I’m not thrilled by the vendor. Not only have they failed to properly document their product, but they are not doing anything to even start to fix it. Big missed opportunity. Use your support to detect and address deficiencies in your documentation, so even if it’s not great, it will get better incrementally.
2. For product feedback, press 5
The second common pattern that shows customer support has been set up as a silo is support responses that go something like this: “no, we don’t do this, but this is a great idea, why don’t you go and fill in this form to send it to our developers.” Huh, I don’t work there, you do, so why don’t you? Usually there’s at play a mix of lack of internal currency given to support staff (underlings paid a fraction of what developers make), and a lack of software integration in the vendor’s internal systems (i.e. their support app can’t talk to their product management app).
Either way, this compartmentalized thinking doesn’t cut it. Submitting a proper support request already felt like work, so it’s likely the mental capital and time that I wanted to allocate to the issue is already spent and at this point I just want to move on.
This does not happen with smaller startups where developers support their own product, but as organizations grow they tend to move their programmers away from front-line support. Fair enough, but don’t make me do the same customer twice, and don’t make me feel like your product team does not listen to its own support colleagues.
Bottom line: customer support is a great source of improvement ideas for your product and its documentation. Oh, and it’s also a great lead generation channel, from disgruntled customers you can win back to people toying with a free trial that good support converts to customers. But at least most software shops probably already get that part, as it’s money directly in the bank. My point is that ultimately, integration between support and product/doc also is.