Today I'm very excited to bring you the first of a three part series on handling customer support. We got in touch with the support teams of several of our partner services to hear their takes on how to handle tricky support situations. Some approached this from a conceptual perspective, others gave scripts for the responses they give customers, and others did a little of both to show both sides of the coin.
Today's situation is a situation we see all the time: A user asks about a feature your service does not support but may be able to in the future.
Chase Clemons of 37 signals and Support Ops:
Always be honest. It's okay to say you're not working on something. But if you are, then let the customers know. And be upfront that it's possible the feature might make it in. Try something along the lines of this:
"We haven’t added {{FEATURE}} into it yet. But I think that’s an awesome idea! In fact, we loved the idea so much we’re began working on it a short time ago. I don’t have an ETA from the team behind it yet but from their last update, I’d say we’re close to launching it."
I really like the approach of complimenting the user on their suggestion and using that as a jumping off point for the conversation. Really sets the tone for a positive interaction.
Gustav Jonsson of Podio:
"Hey (Name), This is a good suggestion. We have had other people asking about this, so this is on our (pretty long) lists. I'll share your specific use case with the team, thanks for providing it (helps a lot).
When/if we release this feature we'll get back to you, I promise.
A similar script here that does a great job of tempering the user's expectation, while still committing to giving them responsive and personal support.
Gregory Ciotti of Help Scout:
This is a situation that we encounter a lot! The first thing to remember here is that it is important to remind a customer how important their feedback is to you (regardless of if the idea gets implemented). The next thing to remember is that it is best to maintain customer expectations and not get people's hopes up by trying too hard to please.
If the idea is only on your "roadmap" so to speak, inform the customer that you think it's a great insight, that you're actively looking into the idea, but that it isn't on your plate for the next few months/weeks. Offer to add them to a list of folks who have asked, so they can be the FIRST to know if and when anything changes on the status of that feature.
If something is on deck or a soon-to-be-completed project, this part is easy: let them know they can expect it shortly, but refrain from giving an exact date, and also offer to add their email to be updated (we use Trello to do this, described in detail here)
It's best to over-deliver (or surprise them) rather than promise a specific date and fail to meet it, which is why a more generic answer of "soon" is more appropriate in this situation.
Gregory touches on a point that we at Zapier come back to often. We know what we're actively working on and will have ready soon, but we don't commit to firm dates on features. Under-promise and over-deliver, just as he says.
Mary and Ashley of Agilezen:
We are a small team here at AgileZen, and we try to be honest with ourselves about what we can and can't deliver. We are cautious to reveal any "maybes" to our users, but our internal process allows us to comfortably communicate if a feature is truly "on the way." We use our own backlog management tools to keep ourselves honest with these responses. We hardly ever offer exact date estimates, but we can often relay relative time frames to our users.
I really like the commitment to measurement from the Agilezen team here. When you're not committing to firm dates it can be easy for that to carry over to the execution of those requests, kudos to them for systematically taking steps to avoid that problem.
Lastly, we at Zapier try to communicate three things to the user in this situation: that this may be possible, a general idea of when it might be available, and where to look for news that it is available. Like the teams above we avoid firm deadlines because of the number of variables involved, but giving users a vague sense of when it might be available, as well as a link to our updates blog so they can know the instant we do have that functionality helps us to answer the request in a most thorough and efficient manner.
That's all for today, check back tomorrow when we tackle another support scenario with tips and scripts from these teams.
