Knowledgebase implementation: overview, examples, best practice, tips and tricks
Agenda
- Implementation
- Browsers Vs. Searchers
- Content Vs. Knowledge
- Defining Knowledge
- The Knowledge Cycle
- Best Practice, Tips & Tricks
Implementation
- Avoid big bang implementation approach
- Crawling / indexing / spidering all content may not be useful
- Re-author is better than than migrating large document repositories
- Leverage out-of-the-box functionality wherever possible
Implementation: Tasks and Activities - Foundational Activities
When delivering a knowledgebase there's a range of tasks and activities carried out before we get into the customer-facing work. As with all projects, getting the foundational tasks makes the rest of the delivery easy.
- Design
- System Setup
- Customer enablement (and change management)
- Knowledge strategy
- Migration / re-authoring strategy
- Product awareness
Implementation: Tasks and Activities - Core Tasks
The core tasks follow our foundational tasks, and here we make the decisions that state the direction that the knowledgebase will go. Often, these decisions are irreversible and need to be taken with care.
- Search configuration
- Dictionary
- Document types
- Products & Categories
- Branding & Templates
- Navigation sets
- Pages & Workspaces
- Workflows
- Profiles & Users (Security)
Implementation: Tasks and Activities - Customisation Tasks & Activities
Once we've our foundational tasks underway and our core tasks are either complete or we've the end-state in view we can extend the knowledgebase with some customisation activities.
- Extending existing customisations
- External Customisation
- Integration
- External content crawling
- Single sign-on
- Content migration
Implementation: Workflow examples
The knowledgebase should never directly publish content without some review, and here's some common workflow examples.
- Advanced approval/change request
- Alerts / announcements
- Document change / new document request
- Document approval
- Document review
- Escalation
- Feedback
Implementation: Role Examples
One of the main advantages of a knowledgebase is its capacity to serve a broad audience. To push content to our audience we can often do this very quickly with few steps before publication. However, some content can get very technical and we might need some oversight. A knowledgebase will need roles in support of publication to ensure that our article is accurate.
- Document owners
- Policy / governance / legal owners
- Subject matter experts
- Document editors
- Approvers
- Publishers
- Internal users
- External users (if appropriate)
Implementation: User Interface Examples
The knowledgebase can be surfaced in a number of ways, and we term this 'knowledge at the point of action' (KAPA). This means we're getting our articles to our audience at the time and place they need them. Here are some common places we're going to interface with our knowledgebase.
- Feedback
- Subscription
- Announcements
- Updates
- Notifications
- Alerts
- Reporting
Background: Browsers Vs. Searchers
Some people prefer to find their own way. They like to make their own choices based on what they see, such as using Google.
Some people look for guidance to find answers. They like to be offered a choice, such as Amazon.
The design language will often dictate how the site is used. With Google we expect to see page after page of results. Amazon will give us recommendations based on what we’ve searched. eBay tries to both search and categorise content. Netflix offers lots of categories for us to pick from.
What will be our design language?
Browsers
- Happy to go on a journey
- Lots of clicks are a good thing
- Navigation is important
- Categorisation needs to be reflective of expectation
Searchers
- Looking for a quick hit
- Three-click rule applies
- Search text gives important insights into writing ability
- Metadata and keywords are important
Background: Content Vs. knowledge
What's the difference between content and knowledge?
- Content is the cake
- Knowledge is how to bake the cake
Background: Defining Knowledge
- Empirical
- Bite Sized (write for people’s attention span)
- Discovered; highly searchable
- Remove the emotive
- Look for insights
- Don’t be all things to all people
- Know your audience
Background: The Knowledge Cycle
How do I grow my knowledgebase?
- How many answers do I need?
- How long should an answer be?
- How do people consume the knowledge?
- What writing standards should I have?
- Your best endeavour is okay if you’ve no statistics to support a decision
- Don’t be afraid to remove documents that aren’t relevant
- Be prepared to make changes
- Use notifications, subscriptions and announcements effectively
Best practice, tips and tricks
Seeding a knowledgebase and sowing results
- It is better to implement a poor knowledgebase and improve than wait for a great knowledgebase and leave users without answers.
- Analytics will not only tell you not only what the audience found but what they’ve not found.
- If you’re not getting enough hits, then the analytics will be poor.
- Never be afraid to change the design and measure improvement. Equally, never be afraid to change the design back if the statistics show that there was no improvement.
- Try taking people who browse on a journey. A good rule of thumb would be 3-5 visitor actions for every 1 visitor.
- You can manually adjust for a lack of interest, but you’ll need at least 2000 visitors a day to get actionable data.
- Be driven by statistics not speculation.
- Knowledge is a bite-sized piece of information.
- Make your content both informative and interesting.
- Make the top 10 answers the best they can be.
- We’re aiming to be like the Amazon not a search engine or a news website.
- Know your audience with readability statistics.
- Pick a writing style and standard.
- There is no perfect answer to a question, but statistically you should be able to determine which one works best.
Any Questions?
Mark Kehoe
Knowledgebase Consultant
m 0487 335311
e mark.kehoe@outlook.com
t @mark.a.kehoe