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 September 2005 issue of the FT Word. Spread the word: feel free to forward it to your colleagues.

Topics for this month:

where should support report?
the role of the support planning function

Where should support report?

Thanks to Frank DeMar for suggesting this topic.

What is the right reporting structure for support? I’ve seen a variety of possibilities

· into the Marketing organization. This works well for vendors that are heavily customer-oriented such as ecommerce vendors. Marketing controls promotion, which in turn drive the support flow. A direct reporting relationship also facilitates blended sales and support models. The Marketing team is also quite attuned to customers in general, so that’s a nice fit. For organizations that are more technology-oriented, reporting into Marketing doesn’t work so well. In addition, most Marketing executives have little support experience so the Support team can end up being neglected. Marketing is also very big-picture oriented and far from the on-the-ground approach required for a successful support organization.

· into the Engineering organization. This is a classic setup for technology startups and it often works very well since the Engineering organization can provide the technology information that’s so crucial for support, not to mention crucial assists as the support organization hires up and trains up. This setup is particularly well-suited for complex products. The drawback of having Support report into Engineering is that most Engineering executives have little support experience, so may not be able to provide much advice at a managerial level. Also, the demands of the Engineering releases may take resources away from Support even though customer demands accumulate regardless of the release schedule. Finally, the Engineering organization may force the release of problematic products down the throat of the Support team and the customers.

· into Operations. If there is an Operations group, as would be the case for a hardware vendor, Operations is a good home for Support. Most Operations executive have at least some experience with support. Having a link with manufacturing is very helpful when it comes to closing the loop on product issues.

· standalone in a Services organization that reports into the CEO. Many larger vendors have a Services team that includes all aspects of post-sales service: support, consulting, and training. This is an excellent setup because it gives Services a place at the executive table and the opportunity to create close ties with the various other groups while keeping some independence. It’s also a non-subtle way to let everyone know that services in general and support in particular are important.

So what should you do?

The bottom line is that support is in the middle of things, therefore it can never belong perfectly to any one area. And, conversely, if can potentially fit in any area. My preference is to have a standalone Services organization, which in my view is the only way to insert the Support team into the strategic decisions. If your organization is mature, that’s probably the best setup.

For a technology startup, reporting into Engineering is a very comfortable place. Over time, you will start running into the limitations of that setup.

If you’re stuck with a reporting situation you don’t like, take heart. In my experience any reporting situation can be made to work. Typically you will find that one aspect (technology, link with the customer, resources for support) is working well, while the others suffer. Make the best you can from what’s working and expand as much effort as you can to create strong bonds with the other functions.

The Role of Supportability in Support

Thanks to Trit Mulligan and Jennifer Walker for independently suggesting this topic (it must be a good one if several people are suggesting it!)

Resolving customer cases and keeping up the knowledge base are not the only activities worth focusing on in the support operation. Two essential activities also belong in support

1) analyzing customer issues to spot trends and close the loop with the appropriate organization so the issues do not occur over and over again.

2) driving input into future products to improve reliability, usability and quality.

These two activities together are often called as being the Voice of the Customer.

What does this mean for support organizations?

There should be a group or a set of individual whose mission is supportability. In a large organization, you can afford a dedicated group. Otherwise, it’s fine to function with part-time responsibility as long as individuals are really able to safeguard their Voice of the Customer duties against other pressing requirements such as resolving support cases. Supportability duties should show up in their objectives.

Have a process for trend analysis and closing the loop. This perform case analysis on closed cases and identify trends etc.. and take actions (give feedback to Tech. Pubs., write knowledge base objects, give feedback to Engineering/QA, etc.. to prevent the same cases from being logged in the future.)

Support should have a voice in the release-shaping process. This is to ensure that diagnostics are built into the product (error messages, tracing, logs etc…) and also to advocate customer-friendly features. Support input into new products is usually incremental rather than revolutionary, but it makes a big difference in customer satisfaction and cost of support. The supportability team should include technically-savvy individuals to gain the respect of others on product development teams and get the support ideas accepted and implemented.

FT Works in the News

SSPA News published an article I wrote entitled Brooks Software A Support Renewals Success Story You can read it at http://www.thesspa.com/sspanews/August05/article2.asp. It was created with Neil Baron of Brooks Software who captained a wonderful rebirth in Brooks’ renewals business. Very inspiring!

I will be speaking at Knova’s User Conference in San Francisco, CA on September 14th. Topics: Collaboration in the Support Center and Deep Truths in Knowledge Management, co-hosted with David Kay.

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