[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Tech Support
Dla tych, ktorzy jeszcze nie czytali ostatniego wydania SmartNews
zalaczam ciekawy artykul, z ktorym wydaje mi sie dobrze aby polscy
klienci Progress Software sie zapoznali. Wszystkim natomiast
przypominam, ze zasoby i potencjal techniczny PSC Technical Support w
Rotterdamie sa do Waszej dyspozycji: nalezy jednak zawsze miec
przygotowany pod reka numer seryjny produktu.
Ostatnie wydanie jest dostepne na stronie:
http://www.progress.com/support/smartnews/may01.htm
*******************
Why We Do What We Do: A Technical Support Perspective
by Carol Osborne, TechSupport Americas
The following article attempts to explain some of the
frequently asked questions by
our customers as they relate to information Technical
Support Engineers
commonly ask of our customers.
Have you ever wondered why Technical Support asks you
for your serial number
every time you place a service call?
I bet you think it's to see if you are covered by
maintenance? Well, that's one of the
reasons. The information is also used to identify the
product you're using as well as
the platform and Progress version. This information is
critical to the TSE's success
in capturing your report of the issue and taking steps
to resolve or isolate your
issue further. This data allows the TSE to identify
resources and equipment that
may be required to troubleshoot your issue. Knowledge
of the platform you are
using also allows the TSE and customer to dialect in
the appropriate terms. In
other words, if you're running on a UNIX machine, UNIX
terms will be used rather
than PC terms and vice versa.
The serial number also identifies if the product was
sold to an ISV or directly to a
PSC end user. If the product was sold to an ISV,
knowledge of this fact allows the
TSE to ask the caller if they are a representative of
the ISV or an actual end user.
Technical Support does have agreements with several
ISVs that indicate we are
second line support for them instead of first line
support. This was a mutual
business decision that was made to ensure that the end
user receive the best
resource available to resolve their problem based on
their maintenance agreement
and the application they are running. If you are an
end user of one of these ISVs,
you may be directed to the ISV for additional support.
Because the serial number
provides this detailed level of information it is
often used to notify our ISVs of trends
or training needs within their organisation.
Once it is determined the type of caller you are, the
serial number also has several
caller or contact names linked to it. These names
include previous callers from
your company as well as that of the ISVs (depending
upon your maintenance
provider). When logging a service call it is critical
for us to ensure that we have the
most recent contact information for you, the caller.
This is why we validate your
name, phone and fax numbers and email address. If an
error is encountered in the
verbal review process the contact details within the
contact profile will be updated
with the correct information which is also linked to
your serial number. Each serial
number has its own list of contacts, that is why we
may have correct information
for one serial number and incorrect information for
another. If you are constantly
seeing inaccurate information during this review
process please encourage the TSE
to update the contact profile so you do not have to
correct us. We want to serve
our customers, not aggravate them.
Do you ever wonder why Technical Support tries to find
a workaround for a bug
rather than just requesting a patch on your behalf?
Well, let me explain... First of all, patches are not
tested as thoroughly as full
commercial releases. The potential impact of this
means that a new bug could be
introduced or something else could get broken as a
result of patching another area
of the product. This has happened in the past and will
probably continue to happen.
Why? Because patches cannot be put through the same
vigorous tests as
commercial releases, mostly due to time constraints.
Our release schedule is
such that we are trying to get the latest technologies
to you, our customer, while at
the same time trying to maintain the stability of the
core product. Some fixes are
too risky to be patched. What I mean by this is that
sometimes a bug can occur in
an area of the code that is too complicated to be
patched as it may break
something or change core functionality of the product.
The purpose of patches is to
fix a problem that does not change any functionality
of the core product.
Functionality changes are reserved for commercial
releases where we can obtain
the benefit of thorough QA testing. Patches are also
automatically rolled into the
next commercial release of the product and therefore
do eventually receive full QA
testing - but not at the time of their creation. When
a patch is created it is only on
the most recent commercial release, we do not create
patches on retired or mature
products.
When a customer reports a bug, why does Technical
Support insist that I provide a
way to duplicate the issue? Why can't they just fix
it?
First of all, Technical Support does not fix bugs. A
bug request needs to be
generated in order to have it fixed by development. To
fix a bug, development needs
to be able to identify in which area of the source
code the problem occurs. In order
to determine this, development needs to have specific
information. This information
may include the Dr. Watson log or stack trace, the
error received, the log file,
server, client and connection startup parameters. They
need to have a way to
duplicate the issue in-house to see if it is
environmental, operating system related
or truly a Progress bug. Once development is able to
duplicate the issue they may
have to run it through other utilities to obtain
additional debug information to help
them isolate the area within our code in which the
problem occurs. Once this is
determined, development may need to generate debug
modules that can be used
to run through the steps to duplicate the issue and
therefore capture more data
about the problem and ultimately identify how this bug
occurred in the first place. In
other words, where the internal logic in the C or java
code failed. Then they can
determine a fix for the issue. Because you provided a
way to duplicate the issue,
development can test their fix to make sure that they
solved the right problem. Now
that they understand where the logic failed, they are
better prepared to identify
other related areas in our source code that may also
be plagued by this logic
failure.
These are just a few examples of common practices used
by Technical Support in
order to properly diagnose your problem and implement
the most appropriate
course of action to resolve it.
--
************************************************************
Marek Bujnarowski
Technical Support Engineer
Progress Software EMEA,
Schorpioenstraat 67, 3067 GG Rotterdam,
The Netherlands
E-mail: mbujnaro@progress.com Web: http://www.progress.com
Tel: +31-(0)10-2865-247 Fax: +31-(0)10-2865-225
Support: emeasupport@progress.com
************************************************************
PROGRESS WORLDWIDE EXCHANGE 2001
3 - 7 June, Washington, D.C.
Imagination. Innovation. Getting There.
Register now at http://www.progress.com/exchange
************************************************************
------
Strona WWW: http://pluton.pol.lublin.pl/pugpl/index.htm
Obsluga listy: listserv@zeto.bydgoszcz.pl
Archiwum listy: http://www.zeto.bydgoszcz.pl/progress/index.html
------