Transcript TSANet

TSANet
The Industry Infrastructure for
Multivendor Support
Dennis Smeltzer
President, TSANet, Inc.
TSANet

The Industry’s Best Kept Secret?
–
–
–
–

Established in 1993 as Not-For-Profit / Vendor- Neutral
Over 200 Members Worldwide
Used to Solve Hundreds of Multivendor Problems
Saved Thousands in Sales and Lost Revenue for Members
Why isn’t it better known?
– Behind the Scenes Process



Customers rarely know TSANet is being used
Members don’t promote problem solving
Intranet Links can Provide a Path of Least Resistance but name
recognition is not a priority
– Call Volumes are low to begin with



Last ditch effort … call the other guy for help
Easier to Push the Customer off … “especially when I get
reviewed based on call closure”
Failure to emphasize processes for TSANet or any other CSAs
What is TSANet?

TSANet is an INFRASTRUCTURE
– Legal (Industry Standard Language)
– Tactical (Simple Database for “everyone” to store process instructions

Technical Support Alliance Network
–
–
–
–

Vendor-Neutral
Not-For-Profit
Members Worldwide
Most Major IT Vendors Participate
Provides Support Personnel a Mechanism to Collaborate with other
Partners
– Member to Member Portal



Via our Intranet or Direct to TSANet Portal www.tsanet.org
Members Post Process and Escalation Documents for other Members in the TSANet web site
Contact is typically made via phone or email via each members’ posted process
– TSANet is NOT a 3rd Party -- Contact is made direct between other
Partner/Member
TSANet Community Model

The TSANet Structure allows members to
create two types of relationships
– Open Groups


Many to Many type relationship
SLAs vary per relationship
– Closed Groups (Customized)



Many to Many
One to Many
One to One
TSANet Model
Traditional TSANet Model
Many-to-Many
Closed Group Option
One-to-Many
One-to-One
Standard (Classic) TSANet
Open Group Relationship

Standard TSANet or Classic TSANet
– Largest Membership (400 support centers)
– Best Effort (No SLA but quick response)
– Single Point of Escalation to Program Manager
on Site
– Member Defines Mutual Customer (e.g. Support
Agreement Required, Products Supported, etc.)
– Limited Number of Callers have access to Place
Calls
Mission Critical Customer
(MCC)

Common Elements of MCC
– Many to Many type relationship
– Mutual (End-User) Customer must have
24/7/365 contract with member being called
– Members agree to work to Isolation and/or
Resolution
– Must involve Post Sales Products in the Field
– Member can use TSANet as a Vendor-Neutral
Escalation Point
Mission Critical Customer
(MCC)

Open Group Relationship
MCC Elements
– Requires 24/7/365
– Requires 24/7/365 Escalation
– Mutual Customer Must have 24/7/365 Contract
 Information about what is required to identify
customer is located in the database (You will need to
get this information from the customer)
 Contact Procedures are posted in the database
– Response Times
 2 Hour Response in P-1 (Severe)
 4 Hour Response in P-2
 Next Day Business Day for P-3
– Unlimited Callers have access*
• Must be member of TSANet in a specific Global Region to Place Calls
Customized / Closed
Groups




Typically utilize the TSANet Standard language
Use the TSANet Database / Web site as the single
point for storing and updating contact / process
documents
Member’s will “host” the relationship and choose
Participants and support elements of the
relationship
Can be formed as
– Many to Many
– One to Many
– One to One
Globalization

Formerly Two Separate Companies
– TSANet, Inc.

Americas / APAC
– TSANet Europe, Ltd.

Two

EMEA
– Sets of Paperwork
– Boards / Leadership
– Operations / Pricing

Global Company
– One




Direction (Mission)
Leadership (Global Board)
Operations (Global Staff)
Members (Global Input)
New Open Group
Relationship

Objective
– Create a “Direct” mechanism for Seniorlevel Code Engineers to collaborate within
the industry.
What is the problem?
– Collaboration between high-level engineers happens but typically takes
place as a last resort and after days of customer finger-pointing and
internal escalations



Calls internally must be escalated to the correct level of engineering which is
typically not a timely process.
The mechanism for code de-bugging engineers to collaborate at an Industry
level is a behind the scenes process and usually takes the form of a business
card relationships. These relationships are vulnerable and not accounted for.
Once high-level engineering is involved, inviting another partner/vendor means
starting the problem resolution process all over again. At times, this process is
better accomplished by an upset customer who can get a call escalated more
rapidly.
– Customer satisfaction can deteriorate rapidly when confronted with the
industry’s inability to get their paid suppliers together



Customers’ experience the same level of frustration as engineers experience
when engagement of like resources at another company takes the course of
starting all over again. Thus, finger-pointing can and does occur.
Senior Engineers can move rapidly to resolution once the correct level is
engaged increasing customer satisfaction
Entitlement is not the issue is most cases. These are high-level paying
customers
What will this solve?


Establishes a quick, vendor-neutral easy to implement process
for engagement of senior-level, code debugging engineers
throughout the industry.
Establishes criteria
– For the Engineers who use it
– When the process should be used




Obligates the industry to work on behalf of qualified Mutual
Customers but establishes criteria for disengagement should
common, mutually agreed principals not be in place
Keeps the customer informed but out of the escalation and
finger-pointing process between members
Formalizes the process and establishes an industry standard
mechanism already in place
Implemented at little or no cost for most members
What are the obstacles /
hurdles?




Industry Definition of “Terms and
Procedures”
Customer Entitlement
Who, When and How can someone
“Push the Button”
What is the ROI and is it Tangible?
Industry Input Needed to
define scope

Define when the relationship can be invoked
– Problem solved by Sr. Level Engineers with access to Code?

Define Sr. Level Engineers (Outbound Process)
– The agreement will allow only “named” qualified engineers to engage

Define what is acceptable process for receiving a call (Inbound)
– To what level

Process or Named Callers
– Customer Entitlement



Engagement
Disengagement
Certified Platforms
– Response Time Criteria


Response Time and Definitions
24/7/365
Short Call Process
Example
Problem Identified and Escalated Internally
Customer Entitled
Problem Verified
Pre-Post Customer Entitlement?
Process to Engage?
Customer Involvement?
Non-Disclosure Necessary?
Qualified Engineer Determines
Engagement with other vendor
necessary
Collaboration Occurs
Call Ownership?
Who informs who/ when?
Call Closure?
Steps to Implementation

Obtain interest in moving forward
– TSANet Global Board Meeting – Complete








Obtain interest and commitment of time from industry in
pursuing
Identify Working Group and Initial Participants
Define Scope of Relationship using Industry Templates and
Database (TSANet)
Management Approval
Legal Input and Feedback
Process Templates
Beta Testing
Release to Membership and Press