Symbiotic Support Channels: A Conversation with Eric Eidson

2012 is my 25th year in the customer service industry, but it turns out there is still a lot I don’t know. One topic I’ve had zero visibility into is technical support for customers delivered by channel partners. I found out just how big this topic is, and how little I knew about it, reading a brand new book from long-time member and friend of the SSPA/TSIA, Eric Eidson, entitled, “Symbiotic Support Channels: How Smart Vendors Create Powerful Partners.” Eric agreed to entertain some interview questions, so let’s get right to it:

John Ragsdale: Thanks for taking the time to speak with me about your new book! I have to admit serving customers through channel partners is not a topic I’ve had much experience with, but you definitely are the expert. Could you start by giving us a bit of your background, and how you became so knowledgeable about channel partner relationships?

Eric Eidson: I’ve held director level and management positions with San Francisco Bay Area technology companies, including Autodesk, Sybase, Applied Materials, and BEA Systems. The foundation of experience I draw on for “Symbiotic Support Channels” comes from managing support delivery through partners, and developing global programs to maximize partner effectiveness, scalability, and contribution. My career has included virtually every aspect of service and support, from taking customer calls, building organizations, and managing support delivery operations, to developing offerings, designing programs, and driving strategic direction. Support partners have almost always been in the mix.

Accumulated frustration with the lack of resources available to those of us working with support in the channel resulted in my experiencing a “calling” to do something about it. While I brought a lot of support channel experience to the project, many very smart people provided the perspective and wealth of knowledge that created a comprehensive discourse on how to select, enable, support, measure, compensate, and manage support partners.

John: You wrote this book because you were frustrated with a lack of resources for developing and operating support programs. What do you hope to accomplish?

Eric: This book is the first comprehensive resource focused specifically on the topic of support through channel partners. My hope is that it calls attention to just how underserved the topic is and stimulates more research, publication, and community activity.

I hope that people who work with support partners, or are otherwise involved in the support aspect of channels, can read the book and find ways to diagnose and resolve issues they’re facing in their current support partner programs, or find valuable best practices to improve or plan a program. As I conducted research it also became clear that many companies have an opportunity to view their programs more holistically, take advantage of relationships with other channel-focused organizations, and leverage their strengths to compensate for weaknesses.

John: For readers who are most familiar with direct support and support delivered via outsourcers/service partners, could you give us some examples of how channel partners become your support providers? Are these resellers of your product, or what is the typical relationship between the companies? And do they typically deliver Level 1 support on your behalf, or do they take over the entire support experience?

Eric: The book is focused on relationships initiated as a product resale arrangement of some kind. The partner may simply resell the product, add value with an application built with the vendor’s product, or integrate the product as a component of a solution, but in all cases the partner owns the customer relationship. The standard delivery model is that the partner provides level 1, or level 1 and level 2 support as the sole interface with the customer. The vendor provides the partner with training, technical information, tools, and backup support to ensure that the partner delivers great support at the point of transaction.

Support is most often sold to the customer on a partner contract. Partners are generally responsible for marketing, although many vendors provide brochure copy, templates, and messaging. Some offer a support-specific branding asset to help partners who have achieved some level of demonstrated technical expertise or training certification achieve market differentiation. Partners are usually free to establish support prices and are encouraged to sell support value rather than discounting to close sales. They’re also encouraged to add value by creating packaged support offerings. Partners are most often compensated with price list discounts to provide margin, and in some cases are able achieve specific performance goals to earn back-end incentives. I cover front-end versus back-end compensation in detail in the book.

John: Early on in the book you have a section of “basics,” i.e., some of the general guidelines for cultivating a more effective partner selection process. One of the recommendations I found interesting is to ask for response and resolution data from a partner’s call tracking system so can analyze performance numbers yourself. How does a vendor ensure that it has an accurate understanding of a partner’s ability to do support? Is it best to establish up front what data and reports you will want to see?

Eric: The most important things are: clearly define the relevant things partners need to do to be successful in the program, and be certain that the proof required from partners provides information that is needed to accurately assess those things. Selection and validation usually consists of verifying that sufficient, qualified support resources exist, and that the partner has processes and infrastructure to sustain dependable, high quality support. Often the partner is required to have a prescribed number of full-time support employees who have achieved a certification by completing coursework or passing exams prior to program admission. Examples of the common process and infrastructure items covered include escalation procedures, case tracking capability, and systems available for problem reproduction.

Using partner-provided call tracking system data is one of the less frequent methods to obtain quantifiable evidence of partner performance because of the risk that the partner has tampered with the data. However, it has a lot of unrealized potential, and as vendor-partner relationships become more automated I expect it will increase in acceptance. When a vendor can see dependable, uncompromised partner support data, the task of predicting success and measuring performance is more scientific with a much lower margin of error.

John: Later in the book, you talk about how to best enable partners for success, and you mention giving them access to your knowledgebase. I know that would scare a lot of companies, who worry about liability issues from aging, duplicate and just plain bad content. Do you see companies relying primarily on their knowledgebases to enable partners?

