Improvements for support services 1

Suggestions for Support Services

@ ESRI India

Created by Vipul Bhatia for ESRI India Support Services.

Improvements for support services 2

1. Use of Technology:

1.1 Use of Virtual server’s (like VMware Lab Manager):

Create multiple virtual servers per physical machines. This way many combinations of software
versions can be kept in one machine.
Run multiple operating systems on a single computer including Windows, Linux and more.
Reduce capital costs by increasing energy efficiency and requiring less hardware and increasing your
server to administrator ratio
Ensure your enterprise applications perform with the highest availability and performance.

1.2 Remote Desktop support:

Majority of our support calls for critical issues demand a visit to the customer site and troubleshoot the
issue at client location. Sometimes we spend more time on travelling and less time on problem resolution.
Now many of our customers are wired through Internet. So, wherever possible, we can use remote desktop to
get into the customer’s machine where ESRI software is installed. Using the technology for remote access we
will have following benefits:

Sitting on ESRI India office, we can diagnose the problem and resolve it quickly.
There are complex instances where you need experts in specific areas and access to local resources.
This can be arranged quickly in-house and a joint effort can reduce the resolution turn-around time.
The conventional support mechanism does not help us to save our time, money and resources. On the
flip side, some of the organizations are security sensitive and may not allow us to make a remote
connection to their machine. There are customers who justify that our technical person should make
site visit to see everything that we have installed is working fine. In these cases, we can make onsite
visits as per existing support model
This will enhance our capability later on to extend the support to overseas location if a technical
support project is taken up.

Created by Vipul Bhatia for ESRI India Support Services.

Improvements for support services 3

2. Knowledge bank:

We should create and add to existing documents a set of knowledge bank of documents specific to support
services, which an analyst should be introduced at time of induction and should be able to refer to any time
while working within the support role.

The documents should essentially outline in detail the workflows, & procedures along with technical support
specific reference material an analyst should adhere to while working on day-to-day basis.

Some of the examples for the documents are listed below for understanding:

2.1 Non- technical documentation:

Guidelines on planning a visit to client site.
Document on the scope of support services.
Sample responses to queries which an analyst should adhere to in specific cases/different situations
like a query on type of encryption technology/protocol used in ESRI products for encrypting passwords
or an answer to an out of scope of support services query or a request to escalated the issue to a
senior analyst. (This can be done for known issues at time of creating this documents and more
samples could be created as and when required…)
How to escalate issues to senior analyst and from RO to HO.
Basic incident management
Things to keep in mind while working with customers at client site.
Incident quality evaluation guidelines – which should tell the analyst about the criteria’s on which
there evaluation will be done and provide them understanding of each of the evaluation criteria’s.
(Once the evaluation of analyst’s work in incidents is implemented from Internal quality evaluation perspective and customer
perspective (Customer Survey).

2.2 Technical documentation:

2.2.1 Leverage the existing ESRI documentation:

ESRI Support Site (open to both user’s and support analyst) currently provides user’s with
technical documents as general start points for resolving issues which are commonly seen or
problems ESRI thinks users can run into while working with the software. It includes
documents like knowledge-based article(s), software defect(s), installation document(s) and
web help’s.

An analyst should be encouraged to have a basic understanding on where to find the specific
information within the support site as the users may be referring to this system or may have
already been through these documents before reporting the issue.

To supplement these documents we should develop internal technical documents and a

robust document management system to retrieve (indexed & searchable) them. Following are
examples of documents which essentially needs to be in place to start with:

Created by Vipul Bhatia for ESRI India Support Services.

Improvements for support services 4

2.2.2 Question bank:

We have been used-to to them in school time/ college time to do focused preparations for
exams  and have always been helpful to prepare quickly and efficiently for the D-day  .

It’s time that we should bring them to use to infuse the same confidence in the support
analyst when he faces a question/ issue from a client in technical product/area out of his skill
expertise.

I recommend a question bank should be made for the analyst who might be experienced user
in one technology but is new to another ESRI product and does not know where to start on a
reported issue:

So we should provide him/her with a basic set of questions to be asked to customer for
starting troubleshooting on each of ESRI Product we support and a technical area within it.

It should have specific questions for sub parts of product based upon the area they are
reporting the issue for.

2.2.3 Software Testing and Analysis Tools (STAT) documentation:

We should document the use of tools, which are more frequently used in support issues to
identify where the issue is, to reproduce the issues, to identify the cause of issue by using the
debugging tools. The effective use of these tools individually or in combination with other
tools, in various situations where they can be used to evaluate the issue, will subsequently
lead to a quick, efficient and better resolution of incidents.

We should not only maintain a document but also a central repository of these tools for
access to analyst both on intranet and Internet while they are at client location for
troubleshooting. Also hot links can be provided to locations where the latest version of these
tools can be downloaded.

Some of the in general names are listed as below:

1. Fiddler 7. Use out of box HTML Viewer.

2. Fire bug 8. ArcIMS Spatial Server log file analyzer -
3. HTTP Analyzer aimslogs.pl
4. Gaia, 9. Log Parser
5. Microsoft Web Application Stress Tool 10. Process Monitor
6. SendArcXML
11. Trace

Created by Vipul Bhatia for ESRI India Support Services.

Improvements for support services 5

3. Skill development/ Training:

3.1 Focused training should be imparted for working as technical support role: It includes both technical and
non-technical:

a) Incident management
b) Methodology for trouble-shooting any technical issue (GIS or Non-GIS)
 Understanding on how to identify which area of technology this issue resides with.
 Understanding on whether the issue is related to ESRI technology or non-ESRI.
