VanguardMS Customer Support Help Page
This area is for use by the VanguardMS customer support community. This
page contains:
VanguardMS Escalation Process
Escalation Submission Form
On-Line Reports and How to Use Them
Status Report of Escalation Open to VanguardMS Engineering
Definition of Terms
Email Archive
Feedback about this page
This is a brief overview of the Escalation Process. A more complete
definition of the process is contained in VanguardMS Engineering Support
Policy.
- Field Support.
- When a customer problem is identified, field support personnel
check configuration; validate the application using application
notes, FAQ data searches, etc; gather and analyze data (including
Alarm Logs, Node and detailed Stats, crash reports, logs of recent
changes to customer environment; etc); and seek support from 1st
and 2nd Level Support groups if the problem is not resolved in
a timely manner.
- Level 1 Support.
- Level 1 Support is provided by Global Support Engineering
who can be contacted by phone or by email (using the MS Mail "Cust.
Serv." icon). The role of GSE in dealing with a customer
problem is to document the nature of the problem and to capture
basic information about product line, release level, configuration,
and application; verify proper installation and configuration;
resolve the problem on the phone; dispatch on-site service (if
appropriate); or, failing to resolve the problem in a timely manner,
escalate the problem to Level 2 Support . Wayne Shaker is
the manager of GSE.
-
In some cases, groups other than GSE may be qualified by VanguardMS
to provide Level 1 Support and to contact Level 2 Support directly.
Examples of such Level 1 groups are On-Line Center, accepted VAR's,
etc.
- Level 2 Support.
- Level 2 Support is provided by Global Network Engineering
who respond to an escalation from a Level 1 Support function.
The role of GNE is to more deeply evaluate a problem drawing upon
technical experts within GNE and VanguardMS Engineering; attempt to
duplicate the problem (when necessary); contact the customer directly
to get more information and, if necessary, gain access to the
customer's network for diagnosis and data gathering; or recommend
configuration changes, software upgrades or unit replacement to
attempt to resolve the problem. Failing to resolve the problem
in a timely manner, GNE will escalate the problem and all associated
data to VanguardMS Engineering. Jeff Amaral is
the manager of GNE.
- Escalations to Engineering.
- Problems Escalated to Engineering are logged in a problem
tracking system; categorized by the severity of the impact on
the customer; and assigned to a manager and engineer for evaluation
and resolution. Depending on the nature and severity of the problem,
the resolution may be a software patch release; a temporary workaround;
or resolved in a subsequent standard release of software. All
open escalations to engineering are reviewed weekly by Engineering
and GNE and documented in the Status Report of Escalation Open to VanguardMS Engineering.
Wayne Dixon is the VanguardMS
Engineering Escalations Manager.
-
A problem is Escalated to Engineering after level 1 and level
2 means of support have been exhausted and have failed to remedy
the problem. At that point in the process, an escalation is logged
to the engineering problem tracking system by GSE or GNE via Clarify.
Clarify Access page.
In addition to Escalations, DDTS also allows the logging of
one time crashes. Query DDTS Crash Database
Most system crashes are one-time, self-recoverable events which
cause a brief outage. These types of problems are generally difficult
to diagnosis and resolve, and require a number of occurrences
to identify the trend and to isolate the underlying cause. The
crash data base is used to log these sporadic occurrences. Immediate
diagnosis or resolution is generally not possible. (Any other
type of crash of a more severe nature is handled as an Escalation.)
Defects which are observed, but which do not require commitment
of a resolution to our customer, may also be logged through Clarify. These defects will be evaluated when possible and over time
lead to improved overall product quality.
All open escalation's to engineering are reviewed weekly by Engineering
and GNE and documented in the Status Report of Escalation Open to VanguardMS Engineering.
Questions, additional inputs, or corrections regarding an escalation
or the content of this report should be forwarded to Dave Brooks.
Under no circumstances should the field establish direct contact
with the manager or engineer who are assigned to an escalation
without Dave Brooks or Wayne Dixon's direct involvement.
This report is organized alphabetically by end user customer name.
Each escalation can be identified by the CR# assigned by GNE/
GSE. Each summary contains the following information about the
escalation:
- Tracking Information (Customer, Severity, Escalation State,
CR-#)
- System Information (Platform, Release on which the problem
occurred)
- Resolution Information (Patch #, Target Standard Release #)
- Schedule Information (Escalated to Engineering, Target Fix,
Actual Fix)
- Problem Description (generally describes one or more symptoms)
- User Impact
- Workaround Description (when/ if available)
- Limitation Description (when problem is understood)
- Status (updated weekly; daily for Severity 1 problem)
This section covers the terms used to track and categorize escalation's
to engineering.
Problem Severity:
- Severity 1 (Critical):
- A problem that prevents the implementation of a required major
feature(s) and exhibits an unacceptable impact on the customer's
operation or service availability for which there is no known
work around. Requires immediate engineering attention and daily
status updates. The normal remedy for a problem occurring on a
supported release of software is upgrade via a software patch.
- Severity 2 (Major):
- A problem with a required feature(s) that seriously degrades
the products performance or limit's service availability, but
does not prevent product implementation or is mitigated by a temporary
work around implemented. This includes any node crash which requires
manual operator intervention for recovery. Within 5 working days
from when a severity 2 problem is Escalated to Engineering, the
problem must be reviewed, and within 20 working days thereafter,
a commitment is required as to when the problem will be resolved.
The normal remedy for a problem occurring on a supported release
of software is upgrade to the next standard release or to a specific
software patch.
- Severity 3 (Minor):
- A problem with a required feature(s) that degrades the products
performance, appearance, or service availability, but does not
seriously impact the customer's operations. This includes a so-called
one-time node crash which is self-recovering and apparently not
repeatable. A severity 3 problem requires review by engineering
within 20 working days from the point that the problem is Escalated
to Engineering. Remedy for a problem occurring on a supported
release of software is only made via a standard release
- Severity 4 (No customer impact):
- A problem that does not degrade any product functionality,
performance or service availability. Severity 4 escalation generally
relate to documentation errors or omissions and are remedied by
a subsequent issue of that document.
Escalation Tracking States:
Every escalation progresses through a number of states as it is
being evaluated, fixed, tested, delivered to the customer and
finally resolved in the next release of software.
- Assigned State (A).
- Escalation is assigned to the appropriate VanguardMS manager and
engineer to schedule this effort .
- Open State (O).
- An engineer is actively working on the escalation.
- Postponed State (P).
- Escalation is placed on hold. Generally this indicates that
insufficient information exists to allow further progress. This
moves responsibility for the escalation back to GNE until the
needed information is obtained from the customer/ customer application.
- Resolved State (R).
- A fix for this problem has been found and is ready for a patch
to be built or to be submitted into a new release.
- Verified State (V).
- A patch has been built and tested and is ready for limited
distribution by GNE/ GSE to those customers experiencing this
problem.
- Closed State (C).
- The resolution of this problem has been included in a standard
release of software.
- Rejected State (C).
- The escalation was found not to be a problem of design and
all associated activities has stopped.
An archive has been established to create a reference library
for useful information. The archive can be sorted by Author, Subject,
Date, or Thread. A partial list of the repetitive but informative
email captured is:
- Patch Notices
- Release Notices
- Other?
Click here to view this archive.
Send you feedback, suggestions for additions, and improvements
about this page to Wayne Dixon.
We want this to serve your needs and to improve our overall customer
satisfaction.