Knowledge Base and How-To articles

[codykniffen]

Problem

There are a lot of commonalities between our client environments and we do a lot of repeat work with processes. For example we push a lot of printers out with Group Policy and when we do the conversation always takes place to explain the process to whoever is setting it up this time. Often times Josh or myself just do it because we've done it in the past.

Monday Josh wrote a "how-to" on printer deployments and did a bang up job. He, Ben, and I had a brief convo on where the how-to should go. We all had ideas, but didn't have a consensus answer. We've tried Google Drive, we've tried AutoTask.....I feel like neither are great options.

Proposal

There necessarily isn't one right now, but let's all agree on where they should go 👍

[s1037989]

Great idea! I totally agree!

Isn't this the purpose of IT Glue?

Otherwise, despite it sucking, I feel like AT is the best place.

Either way, how does Keystone come to a consensus and move forward with it?

[mowgli29]

Stefan and I chatted about this. The problem is circular. Nobody takes the time to seek out internal how-to documents because there aren't many we've created. However, nobody wants to take the time to create them because we know nobody will read them!

In our brainstorming, we came up with two possible solutions. First, we could establish training around these how-to articles, making it a regular occurrence and forcing ourselves to keep producing new content. Alternatively, we could find a way to present the information to our techs that doesn't require them to change their normal workflows and routines.

Shortly after that, Jeff and Stefan were talking and Jeff came up with a killer idea! What if, when a Keystone tech searches Google, results from our own internal KB are shown first?

Here's a proof of concept from Stefan. This is how it could work: http://koogle.dev.kit.cm/

[codykniffen]

1. This is awesome.
2. Who does this reply go to?

THIS is a weird e-mail address - "Keystone-Technologies/
keystone-technologies.github.io" <
reply@reply.github.com

On Wed, Apr 6, 2016 at 8:32 AM, mowgli29 notifications@github.com wrote:

Stefan and I chatted about this. The problem is circular. Nobody takes the
time to seek out internal how-to documents because there aren't many we've
created. However, nobody wants to take the time to create them because we
know nobody will read them!

In our brainstorming, we came up with two possible solutions. First, we
could establish training around these how-to articles, making it a regular
occurrence and forcing ourselves to keep producing new content.
Alternatively, we could find a way to present the information to our techs
that doesn't require them to change their normal workflows and routines.

Shortly after that, Jeff and Stefan were talking and Jeff came up with a
killer idea! What if, when a Keystone tech searches Google, results from
our own internal KB are shown first?

Here's a proof of concept from Stefan. This is how it could work:
http://koogle.dev.kit.cm/

—
You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub
#53 (comment)

[s1037989]

KIL session notes:

There are two different things: KB and Training

Here is a workflow representing the problem / solution:

Checklist for items "close to the trunk", much like airline pilots have, despite their immense experience and expertise in flying.
Could AT tickets and ticket resolutions be the source of KB articles?
Just like Koogle, have a Keystack to front-end stackexchange.
Build our KB from public resources so we don't have to write.

• If Alice and Bob face the same problem and each google with different search queries and settle on different recommendations, then our techs are not on the same page and applying uniform fixes which could have a negative rippling effect. Introduce an Everstone (Keynote is taken) that would allow techs to clip and bookmark resources in a shared fashion (fetching.io) so that we're all on the same page and using the same resources, and when techs use our frontend tools they'll be more likely to hit the same search results as other techs that have already marked it as an answer.
• The Project / Implementation team needs to create the KB articles for the Service / Support team.
  Problem: Problem solving is fun, RTFM is not -- how do we address someone naturally preferring to try to resolve the problem by applying personal problem solving skills as opposed to searching for the Keystone way?
• Need a problem management team to turn incidents into problems write KB articles on what they find.
• 3 star difficulty and up on KB articles is a cue to have a training program developed.

Badges and other incentives with respect to training programs can be fun and help to engage techs in the process, but should we incent something that should be someone's job to just do it the way you're told (RTFM?)
Explain why we're having these training programs and expecting techs to keep up with The Keystone Way.

Possible engineering solutions:
Koogle Search Frontend
Keystone Dashboard of resources
Koogle Browser extension for greater power in searches
fetching.io
Keystone Evernote

Send out a survey to the team trying to get some feedback on the direction of these ideas. Stefan will create an initial questionnaire and run it by the members that were present for discussion. Will run it by marketing, too, as surveys seem to be their specialty.

[s1037989]

KIL session notes.

There are several questions that we discussed. We will be cleaning these up and giving them to Marketing (they don't suspect a thing yet) and eventually will release to everyone. This will likely be done with SurveyMonkey.

We won't do any analysis on the responses, we'll simply have the responses to add our discussions, so we have data to fallback on when we don't know something or speculate more than we should.