c) Understanding the scope of support services.
d) Basic customer service skills:
 Pacifying an angry customer,
 Taking customer into confidence while working on a complex long duration issues.

3.2 Creating basic capsule for bringing the technical analyst on board – Should include basic introduction to
major ESRI products and on how to troubleshoot issues related to them.

3.3 Training incidents:

An analyst should be assigned to a mentor and may be walked through couple of training incidents
where the mentor should act as external customer, putting queries to analyst and analyst work through
these issues as they would with a real user.

For this purpose we should have a concept of training incident in our OTSS or may be a separate
application could be build to monitor the progress on analyst.

3.4 Identify the resource: We should identify the candidates on voluntarily basis and nurturing them as
specialists in one or more ESRI products.

3.5 Introduce innovative ways where we can conduct monthly technical quizzes to make the learning
interesting for analysts.

3.6 Develop Training pathways:

We should develop training pathways for the analysts to grow into a specialist into another technology
area.
 These should not focus on product as whole but short capsules targeted for focused area within
a particular product e.g Working with GeoData Services ArcGIS Server or Learning geodatabase
or Migration of Geodatabase or Building faster web maps.
 These pathways should be of two levels, beginners and advanced. So that someone with no
knowledge can start with these courses.
 These courses should have steps for troubleshooting for support point of view.

Created by Vipul Bhatia for ESRI India Support Services.

Improvements for support services 6

Additional Advantage: Once these courses are developed in house, we can fine-tune them to create
new short training capsules for users, which may like to learn a focused area in a product. Also we can
use these start a Web based GIS training given online by an analyst.

4. Collaboration & free discussion:

An easy n free environment should be provided to analysts especially the one’s which are in regional
offices to discuss the technical issues with their highly skilled peers. For this I will suggest a discussion
board should be created. Currently there is not platform like this is available within ESRI Inc’s support
services .

The idea has been further elaborated below:

Discussion board:

A web based discussion board for support analyst should be in place to engage peer-to-peer support from
fellow analyst(s) in an informal discussion on day-to-day basis. “This will be a great boon for analyst working
in regional offices to connect with their counterparts in other regions and head office.” Some of the salient
points to be kept in mind are:

The participation in this discussion should be voluntarily.

We can create categories within this to discuss the issues product wise/ technical area wise and keep
it flexible to create random (Analyst need based) categories.
This shall be at all times monitored by senior analysts.
There should be guidelines to use this discussion board e.g. only technical discussion and no price
quotes to be discussed.
No client reference with names to be told.

It can help us discuss about new enhancements and second thought on software defects, which we can send
to ESRI Inc on monthly or quarterly bases to improve the software needs of our users.

