Skip to main content

We are getting ready to implement Guru in a phased approach across our ~350 person remote/distributed company. I’m curious how other folks are helping to define for their users what should and should not go in to their Guru knowledge base? For example, we don’t want users to save meeting minutes in Guru, as meetings and other in-progress work is not authoritative/definitive. What guidance do folk give their users to help make it clear what should and shouldn’t be in Guru? TIA!!!!

Hi Lynn. I’m a Customer Success Manager here at Guru and wanted to give one idea.

I’ve noticed is that some customers do keep meeting records/minutes in Guru. It would typically be just 1 card, with a historical log, with the goal of allowing users to self-serve past meetings that they have missed. We do this at Guru for our Revenue and Company-wide All Hands, and it’s extremely helpful!

I am sure others will chime in with their various governance standards to spark ideas 😄


Hey Lynn!  I think about this a lot as I’m going through our collections:

  • KCS has a philosophy that “80% of the tickets are solved by 20% of the knowledge articles.” The question I often ask is “What is the information that needs to/is ready to be known?” and use that as a way to guide the mindmapping with teams on what belongs in Guru vs. can stay in a doc/Drive.
  • There’s also an opportunity, especially for go-to-market functions and workflows, to think about where knowledge documentation and sharing fits, as, to your point, I might be crafting a Product Brief for development (which happens at the beginning of the workflow), but what needs to be known is the Help Center documentation and go-to-market materials (Marketing material, Sales/CS talk tracks, etc.) that come later.
  • There’s also approaching it from “What are the questions your team gets asked that you’d love to be able to answer with a Guru card?” This helps with the “What needs to be known” bit.

Hope this helps!


Reply