Using internal and external feedback to improve your Help Center

  • 15 October 2021
  • 1 reply
  • 46 views

Userlevel 3
Badge

Hey everyone 👋🏻

How do you capture customer and internal feedback to help improve your Help Center?

At Guru, I work with our Technical Support Team to manage and update all of our Help Center documentation. We capture feedback through:

  1. an internal Asana form for employees to submit new ideas, flag typos, and suggest edits

  2. new feature releases

    1. We collaborate with our Product Managers and Product Marketing Managers to update documentation before any major product launch

  3. implicit signals from customers

    1. We use Intercom Articles for our Help Center. Their reporting feature to captures article views and overall satisfaction for articles, which we analyze on a monthly basis to inform improvements.

    2. However, we don't capture explicit feedback or comments about our Help Center usefulness. Intercom has a thumbs up/thumbs down feature, but we can't capture comments on articles themselves.

How do you all improve your Help Center usefulness? I'm curious to hear if Guru's tactics resonate with you all or if there are other inputs you all use

@Maddie Rish @Alicia Lane Do either of you have any insight here? 


1 reply

Userlevel 3
Badge +1

I’m a liiiiittle late here, but in case it’s helpful to anyone who comes across this thread in the future…

 

External feedback

For our public-facing help center we use Zendesk Guide, which also only comes up with yes/no voting. Our devs worked some magic and added a comment field that appears after a reader has voted, and the answers go to a third-party form service (Pageclip) for us to review as needed.

Of course, both the votes and the comments have to be taken with a grain of salt. Plenty of people still don’t leave any context about their votes, so they could’ve voted “no” (the article wasn’t helpful) because they’re upset we don’t have a particular feature, or because they’re looking for really specific information that actually doesn’t make sense to have in a general help center (they’d be better served writing in to support), or because they’re experiencing a temporary bug, or just because they’re grumpy that day. Even the comments often aren’t actionable. BUT some of them are, and the overall votes still help us see outliers and trends that can guide our work, so we’re keeping both aspects around!

 

Internal feedback

For now, we mostly just ask people to stop by our #docs Slack channel with requests and suggestions. Whoever sees the message first can then either take action on it right away, add it as a to-do in our Docs team’s Basecamp project (if it should be done soon but they don’t have time in that moment), or add it to our backlog in Trello (if it can wait until our next “crush the backlog” period).

I’d love to formalize the process a little more, though, and set up a form or something like that. We’re still figuring out some of the logistical details of how our Docs team works!

 

(For a little bit of context on this point and the next one, our Docs team consists mostly of frontline support team members who do docs work when they’re not in the queue. I’m the only one who’s on our docs full time.)

 

Updating for new/updated features

Our company as a whole works on a cycle basis, and for any project that will likely involve docs updates, we embed someone from the Docs team on that squad. They’re involved from the beginning and attend meetings, follow along in the Basecamp project, etc. This way, they understand really well how the feature works, what the expected timeline is, etc. and can start crafting updates from early on.

Reply