Skip to main content
  • Home
  • Product Feedback
  • Differentiate between verification ability vs. responsibility (more granular verification settings and/or verification notification settings)

What is the problem?

For many of our cards, we’d like to give a large group the ability to verify content, while still having a smaller team within that group responsible for making sure the cards stay verified. This is to more closely align with the KCS concept of “collective ownership.” To be a little more specific about our case:

  • Ideally, any support agent could (and should) verify a card whenever they use it in the course of their support work (as long as they know nothing is incorrect, of course), starting the verification interval over again and potentially even keeping frequently used cards perpetually verified.
  • For any cards that do expire or where someone specifically requests verification because something is out of date, etc., a smaller group (Docs) within the Support team would then actually be responsible for reviewing the content and verifying the card. (There shouldn’t be a bystander problem here, because the Docs team knows that they are ultimately the ones responsible and has KPIs and OKRs to meet.)

Currently, this isn’t reasonably feasible because some of the people on the Support team are also in other smaller verifier groups where they are the officially responsible verifiers for some cards (such as Escalated Support and Billing). If they’re notified about all the verification needs for all support-related cards, they won’t have an easy way to know when their cards actually need review and verification. And even anyone who’s not on one of those more specialized teams could get overwhelmed with verification notifications and maybe feel like they are responsible for all those cards. For both groups, turning off notifications entirely also has its downsides.

Who is it a problem for?

  • The larger team in this scenario, because they don’t have as much ownership over our internal KB content and always need to request verification, even if they’re seasoned support agents making edits they know are correct. Cards are also more likely to expire and appear untrusted (until the Docs team is able to get them) even if the content is just fine.
  • The smaller “responsible” team in this scenario, since their verification workload is much higher without the shared ownership and participation from the rest of the team.

How do you solve the problem today?

The relatively small Docs team is responsible for keeping most support-related cards verified. We can’t always prioritize this work over more urgent tasks, so often cards remain unverified for longer than necessary.

How would you ideally solve the problem?

I see two potential solutions:

  • Make verification settings more granular. That is, have some way to make that “ability” vs. “responsibility” distinction on a card-by-card basis. This would then flow through to whether people receive notifications for verifying a particular card, whether they’d see it in their Tasks section, etc.
  • Make verification notification settings more granular. This could look like allowing people to say, for example, “I want verification notifications for cards where the Escalated Support group is the verifier but not where the General Support group is the verifier.

 

Hi @BethAnne Freund !

We’ve just started our Guru journey, and we also use KCS for our Support team. I’m curious how you ultimately handled this situation at your organization, since you posted this a year ago. What did you finally do to handle this issue, or is it still outstanding?

We’re a small docs team of 2, so right now KCS falls entirely on the shoulders of the Support team. They’ve been trained to use KCS directly in our Help Center (powered by Zendesk) and so they create, publish, and maintain internal articles in our Help Center that customers cannot see. The Docs team focuses solely on customer-facing content at this time.

We just started using the Guru integration with Zendesk, so now every Help Center article (customer-facing and internal, for a total of 2692) is also appearing as a card in Guru. This presents its own problems - will we have to maintain verification in Guru for something we actually maintain in Zendesk? But I’m curious to know more about how you used Guru as your main source for KCS.

Thanks!

Ashley

 

 

 

 

Hey @Ashley Gordon!

Unfortunately I don’t have the answer to your main concern here, but I do have a suggestion about maintaining verification in your synced Zendesk collection in Guru. You could use the Card Manager feature to bulk set the verification interval for 1 year (or longer if you use the On a specific date feature when setting the Verification interval). That way you don’t have to worry about verification too often. Also, for cards that become unverified in the Zendesk collection (and they will become unverified if the article in Zendesk is edited), you can still use the Card Manager to bulk verify all the cards in the synced Zendesk collection. 

Hey Ashley! Nothing has really changed since I originally posted this. I’d still love to see what I requested implemented—for now, our docs team (still just me and one other person) is still the verifier for most of our cards. Support agents either make changes on their own and request verification or drop into our Slack channel to suggest the changes, then we make them and verify.

We have made an explicit decision, though, that’s related to both this situation and to (at least partially) following KCS: when we verify a card, that doesn’t mean that we’re, say, re-testing every single scenario and double-checking that everything works exactly as stated. Instead, it’s more of a “to the best of our knowledge, nothing has changed here since the last time it was reviewed” kind of thing. Two reasons here:

  1. Everyone who uses the card is responsible for at least flagging things that are out of date, not just us (even though we’re the only verifiers). If someone else used the card and noticed something that’s incorrect before we got to it, they should have corrected/flagged it.
  2. It’s not a valuable use of the docs team’s time to extensively test everything “just in case.” KCS, as I understand it, is much more about “just in time” than “just in case.”

(Note also that we have a system where support agents are embedded in product development teams and make a concerted effort to update all related internal and external documentation when there’s a new/updated feature—so most cards should be getting updated in a timely fashion, which makes us even less concerned about closely reviewing everything when we’re verifying after expiration.)

Is that helpful? Let me know if you have any other questions about how we’re handling this!

 

 

As for your synced Zendesk collection...I don’t remember how it looks when you first connect it, but if you have verification enabled for an existing collection, you can disable it so that you don’t have to worry about verifying them in Guru at all:

  1. Go to Settings > Users and Collections and then to the Collections tab.
  2. For the collection in question, click the three vertical dots and select Collection Settings.
  3. Disable the Enable Verification for this Synced Collection setting and save your changes.

(cc @Lydia Mellette, in case this is helpful for you, too!)

We also handle Zendesk Guide verification in Guide itself (we only have customer-facing documentation there), so I get wanting to keep those separate and not having to worry about double-verifying!

Thank you @BethAnne Freund for the tip on disabling the verification for our synced Zendesk collection. It really helped!

Terms & ConditionsCookie settings