Serio Blog

Wednesday, 18 Jul 2007

This is the final post in the series about Knowledge Base content and design, and follows on from my earlier post on the subject. The earlier post expanded the quality system, this post will give an example for WidgetCo. Hopefully this will help bring all of the previous posts together!

WidgetCo Knowledge Base Quality System

Editor’s Brief

Editor: George Ritchie
Catalog Name: Desktop KB
Catalog Accepted Formats: HTML, PDF
Audience: Service Desk Staff, 2nd Line Support Technicians
Catalog Description: Contains both Incident Resolution and How-To documents for Desktop-based computers running XP and Vista.
Examples of subjects that can be covered:
Subjects covered might include resolution of common display driver problems
Troubleshoot VPN connection problems
How-To roll out a laptop from one of our ghosted images
Resetting a user password
 

Routine tasks for the Editor

Weekly: Check for new Document suggestions. These will either be emailed suggestions to you, or Incident resolved in the last week and flagged with ‘KB suggestion’. From these, produce a list of candidate new documents. Describe the document with either an Incident reference number, or a paragraph describing the subject.

Weekly: Check for document feedback through our feedback mechanisms. Make sure each respondent receives an acknowledgement where contact details are provided.

Monthly: Review the topics (search terms) that have been submitted to the Knowledge Base Engine. Look for topics that are not covered (or adequately covered) and use this to produce a list of candidate new documents.

Monthly: Send an email to all potential users giving a title and link to each new document created.

Yearly: Each document should have a ‘Review Tag’ at the bottom – for example, REVIEW2007. This is the point at which the document is to be reviewed. As reviews are performed just once a year, this kind of tag will work fine. Simply use the Knowledge Base search facility to locate documents tagged REVIEW2007, review the content, and then update the tag to say REVIEW2008 – and so on. Reviews should check documents for accuracy and relevance.

Procedures for adding a new Document

Prior to creating the document:
Check that the document is not already included in the Catalog, or any other possible Catalog. Have the document peer-reviewed by a member of the 3rd line support team if required.
Ensure that the document is accurate and on topic.
 

Reporting and KPIs

A monthly report should be submitted to the Service Delivery Manager detailing:
The number of documents created that month
Number of queries performed in total by consumers that month
Summary of user feedback
Any other issues affecting search relevance
 

Monday, 16 Jul 2007

This is a follow-up to my last post Designing a KB Quality System. In this post, I’m going to give a more detailed description of what is included.

Recall in the last post I said we wanted

  • Accuracy
  • Relevance (conformance with the Editor’s Brief)
  • Non duplication of content
  • Feedback mechanisms
  • Periodic review
  • A way for new documents to be suggested

The first 3 of those mean that it’s unlikely you’ll have a system where anyone can create a document and just add it (what I call a dumpster Knowledge Base). Of course, you could say that contributors have to check these things before adding, but this is likely to be done with just varying degrees of success – and the bigger the team the more problematic it will usually become. (As an aside, I’m not a big fan generally of anything being owned by ‘the team’).

Instead, you will have a small number (ideally 1) of Editors who will check accuracy, relevance and uniqueness before adding. There are two ways you can use Editors:

  • The Editor writes all documents based on suggestions from colleagues or content consumers
  • Or, The Editor checks documents written by others before inclusion.

My experience is that although the second option offers the prospect of more and better content, in practice you’ll need someone to lead the process and will probably end up doing the first.

You need some form of feedback mechanism. For Serio users, this will usually mean you enable the ‘rate this document’ functionality, which allows SerioWeb users to comment on documents for you, or you simply have a special ‘feedback’ email address that goes direct to the Editor. The more technical your audience, the more likely they are to report technical errors in my experience.

Periodic review does just what it says. You need to review documents every once in a while because technology changes. For example, an incompatibility between two products might be resolved, prompting either removal or updating of the document.

Finally, you need a way for content users to suggest new documents. Now, there are two ways to do this.

  • Look at what consumers are searching for.
  • Or, Ask for suggestions directly.