Eric: While some vendors are allowing unrestricted knowledgebase access, many are focusing on other ways to get more advanced technical knowledge to partners. A vendor’s policy regarding knowledgebase access is derivative of its relative confidence in the accuracy and timeliness of its data. Vendors expressed that overcoming the challenge of getting partners to use the knowledgebase was far more daunting than managing content. Many times support organizations will embark on monumental projects to create thousands of new knowledge articles or upgrade technology when the biggest issue is simply that partners and customers aren’t using what they have available.

My recommendation is that vendors do everything they can to get the highest level and latest technical content in front of partners. If visibility to the vendor’s internal knowledgebase isn’t an option, they can let partners participate in internal training, offer access to a higher level of technical support expertise, or create a support mentor program. Something as simple as making a recognized technical expert available in a webinar session goes a long way toward the cause of enabling and motivating partners. The book offers some innovative and low cost ways to enable partners.

John: Later in that chapter, you have a great diagram and discussion about the Support Channel Enablement Map. Could you briefly explain active vs. passive enablement? I thought this was really interesting, because it appears some companies do everything they can do prepare their channel partners for success, and others may do less-possibly jeopardizing the success of the project.

Eric: The concept of passive versus active enablement refers to the level of interactive engagement required to deliver a specific form of enablement. Creating a knowledgebase article, a technical bulletin, or a manual is passive enablement. The vendor creates the opportunity and the partner consumes the enablement at its discretion. Active enablement must be interactively delivered to be consumed by the partner. Examples of active enablement would be classroom training, escalation support, and partner management.

I segmented enablement this way in the book because a number of vendors I spoke with were investing a significant amount of money and effort in active enablement without recognizing it as such. If vendors can see graphic representation of their enablement investment allocation they are able shift resources to the most efficient forms of enablement for their products and partners. The Support Channel Enablement Map is a simple tool to help vendors compare their actual behavior to their intent. It also provides a tool to track how enablement is trending over time as they become more intentional and work to shift the investment mix.

John: An analogy that you use in the book a few times is “the seven blind men and the elephant.” Could you explain the importance of this for building a strong support partner program?

Eric: Like the seven blind men in the fable, every constituency the support partner program engages with perceives support’s role from its own unique perspective. The channel sales organization is likely to interpret anything that comes from support in context of its impact on how much product partners can sell. Partner managers are probably concerned with diverting partner resources from activities that help them achieve their review goals, and partners want to hear about things that help them make money. If the support organization is planning to add a support escalations metric to the partner management process, the outcome support anticipates is that partners will work harder to close cases. But partner managers see resources diverted from selling product, or just another metric to manage. Partners may just see an expense that doesn’t generate revenue. The burden is on support to create the context for alignment and integration of support into the broader channel program.

When we accomplish this the whole becomes greater than the sum of the parts, and the parts are made greater by the whole.

John: It has been a pleasure talking to you about your new book, Symbiotic Support Channels. Where can my readers buy a copy?

Eric: The pleasure is all mine, John. TSIA experts provided some of the most interesting observations and perspectives for the book. Many thanks to you and the entire TSIA team. The book is available from My email address is on page 3. I’m interested in comments and happy to answer questions.

Explore posts in the same categories: Best Practices, Enterprise Support, knowledge management

Tags: ,

You can comment below, or link to this permanent URL from your own site.

3 Comments on “Symbiotic Support Channels: A Conversation with Eric Eidson”

  1. I think John’s question and Eric’s comment about access to the knowledgebase is right on. If you don’t give your support partners access to the knowledgebase, to me, that’s a big red flag that you don’t have confidence in it. If you want your partners to be successful in making customers successful, then you should share with them the best of what you collectively know — which should be the knowledgebase. And, they’ll be motivated to share the things they learn that you’ll never see if you’re only working the back lines, so you’ll win, too — especially your self-service program.

    One metric I love with partners who have access to the knowledgebase is “invalid escalations.” If an issue is escalated from the partner to the vendor, and if it’s closed with a link to an existing knowledgebase article, then I’d flag that as an invalid escalation. There might be a good reason for any specific one, but showing your partners where they stand relative to other vendors on this metric can be really enlightening.

    • Eric Eidson Says:

      100% with you David. There are many ways to integrate KB usage metrics, and it could be as simple as setting up a red flag that triggers when a partner drops below a defined KB views/cases ratio (red flags are a support partner management best practice covered in the book). The most important step is to engage with partners and initiate remediation when they don’t meet a defined standard.

      KB metrics could also be integrated into financial or other incentives and periodic partner management reviews.

      If anybody uses KB metrics to measure partner performance, I would love to hear about it. The book has an entire chapter on measuring partners.

  2. jragsdale Says:

    Great comment David. In fact, I’d think companies would want to do some good reporting on the number of searches, article views, and article links by partners. If they aren’t leveraging this valuable resource, you should find out why.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: