[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:
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

                  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

                  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

                  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
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