Looking at what search terms are being submitted, and what results are returned, is an essential activity. If you are a Serio user, please note that logging of this data is OFF by default – switch it on and you’ll be able to see all the search terms being targeted by your consumers (see ‘Monitoring search terms used’ in the HowTo guide). This will help you identify weak areas and suggest areas for improvement.

If, as an editor, you just say ‘suggest some articles!’ you probably won’t get much of a response. Instead create a simple & structured environment. For Helpdesks and Service Desks, this usually means a way to ‘flag’ Incidents at the point of closure so as to say ‘a knowledge base article for this is required’.

For Serio users, this usually means using Agent Status B (set to something like ‘KB Suggestion’) and a question like ‘Should this Incident be suggested for Knowledge Base inclusion Yes/No?’ as part of the resolution Action. All the Editor need to do is scoop these up once in a while, and decide based on the Editor’s Brief if it should be included or not.

I’ll take all this in my next post and construct a worked example.

Thursday, 12 Jul 2007

I’ve been blogging recently about Knowledge Base content. Before proceeding, I’m going to do a quick summary of what I’ve said so far.

Content is the important thing – if you don’t make a real effort to get good, useful and relevant content you are wasting your time.

Think carefully in advance about your content. Group related content into a small number of Catalogs, and then document each Catalog. Describe the target audience, and the type of documents you’ll be creating. Create a small number of example documents that will show the style and layout to be used. All of this documentation will become the Editor’s Brief.

When designing your example documents, take a little time to help your Indexing/Search system. Find out how you can help it really understand what the document is about, and then use this in your document structure.

I have a personal preference for short-ish, single subject documents. Decide if these are the kind of documents you want. Try to decide a standard document format (HTML, Word etc) and stick to it for each Catalog, and decide how one document will reference another.

Everything above will come together into an Editor’s Brief. Such documentation is a great thing to have because it will help your content stay focused over the months as your content increases. The Editor’s Brief is also useful to searchers in that it helps them understand what is likely to be in the Catalog.

If you have an Editor’s Brief, it follows that there must be an Editor somewhere, which leads me nicely onto the subject of a Quality System for your Knowledge Base content – something you are likely to need from day one.

Here’s what the Quality System will need to ensure:

  • That the documents placed into the Catalog are technically accurate
  • The documents are in accordance with the Editor’s Brief
  • New documents being added are ‘unique’ (in other word, there is not already a document that addresses the same subject matter)
  • That consumers (searchers) can give feedback, and that the feedback will be read and if needed acted upon by editors
  • Providing a mechanism for periodic review of documents.
  • That a simple mechanism exists for suggesting new documents or content

I know this sounds a bit bureaucratic, but in practice it usually works out to be a common sense approach. I'll expand on this in my next post, and will post and example quality system. 

Tuesday, 10 Jul 2007

