The FT Word

The FT Word is a free monthly newsletter with support management tips. To subscribe, send us email with your email address. The subscription list is absolutely confidential; we never sell, rent, or give information about our subscribers. Here’s a sample.

Welcome

Welcome to the December 2004 issue of the FT Word.

In this month’s issue

· should the knowledge base be open or closed?

· disaster recovery planning

Should the knowledge base be open to all customers?

Thank you to Jason Hibbets for proposing this topic.

Most support centers these days have a knowledge base of technical solutions. And most centers know that letting customers access the knowledge base, or at least the “sanitized” portion thereof, is a good idea since it allows customers to find answers themselves, letting only the more difficult questions to be handled by the support center. But how open should the knowledge base be? Should it be open to all, restricted to customers on support contracts, or some hybrid?

It’s a business decision

There is no one answer that fits every situation. You need to make your own decision depending on your business model, your customers, and your products, but here are some guidelines.

If most customers are on support contracts, as would be the case for most enterprise products, it usually makes sense to limit access to the knowledge base to paid customers. However, think about extending access to more contacts than you would normally allow for contacting support since the marginal cost of knowledge base access is so low. For instance, if you routinely limit customers to two support contacts, you can allow four (or more!) knowledge base-only contacts. Also think about how you will support consultants and integrators that work with your products but don’t necessarily own licenses. It probably makes sense to allow them access to the knowledge base even if they don’t have a proper support contract.

If you sell support per incident and most customers are not on a support contract, consider opening knowledge base access to all customers. Since it’s unlikely you will make lots of profits from per-incident support, you’re not exactly cutting into your profit and customers will appreciate having a do-it-yourself alternative to fee-based support.

If you provide “free” support, it’s in your best interest to allow wide access to the knowledge base, without restrictions, to minimize the load on your support group. In this case, both customers and non-customers should probably be allowed to browse the knowledge base.

Finally, instead of an all-or-nothing decision you may want to choose a tiered access, where some special customers can access more documents than the general public. For instance, you may want your channel partners to have access to documents that end-users cannot see. This is a seductive idea but check that you have the need to separate levels of documents (is there a tangible difference between end-user information and channel-partner information?) and the resources to create and maintain those separate levels. Many of my clients find that the divide is simply not worth it.

Think about the registration process

Whatever level of access you decide on, it’s not unreasonable to ask users to identify themselves as they access the knowledge base. This is especially true for more complex products, where users will be willing to exchange their information for a valuable service. Also, the more advanced knowledge base services (such as subscriptions to individual documents or categories) require at least an email address. Keep the registration process as unobtrusive as possible.

The registration process can be completely automatic if you are not restricting access. If you decide to restrict access, define a process to vet users that is fast, unobtrusive to the users, and inexpensive on your end so you don’t negate the economies of scale of the knowledge base. For instance, you may grant existing technical support contacts the privilege to add additional knowledge-base contacts without having to go through your organization.

There are technological considerations

Many knowledge management tools force you to adopt either an open access or a login-protected approach. Check that your business strategy will work with your tool.

A common difficulty is accommodating multiple levels of access for customers, since most systems maintain only two levels of published documents: internal (for employees) and external (for customers). If you must accommodate multiple access levels for customers, you may find the customization requirements to be onerous.

Disaster Recovery Planning

Thank you to Terry Allen for proposing this topic.

Under the heading of “things we know we should do but don’t really want to think about”, disaster recovery planning holds a special place. If you enjoy firefighting, it’s just never urgent enough. If you like tangible results, you won’t get them, at least not in the short term. And if you live for a bit of good news, disaster recovery planning does involve thinking about disasters — it can be a downer.

But you still need to do it. Where do we start?

Make a list

Start with a list of potential disasters. The goal is to create an exhaustive list but don’t stay in the list-making mode for too long. As an example, I once spent a month of weekly meetings to get to what we thought was a solid list, including major crashes on the freeway right under our windows. The very next day, there was a suspected gas leak in the building and the local police kindly, but firmly, herded us out. That scenario was not on our list.

Work systematically; include environmental events (blizzards, earthquakes, hurricanes, etc.); equipment failures; facility problems; security threats; and people issues.

Disaster recovery planning teams spend too much time thinking about rare and catastrophic events. Don’t forget the mundane: power cuts, flu epidemics, down networks. Most disasters do not make the evening news. And the ones that do generate much compassion from customers. I remember answering phones the day after a major earthquake and having customers spontaneously propose to put their cases at the bottom of the queue when told we only had a few staff members able to come to work. Some customers called only to check that we were ok!)

Devise a simple rating system

Assign a rating for each potential disaster based on two factors: the likelihood of the event and the expected fallout. Keep it simple. Rate the likelihood of the events as likely (such as thunderstorms in Colorado), possible (a bad flu bug), or unlikely (a down network if it’s been very stable historically). Rate the impact as severe (center down for more than a day), moderate (center down for more than an hour), or low (center down for less than an hour — depending on your customers’ requirements!).

Work on likely events first, even if they do not have a severe impact. This will give you an opportunity to flex your planning muscle, and chances are that the first disaster you will encounter will indeed be one that’s likely, so the work will be immediately useful. Also, many unlikely events behave as a combination of likely events (an earthquake combines an inaccessible building with unavailable workers and down systems) so you may be able to use your “likely” plans as you plan for unlikely events — and even as the real thing if an unlikely scenario unfolds before a plan is ready.

Create recovery plan

Now to the real work: what will you do in case disaster strikes? It helps to have creative people on the team, and it helps to separate the core functions from others. In a disaster, you must improvise to maintain the core functions. So for instance, although you would never want to function like that for a long time, if the phones are working and people are there to answer them, you can provide at least emergency service. You may not be logging cases, and you won’t be emailing customers, and you certainly won’t be building your knowledge base, but you can continue to provide a core function, helping customers — for a while.

It helps to consider the different ingredients separately. People may be available even if the facility is not (if they can work out of their homes or you have an alternate location ready for them.) Systems may be available if the facility is not (so if you can borrow workstations to access the systems from elsewhere you would be ok). People without systems do quite well when it comes to troubleshooting, although logging and entitlement checking will need to be jettisoned.

Also think about the length of the outage. If the phone lines are down for 5 minutes, the best plan may be to do nothing (beyond calling the phone company to make sure the outage is temporary) If the outage is for an hour, you need to find a solution such as playing a pre-recorded message with an alternate number or at least an explanation. Most phone companies can do that for you if you plan it in advance. If the outage is for a day or more, you need to go to the next level: use another phone company perhaps, or use an alternate number that you will need to broadcast to customers somehow.

Test the recovery plan

The very best plan may be the one that doesn’t get used but do test as much as possible. The problem is that you rarely want to simulate a disaster.

Start by asking someone who is not involved in the planning process to walk through the plans. With fresh eyes it’s much easier to see the faults. Are you intending to keep working if the power’s off but the phone system is still on? It could work in the daytime, but the nighttime shift would struggle a bit. Do you expect managers to call a backup support center if the building is evacuated? Great idea, but is the phone number embedded in their brains or programmed into their cell phones? If not, they will be standing in the parking lot wondering how to translate *8023 into their cell phones. (I know, I’ve been there!)

Besides walking through the plans, you may be able to simulate smaller disasters much like we schedule fire drills. And in any case, learn as much as you can from actual disasters. Say the power went off and everyone went to paper logs as planned (good) but the beautiful templates were stored on computers and were not accessible. It’s a good lesson to either ditch the templates or provide plenty of hard copies.

Document, train, revise

Disasters know to strike when no one from the planning team is in the building. Document your plans, train the staff on what to do, and make sure any critical documents are available offsite and in hard copy.

Review plans on a regular basis, and certainly after each disaster in which they were exercised and make sure any paper copies are current. Phone lists in particular need monthly updates.

FT Works in the News

SSPA News published two articles I wrote on creating support staffing models, a popular occupation at this time of the year. They are entitled

· How Busy are You Going to be? The Science and Art of Support Forecasting. SSPA News 11/16/04 http://www.thesspa.com/sspanews/111604/article1.asp

· How many heads do I need? The Art and Science of Forecasting Support Part 2. SSPA News 11/30/04 http://www.thesspa.com/sspanews/113004/article1.asp.

Ask me for copies if you are not an SSPA member.

Curious about something? Send me your suggestions for topics and your name will appear in future newsletters. I’m thinking of doing a compilation of “tips and tricks about support metrics” in the coming months so if you have favorites, horror stories, or questions about metrics, please don’t be shy.

Regards,
Françoise Tourniaire
FT Works
www.ftworks.com
650 559 9826

Back to Newsletter Archive