Is there a way to support different Knowledge Base (User Help) content for different releases?

Answered

5 Comments

  • Lester
    Comment actions Permalink

    I don’t think separate help centres would be the way to go personally. I don’t think you can have multiple help centres for a single brand, so if you wanted the multiple site approach, you’d have to create brands for each of your products and that would require giving users multiple URLS depending on what product version they were asking for help on.

    But, You can hide/show help centre sections to users based on a tag or organization.  I would investigate that.

    Essentially, each product release would have its own section in the help centre. When a user logs in, they get access to the right area. If you upgrade a user, it’s a simple case of giving them access and they see it when they refresh the page.

    3
  • Elena Barmina
    Comment actions Permalink

    Thanks a lot for your input.

    >> But, You can hide/show help centre sections to users based on a tag or organization.  I would investigate that.

    Will certainly do that.

    0
  • Maggie Ungerboeck
    Comment actions Permalink

    Hi Elena,

    We have this same situation and have struggled with this for a very long time. What we currently do is use the motto that "our Help Center documentation is applicable to the most current released version." This doesn't make those on older versions too happy though as an article could include a feature that they don't have.

    Sometimes, I will put a comment in the Comments section of an article too that says something like "updated the article with the v20.94 feature that allows you to blah, blah, blah." I don't love this either though because someone has to dig through comments to find the information.

    I've considered a few other ideas but for us, they have some big drawbacks that make them too hard to implement long term.

    • Tagging articles - this only works well if the end user searches for a specific version along with their question. They also don't see tags so if they don't use the version in their search, they could still come across an article that isn't applicable to their version.
    • Hiding/showing articles or sections based on version - this creates a lot of duplicate articles to manage. If something changed for an article in the new version, I then have to copy the article, make the change, update the permissions, etc. Considering we release twice a year, this would create a huge build up of duplicate articles. And then managing the version on the organization level gets tricky - since our customers can upgrade to a new version with out us knowing, we have no way to update their organization tag and therefore, they don't see the right content in the Help Center.
    • Creating a new "brand" for each version - same thing as above - just a lot of maintenance and different versions of the same article that creates its own challenges.
    • Adding version numbers within the article - again, a maintenance challenge. At some point, you don't want to be showing old version numbers that don't apply so then you have to go in and update articles. We have over 2000 published articles so there's no easy way to do this.

    I realize my response isn't helpful in solving your problem but I wanted you to know you aren't alone and to share what I've experienced over the years in (trying) to manage this!

    Thanks,
    Maggie

    1
  • Jessie Schutz
    Comment actions Permalink

    Thank you so much for sharing your experiences on this, Maggie! Even if some of these options don't work for you, they might for others!

    0
  • Elena Barmina
    Comment actions Permalink

    Hi Maggie,

    Thank you very much for sharing this! We are now "marking" completely new articles with the new release number - not a neat solution. When old functionality changes, I sometimes have to add new paragraphs under "Changes in Release XXX" heading to existing articles, - even less neat.

    Agree, all creative "workarounds" that come to mind (such as, for example, using brands) are challenging from maintenance standpoint and create a lot of unnecessary duplication. 

    Hopefully, we've given some ideas to Zendesk product team :)

    0

Please sign in to leave a comment.

Powered by Zendesk