I don't have much money to spare, and I wish the banks would make it a little harder for someone else to get what I do have writes Mark James. A few weeks back, I read a column in the IT trade press about my bank’s botched attempt to upgrade their website security and I realised that it’s not just me who thinks banks have got it all wrong… You see, the banks are caught in a dilemma between providing convenient access for their customers and keeping it secure. That sounds reasonable enough until you consider that most casual Internet users are not too hot on security and so the banks have to dumb it down a bit. Frankly, it amazes me that information like my mother’s maiden name, my date of birth, and the town where I was born are used for “security” – they are all publicly available details and if someone wanted to spoof my identity it would be pretty easy to get hold of them all! But my bank is not alone in overdressing their (rather basic) security – one of their competitors recently “made some enhancements to [their] login process, ensuring [my] money is even safer”, resulting in what I can only describe as an unmitigated user experience nightmare. First I have to remember a customer number (which can at least be stored in a cookie – not advisable on a shared-user PC) and, bizarrely, my last name (in case the customer number doesn’t uniquely identify me?). After supplying those details correctly, I’m presented with a screen similar to the one shown below: So what’s wrong with that? Well, for starters, I haven’t a clue what the last three digits of my oldest open account are so that anti-phishing question doesn’t work. Then, to avoid keystroke loggers, I have to click on the key pad buttons to enter the PIN and memorable date. That would be fair enough except that they are not in a logical order and they move around at every attempt to log in. This is more like an IQ test than a security screen (although the bank describes it as “simple”)! I could continue with the anecdotal user experience disasters but I think I’ve probably got my point across by now. Paradoxically, the answer is quite simple and in daily use by many commercial organisations. Whilst banks are sticking with single factor (something you know) login credentials for their customers, companies often use multiple factor authentication for secure remote access by employees. I have a login ID and a token which generates a seemingly random (actually highly mathematical) 6 digit number that I combine with a PIN to access my company network. It’s easy – and all it needs is knowledge of the website URL, my login ID and PIN (things that I know), together with physical access to my security token (something I have). For me, those things are easy to remember but for someone else to guess… practically impossible. I suspect the reason that the banks have stuck with their security theatre is down to cost. So, would someone please remind me, how many billions did the UK high-street banks make in profit last year? And how much money is lost in identity theft every day? A few pounds for a token doesn’t seem too expensive to me. Failing that, why not make card readers a condition of access to online banking and use the Chip and PIN system with our bank cards?

Friday, 06 Jul 2007

In my previous post, I talked about issues relating to document design for knowledge base content.

In this post I’m going to talk about optimising your document for indexing. Whilst what I’m writing applies directly to Serio users, my guess is this holds true for most content-retrieval systems.

The most import thing in a knowledge base is the content – as I’ve written before. To have something that works well (particularly with enterprise content) you don’t always need a retrieval system – for example, you could simply set-up a few web-pages that organise your content in a directory form.

However, as the number of document grows, the need for a search mechanism increases. This search mechanism often takes the form of keyword of phrase searching – pretty much like internet search engines do – returning results based on relevance.

For example, Serio uses Microsoft Indexing Service, which is a standard part of the Windows family of operating systems. When you create content, and place it into the Catalog directory you’ve created, Indexing Service ‘behind the scenes’ reads the document and indexes it. When you search for something, it uses the indices it has created to produce your list of results.

When you create your content, you can give clues to the Indexing Service as to what the document is about – not all words on the page are treated equally. The following should help the Indexing Service to return the best documents to your consumers – but you need to have an idea of keywords. By keywords, I mean the phrases or words your knowledge base consumers might use to locate your document.

  • Title. Don’t use a standard title, create documents that have an expressive, relevant titles that contain some of the keywords you think searchers will use.
  • Bolding. Bolding of certain words seems to be a factor in assigning importance to some words to over others. Use bolding intelligently by bolding key words and phrases.
  • Location of words. Keywords near the top of the document again can help some documents rank over others for certain phrases.

Wednesday, 04 Jul 2007

I recently contacted a customer – an Incident Manager – whom I'd spent some time helping with his Incident Management procedures. He told me that things were going fine, but that some staff were not calling customers back within the 1 hour target of logging Incidents set down in the SLA (or not recording they had done so), and so he'd needed to sent a couple of emails.

I was strangely pleased to hear this, as it meant he was acting as an Incident Manager should – using the weekly checklist we'd drawn up to monitor that procedures are followed and following up where they aren't.

In an earlier post my colleague George asked "So What do Incident Managers do all day?".

An Incident Manager must ensure that the Incident Management process is documented, so that service delivery staff know what it is. They must also take charge of making sure that staff are aware of these procedures for example, through training, workshops, role plays, meetings, and so forth.

But all of this effort is pointless if no-one is actually following the procedures, so as Incident Manager you need to be checking that they are.

Following a weekly Incident Manager's checklist is a simple way of ensuring that such checks are systematic and regular. In addition, checklists provide important evidence that your Incident Management processes are working. In other words, they can be a Key Performance Indicator (KPI), with which you can supplement management reports to back up your recommendations for changes. (See "Some Service Level Management (SLM) Key Performance Indicators (KPI)").