We can have a sub-part to discuss new ideas also and analysts can vote for them.

This will help the Head office to make a better business case for the enhancements and software defects to
be fixed on priority (No. Of customers facing this issue in India.)

I envision it as first to be initiated for support services only and later on to be open to whole NIIT-GIS where
support analyst can get suggestions from any other individual in consulting division (e.g. application
development team, database services) and vice versa.

It can be later be given access to business development executive(s) to ask queries which they may get from
the clients or in general while working on any specific RFP tender(s) from the whole set of technical
resources. Later on, the information can be double verified with the assigned analyst for the region to put it
in official documents as per the existing procedure.

Created by Vipul Bhatia for ESRI India Support Services.

Improvements for support services 7

A basic chat option should also be provided so that two people can discuss the issue in real time, if they are
online at same time in the system (their status being set online/offline).

The onus lies on the user who has raised queries to double verify the information before passing it to any
customer outside of company.

This will improve the communication between the analysts and they should be able to participate as per their
work schedule. This will create an atmosphere to collaborate on complex issues and will be a good team-building
platform.

5. Central repository for tools /document management system other than iniitian :

Dedicated for Support Services.

It should contain all documents pertaining to support services (Technical and non-technical as
discussed in point # 2.
There should be a way (a informal section) for analysts to share their experiences with their
colleagues (upload documents/links/datasets), which they might have found while working on
specific incident or non-incident (out of personal initiative to learning something new).
This should a part formal and part informal portal where analyst can submit new documents for
review which may later be included in official documents after a proper review by product
specialist and technical support head.

6. Technical Evaluation:

6.1 Internal Quality Assessment:

We should develop a methodology to evaluate quality of incident management by the analyst on both
technical and non-technical aspects. For this to happen we should first identify the key parameters to
assess the incident quality.
The parameters should be well documented in guidelines what they stand for and how the analyst will
be evaluated on this key areas. Also it should contain things to be kept in mind on how to achieve the
best rating on these parameters e.g. on scale of 1-5. The highest rating should be something which can
be achieved by not only meeting the set criteria for all the applicable areas but by over achieving some
of the criteria’s. They should be provided proper training on how to achieve the same in sample training
incidents.

The document should be provided (in central repository) and discussed in detail with the analyst before
they start talking live incidents.

Created by Vipul Bhatia for ESRI India Support Services.

Improvements for support services 8

Reporting technical manager of analyst can evaluate the incidents and they should be trained on the
evaluation pattern and criteria’s so that the ratings are normalized across the regions independent of
who evaluates at the end of day.

Below are some of the criteria’s, which can be referred for creating the final list:

 Prompt contact: (with the customer after owning the incident)

 Proper and updated information on research in incident notes
 Technical articles or help topic reference has been mentioned or not.
 Previous incident reference has been provided or not, if any.
 Timeliness – How the analyst kept the customer updated and responded to their queries
throughout the incident.
 Correctness of technical suggestion: provided to user / whether proper research was carried out
to suggest any solution.
 Resolution as per guidelines
 Professionalism in emails

6.2 Customer Survey:

A customer survey request can be sent to end user to give their valuable feedback on analyst’s
performance and any suggestions, which they like to provide.

 Some of the key parameters should be developed for the survey focusing on criteria’s on which
we want to take users feedback on analyst performance.
 It should be constant for all the incidents.
 This can be done for random incidents/ or all the incidents for each analyst.
 Technical manager should be able to send the customer survey on closed incidents, if they like to
at any time.

6.3 System based parameters:

We can have a reported generated by the system on the basis of tracking of some the key times/ dates
for each incident:
a) Time/date ownership of incident.
b) Time/date for closing the issue.
c) Reopen time/date.

We can calculate some of the parameters like:

 Average time to resolve issue (in days).

 Average # of days to resolve the issue.
 No. of incidents owned/resolved per week/per month.

We should avoid to set the fixed time for resolution time on an individual incident as it drastically varies on
complexity of issues and response of user for any additional requested. Though we should try to achieve an
average feasible overall resolution time for an analyst in a given month/quarter/year.

Created by Vipul Bhatia for ESRI India Support Services.