THE LAST WORD

THE LAST WORD - Service Management Magazine, Sept/Oct 1998

"We Need A Virtual Support Community"

By John Chmaj, with Ralph Carpenter and Josh Anderson

Your company is probably losing a tremendous amount of time, money and efficiency, trying to provide multivendor support so that your customer can get the product you sold him to work with other products or components produced by other vendors. Why the huge time investment? Because there is an absence of standardized processes and agreements for support interaction among vendors. According to the Customer Support Consortium (recently scrutinizing several major support organizations), accessing relevant information about another company's product can consume up to three times as much of a support analyst's time and effort, as does support effort for a single product. And contacting another vendor for assistance, can consume up to 17 times as much time and effort as it takes to resolve a single-product incident!

Then too, organizations expend enormous resources, just creating and maintaining the many support partnerships needed to collaborate. And it's costly to provide continuous training on other companies' products. In the end (and without doubt, most importantly), the lack of a consistent, reliable multivendor process has a profoundly negative impact on customer confidence, loyalty and satisfaction.

Today's hi-tech industry customers expect their products to readily interoperate -- a direct benefit of the "open system" model they've been hearing about. And as open systems products have become pervasive, a competitive market has developed that demands support for products produced by other vendors.

But the support systems that technology vendors have put in place have traditionally been proprietary. And though open systems products have propagated, proprietary support tools have remained the norm. This must end.

Toward that goal, support data exchange standards were published in 1997, opening the door for support and call center tools to become interoperable. These standards are a major step toward the realization of the "virtual" support community, where support can be timely, efficient and coordinated across the multivendor environment.

How Exchange Standards Will Work

The Customer Support Consortium (Consortium) and the Desktop Management Task Force (DMTF) have combined their efforts in response to the industry demand for a standard method of exchanging support information between disparate call center tools. The focus of the Service Incident Exchange Standard (SIS) is to: 1) Identify support data and workflow elements that are common among many different support organizations; 2) map the relevant portions of diverse, proprietary systems into a common schema that can respond to all fundamental requests for service; and 3) represent these requirements in standardized data, transaction and incident states.

Similarly, the Solution Exchange Standard (SES) provides a method for exchanging solution information consistently between call center tools. Solution information consists of the information about an issue, and the relevant diagnosis and intelligence required to resolve it. Solutions may be exchanged in a variety of scenarios: a) help desk-tohelp desk, b) technology vendor-toknowledge provider, and c) knowledge provider-to-help desk.

The Virtual Support Community

In the virtual support community, support information can be exchanged electronically among the community's participants: product vendor support centers, third-party support providers, corporate help desks, and channel support providers. Companies that perform services for service delivery organizations (such as outsource providers), will be able to join in the electronic exchange of support information, as well.

And the customer? He'll be linked either to a corporate help desk or to a channel support service, then to the network of third-party support providers and vendors' call centers. Virtual support community participants will be linked via the Internet.

What Should the Participants Do?

The intent is to create an environment that will a) offer and accept service requests among partners in the community, and b) smooth escalation or transference of service incidents or exchange of solutions. Therefore, each participant needs to have the necessary basic network infrastructure in place, to be able to work with the rest of the community. The convergence point could be implemented as a single website, or a complex arrangement of global interconnections that enable multivendor support collaboration.

In order for the virtual support community model to succeed, however, participants must operate according to the following "bylaws": 1) Each participant is capable of handling requests from other partners for service entitlements. 2) Participants will publish their support services, products supported, and internal service processes and expectations in a standardized way. 3) Vendor participants who manufacture hardware or software will publish the authoritative list of names by which their products will be identified, which the community agrees to use, to avoid confusion. 4) Each partner will ensure the accuracy of its own electronic engagement address(es) and protocol(s) used for incident and/or solution exchange. 5) Fees may be exchanged for services rendered, and are governed by the terms of the one-to-one contacts that pairs of participants have established between themselves.

Note that not every member of the support community is required to be able to provide support, in order to be entitled to request support from others.

In Real Life...

...A typical standards-based service engagement might flow like this:

1)Partner A wishes to obtain escalation support for a particular product. The product directory helps establish the product identifier. 2)0nce Partner A has determined the common identifier for the ailing product, a search for support providers is conducted— unless the desired provider is known. This process determines the identity of Partner B. 3) Partner A obtains the appropriate electronic address(es) and protocol(s) for exchanging information, and proceeds to request entitlement through direct contact with Partner B. 4) 'I'heremainder of tile transactions are exercised through SIS for working with l'artncr 11 towards resolution of flue incident. 5) ()nce Partner A's customer's incident has been satisfactorily resolved by I'artner B. the service engagement is complete.

(To two think about: A support community's meeting place/infrastructure might be provided and maintained by a not-for-profit federation sponsored by the community itself—much like those of the Visa and MasterCard organizations, or the New York Stock Exchange. A common infrastructure would assure a high-performance, consistent and neutral environment for collaborative support.)

What Can You Do, Right Now?

You can embrace broad adoption of the exchange standards as the interoperability interface between support organizations. Then, support the additional standards for product and service provider profiles that will likely emerge to facilitate the creation of consistent definitions and relations within a "community." The Consortium has developed a Multivendor Support Strategy which defines specific levels of interaction and business benefit from standardized processes and data exchange, and will continue to mature the standards in partnership with the DMTE; keep abreast of these developments. Most importantly, speak up! Only loud and consistent support from the support community as a whole, will move the vision of a virtual support community closer to reality. M

John Chmaj is program manager of the Customer Support Consortium; for more information about the organization, send e-mail to jchmaj@)customersupport.org. Ralph Carpenter, engineer scientist/ architect for Hewlett-Packard, and Josh Anderson, multivendor program manager of Microsoft Corp, were contributors to this opinion piece.