The FT Word – May 2003
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 May 2003 issue of the FT Word. Please forward it to colleagues you think may enjoy it.
In this month’s issue
· Reducing the backlog: a great spring-cleaning project
· “In Good Company”: a book review about how cooperation makes companies successful
· Interested in a Tech Support Skills workshop in Norfolk, VA? Sign up!
Backlog Reduction: You can do it!
Spring-cleaning fever? I’ve been thinking about backlog reduction techniques. Here are 7steps to follow to conquer even extreme backlog.
1. How big is it? How big is too big?
Except for very simple products, backlog is a fact of life since cases take multiple days or weeks to be resolved.
The best way to measure backlog is to compare it to incoming load. So if you have 500 backlogged cases and you get 250 new cases a week, you have 2 weeks worth of backlog. That would be about right if your cases take about 2 weeks to be resolved.
On the other hand, if your cases are simple and are usually resolved in a day, target a day’s worth of backlog (so 50 backlogged cases for 250 cases per week).
2. How old is it?
The size of the backlog is interesting, but the age of the cases in the backlog is more so. Say you have 500 backlogged cases, 250 new cases a week, in a high-complexity environment. I just said it was “ok” above. But what if the oldest case in the backlog is 2 months old? 6 months old?
Define aging bands for the backlog. In this high-complexity environment, I would use:
Cases newer than 2 weeks: they are probably ok
Cases under 1 month: think of each of them as a potential escalation
Cases under 2 months: they are pushing the limit, unless you are only waiting for customer confirmation to close
Cases over 2 months: these are absolutely problematic
In a low-complexity environment, you can create the same analysis but using smaller bands, say 1 day, 2 days, 1 week, etc.
Some organizations like to age backlogs based on the last contact with the customer. While I’m all in favor of frequent customer contacts, an old case is an old case and I heartily recommend using the harsher discipline of the total age of the case rather than the last customer contact.
Other organizations have a large set of case statuses so they track open cases that are undergoing “customer testing”, and exclude them from their aging analysis. Again I recommend investigating *all* cases beyond a certain age, including the ones labeled “customer testing”. It’s too easy to play with statuses.
3. Do you know where you’re going?
While all open cases should have a clear action plan, managers need to specifically check that cases older than the first aging tier have one. Hold formal reviews to review action plans for older cases. Plan to do it every week in complex environment, every day in low-complexity environments to maintain control over the backlog.
4. Just close them?
If your backlog is out of hand and you have cases that are months old, with no interaction with the customer for weeks, can you just slam them shut? Perhaps — but I wouldn’t do that. Send a quick email or have an administrative person call the customer and gently ask whether the issue is still present. It’s likely that not, but give the customer the courtesy of checking.
5. When you’re waiting on Engineering…
Some cases in the backlog are waiting for a fix, or waiting for help from Engineering. They are often the oldest, most difficult cases. Here are some practical techniques I’ve used to good effect to deal with Engineering backlog. In severe circumstances, expect to use more than one.
Present the crisis to your counterpart in Engineering and see whether a special effort can be made to mop up
Call customers back on less-severe issues and have a frank conversation on how long they will have to wait for a fix. Some may withdraw their requests.
Rework cases from the support side to find workarounds rather than require fixes
Make sure that all Engineering cases are perfectly documented
Prioritize Engineering cases again and again as customer requests change and escalations come and go
6. Brute-force, short-term techniques
If the backlog is ugly and it’s a temporary situation (that is, you have enough staff to deal with incoming cases), consider asking the support staff to work over time to close the backlog — with pay. Since overtime work will occur when customers are not in the office, there’s only so much that can be accomplished, but the time-consuming reproduction and testing work can proceed unimpeded.
You may also be able to attract non-support staffers to the task, or to hire temps.
7. Long-Term techniques
If your backlog is large and growing, short-term techniques won’t help. You can only convince your staff to work so many weekends.
Time to put your strategy hat on. Can you make changes internally to the group such as:
Hire more people?
Increase the technical skills of your existing staff?
Improve their soft skills?
Streamline the resolution process to increase productivity?
Drastically increase one-touch resolution since ongoing cases have such a high communication overhead?
Improve the way you keep the backlog down (steps 1-3)?
Would better tools help?
Leverage tools to communicate more easily with customers?
Use better tools to gather diagnostic information?
Provide more self-service support?
Do you need to reach out outside Support:
Work to increase the quality of the products? Of the documentation?
Increase the technical knowledge of customers?
Change the support offerings to minimize customer requests?
Charge more for support?
Good luck bringing your backlog down and keeping it low!
In Good Company – A Book Review
In Good Company, by Don Cohen and Laurence Prusak, is about what the authors call “social capital”, the characteristics of an organization that make cooperative action possible. Much of the book is about knowledge management rather than collaboration per se.
The best part of the book is a set of inspiring stories from various companies, from UPS to HP to NYNEX, even the IRS. The main point of the authors is that organizations that are best at fostering information sharing do so not so much through fancy systems, but rather through values and habits that are “in their DNA”. The authors reinforce many beliefs that I’ve had for a while, but could not really see validated anywhere including:
People work better in a collaborative manner if they work with people they know and like
Reorganizations break the trust and therefore delay a return to constructive collaboration
Organizations that get too close and cozy can suffer from “groupthink”, where people prefer to agree and not rock the boat rather than suggest change or criticize the way things are done
Allowing and encouraging face-to-face contacts is very important. This is a big dilemma for those of us who think telecommuting should be encouraged.
Much learning occurs through storytelling, whether of real incidents or of myths
All in all, an interesting look at what really makes knowledge sharing work. Now if we could find just one book that did not praise Jack Welch to the heavens….
Tech Support Skills Workshop in Norfolk, VA
Are you located near Norfolk, VA? One of the readers of the newsletter would like to schedule a Tech Support Skills workshop there but would need to join forces with others to fill the class. The Tech Support Skills workshop is a very popular, two-day program for support staffers that covers all areas of working with customers, from listening skills to handling difficult customers, to stress management.
If you’d like to join us in Norfolk, VA, or if you want to know more about the Tech Support Skills workshop, please drop me an email
FT Works in the News
SSPAnews published an article I wrote entitled Staffing for Web Support. You can read it at http://www.thesspa.com/sspanews/050603/article3.asp
On June 25th, I will be teaching about selecting and implementing CRM tools at San Jose State University as part of their Enterprise Management Boot Camp. Find a description of the program at http://www.ecmtraining.com/sjsu/bootcamp/
SearchCRM has asked me to present a webcast on defining CRM requirements in late July. Watch for details and logistics in next month’s newsletter.
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
About FT Works
FT Works helps technology companies create and improve their support operations. Areas of expertise include designing support offerings, creating hiring plans to recruit the right people quickly, training support staff to deliver effective support, defining and implementing support processes, selecting support tools, designing effective metrics, and support center audits. See more details at www.ftworks.com.
Subscription Information
To request a subscription, please drop us a note. The mailing list is confidential and is never shared with anyone, for any reason. To unsubscribe, click here.