So what sort of things would you include in an Incident Manager's Weekly Checklist? To be fair, you obviously must base your checklist on the documented Incident Management procedures you are providing to your staff (for example, your Operations Manual). After all, how can you expect people to follow a procedure you've never written down?

Clearly, procedures will vary from one company to another, but the following checks are typical from my experience, and will get you started with your own list. (Tip: For the benefit of yourself and other readers, I'd recommend you format your own list as a checklist, with tick boxes and spaces for your comments):

1. Take a sample of Incidents logged by different agents during the last week. Check the quality of the Incident details logged:

  • Have all the details listed on your call logging script been captured?
  • Has the correct priority been assigned?
  • Has the correct Configuration Item (CI) been recorded?
  • Is the description of good quality? (You need to break this down further by looking at whether standard questions were asked – version number? error message? - if appropriate description templates were used, if multiple Incidents are being described in one Incident, etc.)
  • Was the Incident correctly assigned?

2. Take a sample of Incidents logged within the last week and assigned to different agents. Check that your procedures have been followed with regard to responding promptly to Incidents logged:

  • Did the assigned agent respond to the customer within the target response time set out in your SLA?
  • Did they make the response in the correct manner (for example, if you have specified that agents should try phoning the customer before sending emails, have they done this?)

3. Take a sample of Incidents resolved by different agents within the last week.

  • Is there evidence that the agent has contacted the customer to notify them of the resolution?
  • Was a good quality resolution description provided, explaining clearly how the issue was solved (not 'done' or 'I fixed it').
  • Has the correct Cause code been attributed to the Incident?

4. Look at all Incidents during the last week where the resolution target was missed. In each case, try to determine the reason and note this against the Incident.

And so forth. Your own checklist might continue with checks on whether correct escalation procedure had been followed, a review of how any Major Incidents or Complaints were handled, etc.

Monday, 02 Jul 2007

This is a follow-on from my earlier Knowledge base Structure post, where I defined something called enterprise content, looked at describing your consumers, creating Catalogs, and creating some example documents that will ‘set the style’ for the content you are going to create.

This post is all about the enterprise content documents themselves – what I think works best, and some pitfalls to avoid.

Short Documents are Best

My own preference is for concise, single topic documents. In other words, don’t create documents that address a range of issues or subjects – it’s preferable to have a document that tells you how to fix a single 'something', or do something of value to the enterprise.

Sometimes content authors sit down to write content, and end up with a longer, more comprehensive document – maybe that covers a number of errors or problems, and shows you how to resolve each.

I tend not to favour this approach, and here’s why. Content consumers will be searching – either by entering a search term, or by browsing to the document from an intranet page. The consumer will want to make a quick decision about ‘Is this document right for me?’. The longer and broader your document is, the harder that decision making becomes, and the greater likelihood that your consumer will miss the solution you’ve taken time to create.

People can also be lazy. If their search yields a number of documents, the consumer may not ‘scroll down’ and instead only read the part of the document that displays ‘naturally’. This phenomenon has been known to search marketers for years, with content you have to scroll down to being referred to as ‘below the fold’ and generally regarded as much less visited.

Think About Your Format

Word, HTML, PDF – or something else? For each Catalog try to stick to a particular format. Remember Word is not the best format if your consumers are Internet visitors.

How will Documents be Linked?

Sometimes you’ll need one knowledgebase article to reference another, maybe to supply supplemental information to the consumer. If you are using HTML as your primary format, it seems natural to create a hyperlink between the two.

This seems fine – on the face of it. However, in creating that link you’ve just increased your support burden and created a dependence between the two documents. If you move the relative locations of the two documents, or rename the linked-to document, then your link no longer works.

A better approach might be as follows. Give each document an alpha-numeric reference number that appears in the title, and tell searchers to see ‘document …. for more information’. In other words, they have to re-search for the document using the reference you’ve given them. Although it is not quite so convenient for consumers, it does mean that you are free to re-organise your content from time to time without developing broken links within your content. Any changes you make will be handled by your indexing system.

Friday, 29 Jun 2007

Tracey Caldwell asks if the time has finally come for videoconferencing in business, at least in Australia and New Zealand.

Now that we are all Green and just as importantly have to be seen to be Green, the days of executives making long journeys in fuel hungry cars or worse still aeroplanes to attend meetings should be disappearing, replaced by virtual meetings.

Videoconferencing suffered from a bad press for years. It was complex to set up and use and rarely replicated a true meeting experience with jerky images and delayed voice. The video conferencing vendors would have us believe that with today’s software and broadband speeds, all that is a thing of the past. So why is it not used very much?

Or should that be why is it not used much in business? Anyone under 16 videoconferences routinely. Of course the videoconferencing offered by MSN and Bebo is one on one. Desktop and boardroom videoconferencing are two different animals and the real challenge is replicating a meeting among several people, being able to view all or one of them, handling interruptions, being able to kick Maria from accounts under the table before she falls asleep.

In South East Asia, Australia and New Zealand, where distances between business centres dwarf those in the UK or Europe, analysts found the uptake of videoconferencing increased significantly in the last year, partly due to the falling costs of equipment. Lots of new vendors especially telephony vendors and software vendors augur well for the growth of this market, they say.

The buzz for this year Down Under is around telepresence, expensive systems which aim to give workers that in the room meeting experience, all bar the biscuits. Unified communication, linking video and audio conferencing with web conferencing and instant messaging are also high on the agenda.

China is leading the market, according to Raidah and Frost & Sullivan, accounting for 44.5 per cent of total Asia-Pacific videoconferencing revenues. The ability to link several provinces across the country has taken this market by storm according to the analysts with players like Huawei and ZTE aiming to move into other Asian countries.

Vodafone, along with other comms companies, knows it should be taking a lead on greener meetings. It has announced it now requires that the alternative of using videoconferencing is considered before travel is approved. There were “air hostesses” at the recent launch of its videoconferencing initiative and a number of posters suggesting “Spend more time with your family”, presumably what cabin crew will be doing once the corporate muscle of Vodafone is flexed.

Google has caught the wave, buying up the flagship software product of video-conferencing start-up Marratech, leading people to believe that conferencing software may become the next addition to Google's office suite.

Google says it is excited about acquiring Marratech’s video conferencing software, which it says “will enable from-the-desktop participation for Googlers in video conference meetings wherever there’s an Internet connection”. I am loving the calendar, not so keen on the spreadsheet. It will be interesting to see what Google makes of videoconferencing as a desktop app.

A report from Cisco, vendor of the £150,000 plus per site Telepresence videoconferencing kit points out that the uptake of videoconferencing is not all about the technology.

Cisco-commissioned report “The Psychology of Effective Business Communications in Geographically Dispersed Teams”, points out that although richer media such as video conferencing helps build teams, it still takes two weeks longer building relationships through videoconferencing than through F2F (face to face, great acronym).

The report recommends using videoconferencing at the beginning of a project, reverting to instant messaging when everyone knows each other. With videoconferencing sounding a bit like a very expensive curry night it is hard to believe that the time is very ripe for this technology. Please see the attached Cisco-comissioned report.

Thursday, 28 Jun 2007

In this post, I’m going to continue talking about Knowledge base content – I started this thread here, and added a diversion thread here.

I’m going to write about content you write or create yourself, which is about many of the specific things you have to do, and some of the issues that arise when trying to create content of this kind. I’ll refer to this as enterprise content – as it’s (usually) unique to a given company or organisation.

Getting Started

The first thing you need to do is decide who the consumers of your enterprise content are, because this will influence the nature of the content, it’s presentation, and it’s availability. I usually ask clients I’m working with to write down a single paragraph about each type of consumer, covering the expected level of expertise, and examples of the information they may be looking for. This then goes on to become part of the editor’s brief (more of which in later posts).

Grouping the content

Next what you should do is to stream or classify the content you wish to create. Unless you plan on having just a handful of documents, it is worth avoiding a ‘skip’ or ‘dumpster’ mentality where lots of unrelated content is thrown in together. Organising your content correctly at the start means your knowledge base can ‘scale’ correctly over time.

There are lots of ways to do this.

By document type. Examples might be:

  • Fault resolution: Documents that tell people how to resolve common faults.
  • How-to documents: These tell people how to perform common tasks that are not faults per-se, such as how to apply a service pack, deploy a ghosted workstation, order a new computer.
  • Bugs: A place where bugs or known errors and workarounds are listed

By subject matter. Examples might be:

  • Documents relating to operating system software
  • Documents relating to desktop software
  • Documents relating to hardware configuration

Which works best for you will depend on what type of company you are. If you make and sell specific hardware or software product, it might make sense to organise your content by product. If you are involved is more general IT support, it might make more sense to group by content type. Make sure the grouping will be understood easily by your consumers.

Serio refers to groupings of content like this as a Catalog. Unless you plan to have many thousands of documents, keep the number of Catalogs to as small a number as possible, particularly at the start. Too many does not help consumers, it confuses them.

Design Some Example Content

So far, we’ve got a picture of our consumer, and we’ve applied a simple organisation to our content. Now you need to write some example documents – not many, 3 or 4 in each Catalog should be fine. Here you’ll define the layout and, by example, the tone and style of the documents you’d like to see.

I’ll post next week on how to design a ‘good’ document (a totally subjective opinion I know) and how to create a quality system. I’ll also post some info on how you can ‘optimise’ documents for the indexing service that Serio uses.

Monday, 25 Jun 2007

This is a follow-up and continuation of last weeks Knowledge base Content post. In writing this post it veered some way from my chosen topic, hence it’s posted under Technology, but it’s something I think it’s worth writing about – combining both local and specific internet search results in a single relevance-based list.

Third-party content

Third-party content is often taken directly from, or derived from, trouble-ticket data (I discussed trouble-ticket [Incident] data last week). I’m describing it here because it’s a type of content you don’t control. Typically hardware and software vendors publish this kind of content for the benefit of their customers. Sometimes the content is free, other times it's restricted and paid for (The Serio knowledge base is found here).

Third-party content presents some interesting challenges, the most important of which is integration when the content exists on an Internet website. I’m going to discuss these challenges here, as this is something I’ve been asked about before.

In an ideal world you’d set-up your own knowledge base, and simply ‘add-in’ third-party knowledge base sources – so that when you do a search, you can search at the same time:

your local content (your own trouble-ticket data and documents),
the knowledge base directory at vendor A,
the knowledge base directory at vendor B and so on.. 

and have a single, consolidated results list based on relevance.

It sounds great, but is very difficult (impossible?) to implement at this time. In a nutshell, if the content exists on another site you can either:

  • Spider the content yourself, like a search engine does. However, webmasters have a habit of banning spiders they don’t recognise or which operate without permission on their websites, so as to conserve bandwidth for real users
  • Ask the remote website to query it’s own content for you – but this presents problems when constructing a single results list based on relevance because your own knowledge base software cannot see the actual document (ie, does a remote document rank above or below a local, private document).

So, like I said, it’s technically demanding – even leaving aside the ‘terms of service’ issues that arise when using the content of another ogranisation.

Tip: If you are a Serio user, there is something you can do – add your best external knowledge base sources to your ‘Useful Links’ chapter (see ‘Useful Links’ in the HowTo guide for more information).

Probably the best hope for solving the problem I’m describing lies with major search engines such as Yahoo! and Google. What they need to do is allow searchers to set-up customised pages that restrict the searching to particular points within sites (where the KB content is specifically, not just a particular URL) and let the search engine perform consolidated search for you based on your choices.

However, for this to solve the problem search engines would need to see your own local (trouble ticket) content, and would need to understand this is private and not to be served to other searchers. The search engines could either fund this by a fee, or by advertising as now.

I'll come back to the 'proper' thread of these posts later in the week.

Pages