The Autodesk support organization defines a set of “support principles” that establish a baseline for quality service. The principles are supposed to be straight-forward, common-sense guidelines such as:

• Provide credible and timely responses
• Make and honor commitments
• Confirm resolution
• Document cases
• Communicate professionally
• Escalate immediately

We do weekly review of randomly-selected cases for principle compliance, and the review scores are a lead measure of our success. They’re a lead measure because management considers principle compliance a predictor of success (where success is measured by the quarterly Net Promoter Score aka customer satisfaction).

In practice, you can go around in endless circles discussing what these principles actually mean. I’ve sat through whole meetings where we never got past the first definition of the first principle.

Based on my experience on the front-line, here’s my take on the principles. I’ve reduced the principles to single-sentence bullet points with [I think] plain English words.

• Respond quickly with either a solution or some questions that clarify the problem.
• Let the customer know when you’ll get back to them, and do what you promise.
• Don’t let cases sit inactive for over 2 days: if you’re waiting for information, follow up with the customer; if you’re researching the problem, let the customer know what’s happening.
• Document cases so that others can understand the problem and the solution.
• Communicate like a pro: clear, concise, easy to understand, and with the same tone you would expect from others.
• Don’t delay–when you tell a customer you’re going to escalate or transfer the case, do it right away.

Here’s a word cloud I generated from the summary and description fields of the Softimage support cases that came in so far this year. The word cloud shows the top 50 words (after I manually removed words like “Softimage”, “using”, “hello”, and others). I did about 30 search-and-replaces to get rid of words that weren’t feature-related, but there’s still some, like “attached”, left in the cloud.

After a few abortive attempts at time-tracking, we’re rolling out a new time-tracking system here in product support. One of the main goals it to understand how much time specialists spend on “reactive” events (responding to support requests) versus “proactive” events (writing KB articles, developing training, blogging, and manning the forums).

The difficulty for me with time tracking is that these days my time and effort is so interrupt-driven. For example, I’ll be drafting a blog post when I see a new scripting question on the mailing list. So I jump on that to try and answer before someone else does 😉 But then one of my support cases is updated, so I jump on that and reply.

Meanwhile a new case comes in, so I take that and start research. Then maybe I have a meeting, or someone needs me to explain how to do something in our help desk system (I’m the local superuser). Eventually I rewind back through everything, possibly being interrupted again at any time. Or being distracted by my almost compulsive checking of my email inbox and the support incoming queue;-)

I admit this may not sound like the best way to work, but it works for me. I know many others on the support team prefer to handle one thing at a time.

I’ve found I need some utility, like the one in the screenshot, that allows me to have multiple timers going. That way I can accurately keep track of what I’m doing.

A company’s product support model can be visualized as a funnel.

For every N customers who need help, only a subset will require direct one-on-one support

• At the top of the funnel is the self-service component, where you hope the majority of users can find their answers. Ideally, there’s a support portal that brings together documentation, KBs, FAQs, blogs, forums, videos, and tutorials, and provides an integrated search, and possibly some sort of interactive guided question-and-answer technology. In practice, most self-service sites are usually a loose collection of these different components, which rely on the user’s ability to define good search queries.
• Next in the funnel are forums and user communities, where you can get help from other users and, in some cases, from staff who monitor the communities.
• For a company like Autodesk, partners provide the next level of support (this is not so true for Softimage, but is true for most other Autodesk products).
• Finally, at the narrow end of the funnel, is the one-to-one support provided by people like me, the “technical specialists” (I’m not sure why, but I loathe that title).

Now, the funnel analogy is not “correct” in the literal sense. In a real funnel, everything that comes in eventually flows through the bottom of the funnel. In the support funnel model, the number of customers decreases as you move down the funnel. A more accurate diagram of the support model would be a sankey diagram, which shows the proportionate number of customers served by each level of support: