iiliiiiMiW
IBR^R'ES
1Q60 007015m
2
/;
X
''? Of
tt^'
HD28
.M414
9o
/SicSOA990)
TECHNICAL REPORT
Software Hot Lines:
A Preliminary Description
by
Brian T.
Pentland
Revised March,
CCS TR
1990
«104
SSWP #3140
CENTER FOR
COORDINATION
SCIENCE
Massachusetts Institute of Technology
Sloan School of Management
(^
13
mKrirJ/1/-\
^^'^^^-"-»J-^^^l
Software Hot Lines:
A Preliminary Description
by
Brian T.
Pentland
Revised March,
CCS TR
#104
1990
SSWP #3140
The author gratefully acknowledges the helpful comments from several of
the participants in the research, as well from my advisors and friends here at
the Sloan School of Management and the Center for Coordination Science.
Abstract
Technical support hot lines are an integral part of most complex software
products.
create
a
This paper uses data from
a
set of 13 software
lines to
preliminary description and analysis of the basic process of providing
technical support.
Some key managerial issues are
relationship between learning and coordination
reported here are part of
learning
support hot
in
coordination.
is
my on-going research
identified and the
discussed briefly.
The
results
into the role of organizational
/^vo^
1
.0
Introduction
Hot lines are everywhere.
Whether you buy
system, the manufacturer generally provides
And
questions, comments, or complaints.
can of soda or
number
to call
in
computer
a
case you have
while people seldom need help with
they do need help from time to time with their software and
their soft drinks,
other complex technical products.
requirement to do business
is
a
a
hardly considered
a
in
Technical support
the computer industry:
"product"
at all.
As
a
result,
is
practically
a
an "unsupported product'
hot lines (or some other
vehicle for servicing customer inquiries) are commonplace features of software
But although the technical support function
firms.
glamorous than activities
like
is
commonplace (and
new product development),
it
less
raises some
provocative problems for managers and organization theorists.
It
also provides
an example of how an ostensibly simple task -- answering phone calls -- can
give rise to
paper
is
a
wide variety of coordination processes.
to create a preliminary description of the software
that can be used as
a
that comes
in
is
to
know something, vendors try
an occasion for
a
collecting,
With
a
storing,
support function
typical software vendor,
distributing and
knowledge customers need.
in
it
is
Each
For this reason,
refers to as
a
"knowledge
the function responsible for
many cases
To some extent,
respond.
to
knowledge transfer.
technical support exemplifies what MachUip (1980)
industry."
of this
basis for future research.
When customers need
call
The purpose
actually creating the
this quality
is
range of service functions, from hospitals to travel agencies.
shared by
a
wide
But technical
support exemplifies the particular problem of collecting and delivering
knowledge that
not readily available to any single individual,
is
distributed throughout the vendor organization.
creates an interesting organizational problem:
knowledge
how
distributed
is
into several
of
sections.
to
since no single person knows
to
customer inquiries?
organize the technical support function when
the central theme of this paper, which
is
a
brief case history of one of the firms
This case includes many of the features other firms experienced
in
divided
is
Section 2 describes the sample on which the paper
based. Section 3 presents
growth
is
This distribution of knowledge
everything, how can the organization respond effectively
The problem
but
the size and complexity of the support task.
is
the sample.
in
dealing with
in
Sections 4 and 5
describe some alternative ways hot lines are organized and how the process of
answering
some
works
calls
of the practical
in
the organizations
in
the sample.
Section 6 discusses
problems of dealing with customers, human resources, and
linkages to the rest of the organization.
The paper concludes with
brief
a
discussion of some implications for coordination theory.
2.0 Scope and Method of Research
Software vendors deliver technical assistance to
variety of ways.
telephone
--
In
this
paper,
I
will
as "technical support."
industry, but
it
is
worthwhile
to step
th^^ir
customers
refer to one of those
This label
reflect<;
ways
--
in
large
a
the
common usage
in
the
back briefly and consider the range
of
services that firms use to provide practical knowledge anr) product information
to
customers.
These include documentation (printed and electronic), training
(classroom and computer based), and various kinds of specialized consulting.
Electronic bulletin boards and electronic mail are becoming increasingly
means
of interacting with
common
customers, substituting for direct telephone contact
in
.
some situations.
Smaller,
newer companies tend
to
technical support closely integrated,
have training, documentation, and
sometimes even
grouping makes sense because the work
volume
is
in
single group.
The
closely related and insufficient
separate staff for each function.
to justify a
a
in
Larger, older companies
tend to differentiate the functions into separate groups, but usually maintain
them
customer or product services organization.
as parts of a single
when the functions are differentiated, there appear
cross-fertilization,
when trainers
as
assist
in
to
Even
be opportunities for
writing documentation, or
documentation staff help with telephone support.
when
So while this paper focuses
on the activity of answering customer telephone inquiries,
it
should be seen as
part of a broader range of activities that transfer practical knowledge to
customers
In
activity,
order to create the following description of the technical support
individuals
in
13
companies were interviewed. The firms
were selected on an ad hoc basis from the Directory
Technology Companies.
the sole interviewee;
in
In
of
in
the sample
Massachusetts High
most cases, the manager of technical support was
some cases, other personnel were also interviewed.
All
respondents were assured of the anonymity of themselves and their companies.
Interviews lasted about an hour and focused as much as possible on the
operation of the telephone support operation.
included
in
the sample are listed
and some approximate estimates
in
Figure
of the
number
platforms being supported, as well as the
technical support service.
1
Pseudonyms
(p. 40),
of
number
for-
the companies
along with the product area
customers, products and
of people
providing the
(*** Insert Figure
The sample
about here. ***)
reflects considerable diversity
hardware platforms, and customers.
database products (PCCo)
to
to several
in
terms of the products,
The products ranqe from simple PC
extremely complex systems for automating entire
multi-national manufacturing firms
hundred dollars
1
(BizCo), and range
hundred thousand
dollars.
price from
in
a
few
The hardware platforms
include everything from desktop PCs to engineering workstations to mainframes.
The users
managers
of
these products range from individual PC hobbyists to MIS
to Ai
While
gurus.
many
products are meant for use by
of the
developers (e.g., SmartCo, CompCo, ExecCo, CaseCo and others), some are sold
directly to end users
(e.g.,
PlanCo and PCCo).
3.0 A Case History
Although many readers may be familiar with calling
they may be less familiar with working
history
in
or managing one.
sells
expert system development tools.
lengthy interview with
first
person hired as
voice,
it
is
not
a
a
a
it
full
SmartCo,
The description
time support person.
The case
is
follows.
a
It
coinpany
based on
a
Altl"^uqli
of Smar-tCo
is
it
is
written
in
his
particularly
describes the reorganization of the support function from
one structure (personalized generalists)
in
tiiat
former manager of customer support who was also the
direct quotation.
interesting because
at
line,
This brief case
intended to provide some context for the discussion
is
describes the history of the customer support function
which
support hot
a
to
another (depersonalized specialists)
the face of growing demand for increasingly complex services.
The Early Days
at
SmartCo
customer support, training, and documentation were all one
a total of eight or ten people.
People tended to be
allocated half-time to two functions (like training and documentation), but
eyerybody met together as a whole. At that time, this collection of
actiyities was under the Director of Services.
This grouping made sense
because all three of these functions were concerned with teaching users
about the product, helping them use the product, making the product
accessible to them, and so on.
Initially,
group.
We had
The company only had about two dozen customers
at first,
so there
and 10 customers per full-time support person.
It worked
out that you'd handle between 2 and 5 distinct customer contacts per day.
For any giyen contact, there could be several actual phone calls, since
It always
you'd usually call back and forth rather than waiting on hold.
seemed like you were taking a lot more than 5 contacts a day, but
remember looking over the daily call records (which we called blue sheets)
Part of
to estimate that number, and it really never got much above that.
the reason is that you might spend a couple of days working on a single
were between
6
I
call.
The kinds of calls we got back then were often really deep questions.
Our first customers were really Al pioneers. They were R&D-type places
who were trying new things and wanted all kinds of special functionality.
Often times, they wanted to do things that were not in the user level
code, so we had to talk to someone in product engineering to find the
appropriate functions for them to call.
In a sense, customer support was
filling in the gaps in the product for these customers.
They knew they
were getting a product which didn't do everything, but they still wanted
to stretch it to fit their needs and our job was to help tliem do that.
The other kind of call we got a lot of -- the most frequent by far,
actually -- had to do with installation problems.
It really wasn't easy to
install the software on certain machines, especially if the customer had an
unusual hardware configuration.
Many of these calls were routine, familiar
problems having to do with not following the instructions, but some of
them were real tricky, system level problems.
the early days, everyone -- the whole company -- was in the same
room with 6 foot dividers between the desks, so you could just call out
your question and tap into the expertise of whoever was withiti earshot.
But after the company moved into the new building (1986), people had
separate offices (two persons per office), and you couldn't do that.
If you
knew who to ask, you might run down the hall and talk to them, but that
wasn't necessarily very efficient or even possible.
In
One of the questions that management had at that time was how
many customers a support person could really handle. This was important
because they tiad to know what the staffing requirements would be as the
customer base grew.
Sales were starting to take off, so this was not an
academic question. The support group met to discuss this issue and decided
that 15 customers was a good number, and 20 was an absolute maximum.
Beyond that, it would be impossible to provide the kind of personalized
service that the customers had grown to expect, and that the company
to provide.
wanted
Blue Sheets
Each call that came in was logged on a "blue sheet" which had
various information, like the customer, the software versions, hardware
platform, and most importantly, the description of the problem and the
resolution. The blue sheets were really the life blood of support, providing
not only records of call volume, but also history and continuity for the
One copy we kept
support group. We made 3 copies of each one.
ourselves, one copy went into a file where all of them were collected, and
a third copy went to the product support manager and the president.
In the early days, the president would actually look over all of the
blue sheets, that's how important customer support was for the company.
He put tremendous emphasis on being close to the customers. The customer
service manager felt the same way, so much so that he used to distribute
an illustrative chapter from In Search of Excellence to new employees t^^
Our job was to make the product work for them
help make the point.
The support manager liked to hack code himself, and he
matter what.
encouraged creative solutions for problems and requests.
was explicitly "no holds barred"; you had to handle everything.
in the field would tell the customers that we'd do anything for
them, because part of what we were really selling was a relationship with
So in addition to handling calls, we would pro-actively call
the customer.
the customers once a month, just to see how they were doing, if we could
It
Sales reps
help,
etc.
The relationship with customers was very personal. When they came
for training, we'd make a point of having lunch with thein, getting to
know their application, and getting to know them. Customers had a direct
line to their personal supporter, rather than having to go through the
switchboard. We'd ask about their families, vacations, that kind of thing.
At the annual customer meeting, we'd hang out and drink with our
customers. There was definitely more than just lip service paid to the idea
of getting close to the customers.
Of course, support people would occasionally be unavailable, due to
To
vacations, illness, or other duties (more on these duties in a moment).
handle those situations, the concept of a "default support person" emerged.
This was
the default person would take your calls.
If you were out,
explained to customers, of cour-se, who understood it as a necessary and
desirable way of handling things when their- regular support person was
away. The default support people were generally very busy (this is putting
because they had all of their own customers plus whoever was
it mildly),
away.
The task was rotated among all support staff so that everyone did
Although every effort was made to
default once every 1-1/2 to 2 weeks.
avoid the situation, it occasionally happened that only two people would be
covering for the entire staff of ten supporters -- telephone hell.
Nonetheless, the default support person provided a way to handle calls
regardless of whether the regular support person was available.
The personal relationship with customers was important for the
company for a variety of reasons. First, it meant that customers were
more
succeed in creating productive applications.
Early success
were extremely important to the continued growth of the company,
and support people were supposed to stay involved with their customers to
help insure that success.
We were also supposed to help the marketing
people find and develop these stories into sales collateral: video tapes and
brochures to hand out at trade shows.
Another reason to stay close to
the customer had to do with capturing innovative ideas and spotting areas
where the product should be enhanced. Support people were supposed to
be the conduit between the customer and product engineering for ideas,
not just problems
likely to
stories
.
Growth, Growth. Growth
From 1985 to 1989, the size and complexity of the support task grew
substantially in three different dimensions.
First, the number of customers
increased from a few dozen to several hundred.
Second, the number of
products that the company was selling grew from one to four.
Third, the
number of hardware platforms on which these products ran grew from two
to around ten.
What did not grow substantially was the number of support
people.
In August 1985, there were about 9 full time supporters. By
August 1986, there were about 12, but that number stayed constant
through the end of 1988. Although the maximum conceivable number of
customers per supporter was thought to be about 20, we now had between
Not all of these customers were actively developing
applications, but the number was still way too high.
40 and 50.
Part of the reason support staff was not increased was that the
company was not quite breaking even on its sales. There were some
layoffs, and new slots could be justified only if they would be profitable.
For a variety of reasons, it was very hard to show that adding another
support person would increase profits, so the existing staff was forced to
take on more and more customers.
Since support, training and
documentation were all under the manager of customer services, he would
sometimes take an open slot away from documentation and give it to
support, but that was rare.
The large and growing number of customers put support in a very
awkward position. We claimed to be providing personalized service at a
very high standard. Over the years, we had developed a great deal of
pride and esprit de corps around this theme.
But now it seemed
hypocritical to talk about a level of service we could not realistically
provide.
We could not proactively call customers; in some cases, we
couldn't respond to calls that weren't "crisis level" for the caller for
several days, if at all.
When things grew to this point, it was really just
fire-fighting.
Other Responsibilities
As
I
implied above,
support people did more than just answer the
8
Their other main functions included quality assurance, marketing,
phone.
consulting, and providing input to development on what customers wanted.
Of these many roles, the quality assurance role was among the most time
consuming. When a new product release was being worked on, it was
Support people would
given to customer support for an early shakedown.
report bugs to product engineering and in the process, familiarize
themselves with the new release that their customers would soon be using.
This role -- bug reporting -- was part of the regular duties of a
supporter, of course, since the process of responding to customer inquiries
often involved diagnosing and reproducing problems.
But quality assurance for a pre-release product was a special
responsibility because customer support had to sign off on any product
The theory was that if we were going to
before it could be shipped.
This formal veto
support it, we should be allowed to say if it's ready.
power was a great source of tension at times. A sales person would say,
have those new features"; product
"I can close the sale now if
engineering would say, "the new features are ready"; all the top brass
would say, "we really need the revenue"; but the support person would say,
Testing was known to be
"It's still buggy.
"I haven't tested it yet" or
important, but it was easy to lose sight of that in the rush to claim
Support held its ground in most cases, although it meant pulling
revenue.
When a
people away from regular support assignments to do the testing.
whole new product was coming out, being the default support person could
be a nightmare, because so many other people would be doing testing.
I
"
The other responsibilities were less critical, but still took time.
Marketing activities consisted mainly of getting good stories together for
mentioned earlier.
Consulting was different, kind of
the sales people, as
You might work
an extension of personalized support to the extreme.
personally with a customer, one on one, for several days at a time. This
was a lot of fun and it was also good for the career development of the
These were considered real plum assignments; very
support person.
But they also took you away from the phone and added
desirable indeed.
to the work of the default person.
I
Implicit Specialization
Because supporters were assigned to customers, we were supposed to
Customers use all aspects of the product, so supporters
be generalists.
But in practice, there
need to be familiar with all aspects of the product.
was always some degree of specialization that took place.
The first kind of specialization was by hardware platform. As
mentioned, many of the support calls were related to installation, and
Also, the "native language" of
these problems were all hardware specific.
the two main hardware platforms was different in the early days, and the
All of these factors
product itself has some minor differences, as well.
contributed to a tendency for certain supporters to know more about one
kind of hardware than the other.
I
The second kind of specialization was by software functionality. The
Each piece
product has several major pieces that are logically distinct.
has a different purpose, calls different functions, and has different idioms
For example, the user interface involves an large number of
for use.
features for creating special windows, menus, graphics, and so on.
When
customers make heavy use of interface features and stretch the limits of
the product, their support people will tend to develop some expertise in
the interface. The same goes for any other part of the system.
The third kind of specialization that developed under the personalized
service system was by product.
Initially, the company had only one
product, so this dimension was nonexistent until mid-1986.
But when the
new products did start coming out, certain support people were specifically
assigned the job of supporting the new customers. As the customer base
for that product grew, additional supporters were brought into the pool.
The tendency to specialize along each of these three dimensions was
When something needed testing
reinforced by the quality assurance work.
feature,
it was given to the people who knew the most about the platform,
In the process of testing, the support people
or product in question.
would attempt to exercise every aspect of the system and become quite
So although the formal assignment of customers
familiar in the process.
to supporters implied that supporters were first and foremost generalists,
the level of specialization among supporters was constantly increasing.
Knowledge Overload
As mentioned above, the growth being experienced involved more than
more customers. Existing product had additional features which in
some cases involved rather subtle concepts of knowledge representation
and reasoning.
The marketing strategy for the company involved
supporting new hardware platforms, but that meant learning about new
operating systems (e.g., UNIX, VMS and even DOS), new file systems, new
machine configurations, and so on. New products added entirely new sets
of functionality and potential problems to the support person's list.
Although not all products were available on all machines, and product were
remarkably standard across platforms (a real tribute to the product
engineers), there still tended to be a multiplicative effect in terms of
knowing about each product on each different machine.
In this situation,
it was
not uncommon for the customer to know more about their hardware
and operating system than the support person, which was embarrassing and
damaging to the credibility of the company, even if the person was an
expert in the company's own products.
just
One response
knowledge overload was to create mechanisms
among supporters.
So we created the Red Book,
to this
for sharing expertise
which was
a 3-ring binder that each support person used to keep track of
solutions to typical problems.
It included things like how to make a
certain kind of menu, how to install the software on a network with an
unusual kind of file server, things like that. When people solved an
interesting problem, they would write up a page about it, including any
code they had written, and circulate it to the group.
People would add it
to the appropriate section of their personal Red Book and everyone was
kept up to date.
10
Another mechanism was the SOS system, which we implemented on
our VAX. It was essentially an electronic version of the Red Book, with
sub-directories for each topic area.
You could log into the SOS account
and browse through various messages about past problems and their
Although this was better than the Red Book in some respects
solutions.
(it was centralized), it wasn't really that great.
Messages were stored in
separate files which were not very convenient to use.
This primitive online system was made available to users, as well, on a micro-VAX housed
Apparently, users were glad to have this
at the company headquarters.
resources, but were disappointed at its performance and accessibility.
The New System
The support function at SmartCo has recently been reorganized. In
Rather,
the new system, customers do not have personal support people.
they call in to a dispatcher who verifies that they are entitled to support
and tries to identify what kind support they need. The dispatcher then
This
routes the call to a support person who specializes in that area.
system formalizes and extends the kinds of specialization that were
This allows support people to
implicit under the earlier organization.
It also cuts down on
focus on the portion of the product they know best.
the number of times that the customer discovers that they know more
than the person they are relying on for support.
The old "blue sheets" have been replaced with a special purpose
database, developed by our database vendor for their own customer
support, and modified to suit the details of the new setting.
Each call
which
remains
initiates a transaction in the database
"active" until it gets
Supporters can browse their
closed out by someone resolving the problem.
active calls, and managers can get reports on the overall state of the
All entries are time-stamped, so it's possible to track
support effort.
exactly how long each step in the process takes.
The second innovation
in the structure of customer support is to
"two-tiered" system.
The lowest level of support is purely "online" which is
now delivered through CompuServe, so it s faster, more
People call in and browse through various
available, and more usable.
The second
topic areas populated with all kinds of questions and answers.
tier is the "dispatcher-specialist" service just described. This means that
some of the calls that would otherwise be handled by customer support
people are handled by CompuServe.
move
to a
In some
In the new system, each person has 4 or 5 specialties.
sense, we are still generalists, but in a much more limited sense than
before.
There is a notion of a "primary" and "secondary" specialist, as
well.
Any given person will be the primary specialist on one or two areas,
and a secondary specialist on the others. Specialties arise from the kinds
of hardware or software discussed earlier. Each specialty area has at least
one person covering it, and as many as three.
This
is
the history of technical support at one organization,
11
but
it
demonstrates some of the issues involved
demands on the
staff,
managing that function: the
in
the hectic pace of work, and the complexity involved
something as apparently simple as answering the phone.
analysis,
describe
draw on
will
I
this case
As
and on the other firms
in
in
proceed with the
I
the sample to
variety of organizational forms and management issues as observed at
a
SmartCo and elsewhere.
4.0 Alternative Organizational Forms
The support function
generalists to
as
SmartCo went from being
group
of personalized
These are only two
highly structured team of specialists.
a
a
the possible ways of organizing the technical support function.
indicates the organizational form used
sampled.
"generalists"
calls
and routes them
these forms
4.1
to the
will
be discussed
in
a
specific
(1)
"specialists,"
appropriate specialist;
(with or without a dispatcher);
where each support person has
1
each of the other organizations
in
The three main systems observed are
operator takes
Figure
of
list
and
(3)
where an
(2)
"personal assignments,"
of clients
Each of
they support.
the following section.
Specialists
The
specialist system
appeared
differentiating feature of this system
in
is
that there are formal assignments of
responsibility for different kinds of knowledge.
ways.
The
five of the organizations visited.
Knowledge
is
divided
in
several
As mentioned earlier, the main divisions are organized by hardware
platform and product or product feature.
In
those companies that
sell
products
on multiple platforms, there are almost always specialists for each major
platform (e.g.,
IBM and DEC, or UNIX, DOS, and VMS).
Even though the
vendor's own product may be nearly identical on each of these platforms,
12
customers want to talk
to
someone who "speaks their language.
be substantive differences
in
how
a
There may
also
product works between environments that
One support manager explained
require special knowledge.
"
it
as follows:
When customers call, they have a specific operating system in mind.
We run on both DEC and IBM, and an IBM customer doesn't like to
They just have
talk to a DEC support person or vice versa.
All of our people know our product
completely different languages.
inside and out, but they may not be very experienced in the various
That's why
need to have people with an
operating systems.
experience base in each of the major operating systems we run under.
I
For companies with large products (with many separate sub-systems) or
companies with multiple products, there
or product area.
is
often
a
At SmartCo, there are support specialists for each of the
main sub-systems within the product.
This suggests that there
material for the whole staff to become fully versed
respond
to user questions.
hardware platform, but
database connections.
respond
to
a
in
at a
level
is
much
just too
is
adequate
to
At SpreadCo, the main specialization was by
new specialty had emerged
This was an area
to
support the company's
where an experienced person could
user questions "ten times faster" than the other staff,
specialization
There
division of labor by product
so
made sense.
also
some division
of labor within
support groups between
"application" or "user level" questions versus "technical" questions.
much more subtle
distinction which
information the user needs,
depends on classifying what kind
This
is
a
of
rather than what kind of machine they own or what
product feature they are using. ExecCo has specialists who handle application
questions (how to use the product to achieve
a
certain result),
while most of
the support group are dedicated to providing "statement level" technical support
(how
to use a specific
product feature correctly).
13
Since these two areas are
closely interrelated,
it
may be
difficult in practice to
make the
distinction
in
all
cases.
4.2 Generalists
Generalists were used to provide technical support
companies visited.
In
this system,
in
In
any specific supporter.
to
firms were there
platforms and one product, or where the staff
specialization.
five of the
the staff are responsible for any question on
any product, and customers are not assigned
system appears to occur mostly
in
is
This
only one hardware
is
too small to allow
much
terms of the number of products and platforms they support,
these groups correspond to the "specialists"
in
other firms, but they appear to
be generalists because they cover the entire range of questions that come up.
Two
of the firms with generalists
number
of
actually support
hardware platforms, but they have only two
so specialization
seniority,
(CompCo and OffCo)
is
unfeasible.
but since they
sell
CaseCo has
'
a
full
a
large
time support staff,
large staff with three levels of
a
single product on a single platform,
all
of these
people are generalists.
4.3 Personal Assignment
Assignment
of clients to specific
support people appears
to
be driven by
two factors: installation specific details and the desire to maintain close
customer relations.
installation
site.
For example,
and operation
BankCo uses
of their software
is
this
system because the
highly customized to each user
A supporter who was unfamiliar with conditions
at the client site
would
In fact, CompCo does have specialization within its technical support
group, but it occurs between the groups in the US and in Europe.
Since
communication between these groups is limited, the two US support staff are
forced to fend for themselves.
14
waste
a
great deal of time
getting an explanation of
in
Personal support people provide continuity and familiarity with
for each call.
unique circumstances
customer
at the
tabs on whether the customer
exist with the customer,
4.4
the relevant details
all
The
site.
vendor
to
keep
whether other business opportunities
satisfied,
is
also allow the
and so on.
Hybrid systems
There are
SaleCo uses
a
a
variety of hybrid system that are difficult to label concisely.
system
assignment
of personal
of clients to
support people, but
rather than assigning clients to individuals, they are assigned to teams of
Each team consists
specialists.
communications specialist, and
correspond
to the
needs of
additional staff to operate,
a
of an
operating system specialist,
a
These specializations
product specialist.
Although
system requires
a
typical client.
it
combines the continuity of personalized service
this
with the depth of skills provided by specialists.
BizCo combines specialists and personal assignment
their system,
specialists and
users have two sources of support:
a
local
representative who
provide on-site assistance.
Many
is
a
in
firms have consulting services which can be
the
representatives are also the people who assisted
installation of the system.
In
assigned to the client and can
when ordinary support
local
different way.
hot line staffed by technical
called in
is
a
inadequate.
What differentiates BizCo
Because they are assigned
in
is
that
the design and
to particular clients,
these consultants provide continuity.
In
addition to these formal hybrid systems,
hybrids that develop.
The most common
15
of these
there are
is
a
number
of informal
informal specialization,
which was observed
every company
at nearly
SmartCo, informal specialists seem
When
call
customer
a
becomes
there
is
to get
a
a
calls
with
emerge quickly within support groups.
to
When the next
comes
call
natural tendency to "ask the expert."
in
on
expertise grows quickly and
participating
in
is
related topic,
and their
reinforced by formal assignments (such as
design meetings for
Another common kind
a
Before long, such people begin
of the difficult calls on their informal "specialty,"
all
new release or quality assurance).
a
hybrid develops when customers ask for
of
particular support person (even though there
a
no formal assignment). Some
is
companies discourage these requests because they interfere with the formal
When they are honored, requests from
assignment process.
of informal personal
formally
in
at
challenging problem, the person who takes that
a
expert."
"local
As was the case
the sample.
in
assignment system on top
call
callers create a
of
whatever other system
is
a
kind
is
place.
5.0 The Call-Response Process
Given the diversity of this sample, there
similarity in the basic process of
remarkable degree of
answering customer
calls.
In
this section
I
will
describe the call-response process using concrete examples from specific firms
to illustrate the details.
of the implications of
5.1
addition to tracing the process,
how each step
is
I
will
discuss some
implemented.
Classifying the Call
The
classification of the call
appropriate response.
line
In
support" number.
When
a
is
call
the first step
comes
in,
it
Barring wrong numbers,
16
in
determining the
usually goes directly to a "hot
all
calls
to this
number are
Some smaller firms don't have
seeking technical support.
separate technical
a
support number, so the regular switchboard operator or receptionist serves
preliminary screening function.
At this preliminary level, the caller only needs
to identify him or herself as seeking technical
Given that
caller
a
entitled to that support.
is
valid license for the software
Entitlement
technical support
is
offered, and typically cost 151 of the
Maintenance accounts for as much as 50%
per year.
companies sampled, so entitlement
call.
all
products where
initial
purchase price
revenue
of total
in
some
an important issue.
is
Conceptually, checking the entitlement of the caller
process of classifying the
usually
is
and an up-to-date maintenance
Maintenance agreements are required for almost
agreement.
of the
a
support.
wants technical support, the interaction proceeds by
checking whether the caller
based on having
a
A taxonomy
of hot
distinguishing between two kinds of customers:
is
part of the overall
line calls
could start by
those with valid maintenance
Those without agreements can be further sub-
agreements and those without.
divided into those with valid licenses who have
let
theii-
maintenance lapse, and
those with pirated copies who are trying to steal services as well as software.
Among
the people with lapsed maintenance, the lapse may or may not be
intentional,
and so on.
Each of these distinctions can gave implications for
how the person taking the
companies
will
call
may choose
provide technical support
to
to
respond.
For example,
some
customers whose maintenance
agreement has expired, and then use the fact that support has been given as
tool
to help get the client to
Although classification
is
renew.
logically the first step in
17
handling
a
call,
every
a
call
cannot be neatly classified
actually the problem,
at all.
The
Even when an entitled
caller states
or that there are multiple problems, or that there
classification of a call
correctly identified until
it
is
many cases, there
in
actual outcome.
actually solved.
is
is
remains problematic until the
because one can never be sure that
actually resolved,
because
advance.
what they want, further discussion may reveal that something else
explicitly
problem
in
is
no
call
is
problem has been
a
This poses
further problem
a
no feedback to the hot line concerning the
resolved when the caller stops calling,
Calls are treated as
whether the underlying problem was resolved or
not.
Likewise, the issue of entitlement to support
is
continuously subject to
Several respondents mentioned the problem of customers asking for
negotiation.
services which went beyond what should properly be covered by their
maintenance agreements.
program
for them,
What starts out
For example, customers may want you to debug their
or teach them
as a
how
to write a
program
in
the first place.
reasonable request from an entitled customer can turn into
an unreasonable request quite easily.
5.2 "Logging" the calls
Nearly
receive.
Some
In
all
of the organizations
(including OffCo,
track of their calls on paper only.
is
of the calls
they
most, calls are logged into an electronic database of some kind.
of the firms
records
surveyed keep records
similar from firm to firm:
CompCo, and
In
until
recently,
SmartCo) keep
either case, the information kept
in
the
identifying information about the caller
(name, phone, license number), the product and version number, the hardware
platform and operating system, and frequently, the classification of the
18
call.
Call
logging serves
a
variety of purposes.
support staff to track the history of
all
"covering your ass" when
attention.
If
the
call
log
a
The
call
reveals that
something and
in
back, but no record of
such
complaint would effectively be diffused.
provides
call
return
a
Second, the records provide an indication of how many
on what subjects, from which customers, and so on.
various times of day
is
a
means
calls
call,
of
then
are coming
Data on the volume of
used to determine staffing requirements
of the organizations visited.
The subject matter
about specialties that may be
in
It
are an
of calls
log also
Since
the last interaction the customer
to try
calls at
allows the
customer complains that they aren't getting proper
agreed
in,
it
may extend over several days.
problems are resolved on the first contact, records
important means of insuring continuity.
a
all,
particular problem over the course of
a
several actual phone conversations, which
not
First of
of calls provides
some
in
information
demand or problems that may be developing.
can also reveal product areas that need improvement, or opportunities for
new features
to
address new customer needs. Data on who
customers who are discontented or need additional training.
with electronic
much more
call
easily,
is
calling can
reveal
The companies
databases could generate these kinds of reports (and others)
and believed this information was useful.
The extent
to
which these reports were actually used was not clear from the interviews.
Third, these records can provide
a
history of problems and solutions.
used effectively, solutions to prior problems can be
Several firms with electronic
current ones.
and ExecCo) have systems for indexing their
to the staff.
In
some cases, the
calls
call
a
helpful guide to solving
databases (including CaseCo
calls to
make them more accessible
are indexed by their classification;
19
If
in
others, they use the actual text of the problem description (and solution) to
create the index.
Firms with paper
logs also filed
call
but they seemed less able to use the previous
call
them
in
indexed
files,
sheets for answering current
calls.
Several of the firms
I
visited also maintained databases on problems and
separate from the actual
fixes,
history.
call
The purpose
of
organize and store useful information on certain topic areas.
support staff were asked to write up
more than 30 minutes
but
in
to solve.
SmartCo has
paper-based version
early,
a
These discussions were
in
system with
of this
is
to
At SpreadCo,
discussion of any problem that took
a
recent years have been indexed
entire group.
these systems
system
initially
kept on paper,
an electronic database for use by the
a
at
similar
SmartCo was kept
Each support person was responsible for updating
The
purpose and history.
his or
in
red notebooks.
The
her own book.
goal was to create a centralized resource of practical information about
use the product that could ease the burden on the support staff.
how
Towards
end, the system at SmartCo migrated to electronic mail and then to
a
to
this
bulletin
board that was made accessible to customers.
5.3 Assigning the Call:
Each
were
a
Figure
call
Knowing who Knows
has to be assigned to
a
support person for response.
variety of systems of accomplishing this
1.
The simplest process was used
assigned to specific support people.
to take the call,
If
in
in
firms
There
the sample, as shown
in
where customers were pre-
their support person was in the office
then the assignment problem was solved.
However, people
take vacations, attend meetings, and have other assignments from time to time.
This creates the need for some kind of backup system for the assigned person.
20
In
SmartCo (while
this
system was
person" on duty every day out of
well
use), there was one "default support
in
a
staff of 12.
when only one or two people were
out,
Although the system worked
quickly became
it
'telephone hell"
when the group was short-staffed.
The next simplest assignment process was used
The
was SmalICo, where
limiting case
A more representative system was
at
calls
all
firms without specialists.
in
were handled by
a
single person.
CompCo, where the operator took messages
for technical support on the standard pink "While you were out..." message slips
and put them
messages out
in
of
a
the box and return the calls, making sure not to leave any
messages there for too long.
In
messages and decide which ones
select the calls they
this
kind of system,
they have the opportunity to
to take,
would rather handle.
opportunity to select
The process used
call.
principle,
the staff has the
An "IBM
call"
answer
it
also allows the
efficiently.
the "dispatcher/specialist" system
in
this system,
that calls are not
which may be easier, more familiar, more challenging,
calls
staff to pick the calls they are best able to
In
In
is
While this creates the possibility of shirking,
or more fun.
self-
Although no detailed data was
how these decisions are made, the key point
just handled on a first-in, first-out basis.
complex.
people take calls as soon
Since the support people can sort through the
as they are free to do so.
collected on
The support people would pick
designated "in-box."
is
somewhat more
the assignment proceeds from the classification of the
would get assigned
to the
"IBM group," and so on.
Within
the specialist group (which might consist of several support people), calls may
be assigned based on who
is
available or there
may be further
Although this layering could proceed indefinitely, no firm
21
in
specialization.
the sample had
Another minor complication
more than two layers.
call
is
mis-classified,
5.4 Action at
Once
the problem.
In
that
is
if
a
diagnosing the problem
has been assigned to someone,
many cases, the customer has
answered immediately and
common
this process
must be reassigned.
distance:
a
call
a
it
in
the next step
is
to ascertain
specific question that can be
a
Support managers say that "easy
easily.
calls" are
the technical support organizations sampled, comprising anywhere
in
from 50% to 80% of the
total
volume
"Easy" questions often involve
of calls.
documented features that the user could have read about
One
routine installation problems.
hazards of
of the
boredom that arises from answering dozens
life
the manual, or
in
on
of trivial calls,
a
hot line
is
the
explaining the same
simple procedure over and over again.
But not
all
caller reports
have immediately obvious answers.
calls
symptoms that are insufficient
to
In
diagnose the problem.
cases, there are several paths of action available,
is
the call-back, which can work
provided
may need
in
to
the
initial
calls,
is
the problem
is
these
If
The most common
sufficient information
is
unknown, the support person
This research can involve consulting manuals,
or other support people.
replicate the problem on a
research
two ways.
contact but the answer
do some research.
records of prior
in
In
each of which requires some
form of repeated or prolonged interaction with the caller.
case
many cases, the
computer
at the
vendor
It
can also involve attempts to
site.
When
this
initial
complete, the support person calls back either with an answer, or
is
When the
still
unsolved,
initial
a
request for additional information.
information provided by the caller seems inadequate,
22
the
if
.
support person
usually ask the caller to collect more.
will
to
But
me.")
complicated.
call
if
"See
anything looks funny
if
the customer
is
file
instructions over the phone to
a
technical support interactions
in
who
caller
Now
OK?
return.
tell
what
is
I
level
otherwise unable to perform or
is
"Type
interpret the necessary diagnostic tests:
hit
and get back
the research process gets more
relatively naive,
A common occurrence
the system
in
"phone coaching," where the support person gives keystroke
and then
is
the support person can issue rather abbreviated
relatively sophisticated,
instructions (e.g.,
the caller
If
me what
in
it
D
-
-
I
R
it
-
A
-
colon
Phone coaching
says..."
requires incredible patience from both parties, because
space
-
is
extremely tedious
and often very frustrating.
Phone coaching
is
much more common
Rockart and Flannery (1983)
call
in
organizations that support what
"non-programming end users."
automation software that runs on the UNIX operating
example,
sells office
system.
While users have been trained
in
the use of OffCo's products, they are
quite often completely ignorant about how to use
EMACS.
of
CompCo
analysts.
UNIX or the system
Even the simplest diagnostic tasks require the use
phone coaching
s
is
OffCo, for
relatively
common
in
editor,
of these tools,
the support of this product.
so
The users
compilers, on the other hand, are trained software engineers and
Keystroke
level
phone coaching
is
far less
common
for these kinds of
users
Even where users are quite sophisticated, the support person
confronts the basic problem of getting information about what
their system.
The general pattern
of
coordinated action
at a
is
still
happening on
distance cannot
be avoided unless the support person accesses the caller's computer directly.
23
Dial-in support
increasingly common among software vendors and
is
standard practice among hardware vendors.
in
access as
a
FastCo, for example,
condition of their maintenance agreement.
and others also use dial-in capability as part
is
becoming
requires dial-
OffCo, CaseCo,
of their diagnostic
bag
BizCo
of tricks
(although some customers refuse to allow remote access due to security
restrictions).
While dialing-in may facilitate gathering information to diagnose the
problem,
it
can complicate the issue of who
mentioned above, there
is
will
that some customers want you to do their
on.
to optimize an algorithm,
code,
Several support managers noted
work for them,
to
design
a
At CaseCo, the support manager noted that once
they are hooked:
we have
"There's
to fix
a
Although this rule has
it."
just as
it's
a
in
some cases,
5.5 Finding the
As noted
in
Answer
a
support person
limits,
dials
in,
is
it
easy to see that
a
support person who edits their broken code,
it
that way.
it
vs.
So although dialing
does not necessarily aid
in
in
Conversely, they could be
facilitates the diagnosis of
their solution.
Creating the Answer
the discussion of problem diagnosis,
immediate answers.
user interface, and so
support person making changes to code without asking
or explaining what was done.
problems
a
broken, and then leaves
unhappy about
debug thousands
to
kind of unwritten rule that once we look at the
customer could be unhappy with
verifies that
As
an inherent ambiguity over the limits of responsibility
the vendor has for solving customer problems.
of lines of code,
actually solve the problem.
not
all
problems have
This assertion leaves open the question of whether the
sought-after answers are "out there" somewhere, waiting to be found, or
whether they need
to
be created anew. The answer
24
is
that both situations occur
.
routinely
in
software support. The support people
terms of "finding an answer", but they also spoke
The
workaround."
distinction
clear
is
in
interviewed often spoke
I
terms of "developing
in
some cases, but rather subtle
in
a
in
others
The
call
clearest cases of "finding" answers arise
when
that can be answered by looking at documentation or
There are
a
large
of
prior
sheet.
call
hardcopy
number
PlanCo's project management software require special plotters
Since there are
of their projects' critical path charts.
of plotters available,
When
configure each plotter.
a
a
each requiring appropriate configuration to
work correctly with the software, PlanCo's support
files
a
a
variety of resources that support people can consult to find
answers. Users
to create
support person gets
a
customer
calls with
staff keeps files on
how
to
an output problem, these
provide the resource needed to find the answers.
Another way
introduction,
product.
of finding
answers
no single individual knows every aspect of
they can just
product engineering
development
in
staff
call
in
a
single room.
a
out to the others.
was within earshot
if
a
hall"
to find
found, the answer
is
is
lost.
It
is
in
25
a
few of the
to
a
difficult question
house support and
so the entire
But most
separate offices, so the
common practice
someone who may know an answer.
found.
In
tough question came up.
the sample house their support people
the
complex software
When
SmartCo used
single room with low dividers,
immediacy of face-to-face interaction
down the
in
in
support people who are
FastCo, and CaseCo),
answering phones work face-to-face
companies
a
Therefore, finding answers often requires interaction.
firms sampled (including BankCo,
arises,
As noted
to ask other people.
is
to
"run
When the person
is
But not
that come
in
answers can be found so easily.
all
some
of the calls
pose problems which are completely new and have no ready
answers. A typical example of
of their
some part
fact,
In
"new" problem arises when
a
system (hardware or software) that
is
a
customer upgrades
sold by
a
different
vendor. The example mentioned by one interviewee was an operating system.
The new version
product,
a
of the operating
fact which
system may not be fully compatible with the
was previously unknown
to the
vendor's support staff.
It
turns out that customers often discover such incompatibilities before vendors
do,
sometimes because they are able to get new versions
vendor, or because they have
a
in
advance
of the
specialized configuration that the vendor would
not otherwise have occasion to test.
In
situations
where incompatibility
the problem, diagnosis may be
is
Two courses
straightforward but solutions are not.
of action are possible.
Either the customer can go back to the earlier version that worked, or the
vendor can quickly try
work
in
to
work out the problem and change their product
the new operating environment.
option for the customer
is
going back to
In
a
to
the short tenn, the only feasible
previous version.
term solution, changing the software, clearly involves
a
But the longer
creative process of
adapting the code.
There are other kinds
of situations that require creating
variation on the compatibility problem just discussed can arise
attempts
a
everything
new
is
application.
New
applications can create
ostensibly working correctly.
new answers.
when
a
A
customer
new problems, even
if
At SmartCo, customers were
constantly attempting to create innovative applications, and part of the role of
26
.
customer support was
of this
was
in
to
fill
in
where the product
creating interfaces for sharing data with other products or
between different kinds
of
machines.
Another situation where new problems arise
unreported bug
discovered.
is
work correctly.
is
It
the diagnosis process
correct, or
so on.
In
if
a
previously
of
that the vendor's product does not
is
worth noting that while many callers complain that the
not working as expected,
is
when
is
The diagnosis process involves the same kind
steps mentioned above, but the outcome
product
A typical example
left off.
to ascertain
is
not
if
all
of
these
call
represent bugs.
Part of
the customer's expectations were
they misinterpreted or perhaps never even opened the manual, an
any case, the support person has
written by the customer should do.
unambiguous, but that
what the program
many cases, the expected performance
In
not always true.
is
to figure out
The support manager
at
is
CompCo
noted that the "pinnacle of the support job" was what he called "lawyering":
deciding on what particular statements
in
the language should mean
in
certain
If
there are
contexts
The
response to
initial
multiple ways to achieve
a
a
new bug
is
generally
a
workaround.
given result, then an alternate method
researched, tested, and offered to the caller as
a
temporary
fix.
have known workarounds, but new bugs require creative effort
new, acceptable solution to the problem. According
to the
will
be
Known bugs
to fashion
a
support managers
I
interviewed, customers generally accept the necessity of workarounds for
problems
until
a
permanent solution can be obtained.
the customer viewpoint
support managers
I
is
The important thing from
that they be able to continue doing their work.
The
interviewed said they were keenly aware of this objective,
27
and generally adopted
as their
it
5.6 Bugs and Enhancements:
own.
Prioritization
and Tracking
As new bug are identified, the support
The general
tracking, and fixing them.
prioritizing,
staff enter
remarkably similar across the entire sample.
them into
a
system for
outline of this system was
For example, every manager that
mentioned their system for prioritizing bugs used basically the same categories.
The dimensions
of the categorization
impact or prevalence (for whom,
have or need
work
in
all
a
in
it
prevent work?),
what situations?), and avoidability (do we
workaround?). The most urgent category
situations (no
prevented work
in
were severity (does
of
bugs prevented
workaround available), followed by bugs that
some situations (and had workarounds), followed by bugs that
were merely nuisances and could be avoided by simply not going out
way
to
all
demonstrate them (no workaround needed).
The
least
of
your
urgent category
every case was "enhancement requests," features that work correctly now but
that somebody wants to
work differently.
Some firms had additional categories,
but the basic outline was similar everywhere.
Each firm has some kind of release cycle for updating
maintenance agreement allows customers
produced.
official
Some firms were very
to get these
rigid about only
its
software.
The
updates as they are
updating the product on the
schedule, while others were more willing to create special "patch tapes"
that could be sent to customers as needed.
This seemed to be
a
function of
the newness and complexity of the software, as well as the kind of relationship
the vendor wanted to maintain.
given update or patch tape
manager
of technical
is
In
any event, exactly what gets included
subject to negotiation.
In
most cases, the
support has input into the prioritization and selection
28
in
a
in
process.
In
some cases, as
SmartCo, the support function exercises veto
at
power over what goes out.
6.0 Managerial Issues
Technical Support
in
Technical support involves
priorities
Some
variety of considerations that shape the
and possibilities for how the function
organized and managed.
is
of these issues are implicit in the description of
The purpose
6.1
a
of this
section
how
are handled.
calls
to identify these issues explicitly.
is
Customer relations
One
key issues
of the
in
managing the technical support function
is
deciding what kind of relationship you want to maintain with your customers.
Since technical support
vendor and
its
the primary point of on-going contact between
is
customers,
is
it
a
focal point for
a
The
managing the relationship.
kinds of relationships that are possible are partly determined by the nature of
the product (simple versus complex, cheap versus expensive),
but
strategic decision because good technical support can be used as
differentiating feature for
Customer relations
and distant
to
company
a
in
the firms
in
I
a
a
few hundred dollars.
however, the more service
if
is
a
a
The more distant relationships
As one support
just isn't possible to provide personalized service
it
the product only costs
also
visited ranged from rather impersonal
were associated with the higher volume, lower cost products.
out,
is
competitive market.
extremely close and attentive.
manager pointed
it
expected for the
when
The more expensive the product,
15°6
maintenance
fee.
Likewise,
the vendor has relatively few customers, then service and support are
important ways to keep existing customers happy and develop good references
29
for subsequent sales.
An example
whether or not
should be.
of a basic policy decision
to
commit to
Companies
in
regarding the quality of support
specific response time,
a
and what that time
the sample ranged from "sometime that day, or the
next day at the latest", to "absolutely within four hours", to "one hour
most."
In
details of
is
some companies, the
after
forwarding/hunting schemes were employed
in
how many rings, and various
the local phone networks.
It
was
how response time objectives were actually
measured or what the consequences
The companies with the
the
response was managed down to the
level of
who should pick up the phone
not clear from the interviews
at
of failing to meet the objectives
would be.
closest relationships seemed to be the ones with
very few (but very large) customers.
Given their small
size,
BankCo and SaleCo
had extremely elaborate systems for installation support, training, technical
The support manager
support, and product customization.
at
each firm
emphasized that their job was to provide the best possible service
Although BizCo has
clients.
a
relatively large customer base,
sophisticated set of services that
it
offers to clients.
The
it
to these
also has a
fact that these firms
refer to the licensees of their software as "clients" and not "customers
the relatively service intensive nature of their business.
or
PCCo ship
figure
it
very
Vendors
like
reflects
'
CompCo
the software and the manuals and more or less expect people to
out themselves.
but
it
6.2
Human Resource
occupies
a
Support
is
still
an essential part of doing business,
lower profile within the firm.
Issues
Staffing the technical support function poses
30
a
fairly
uniform set of
problems
articulated
a
the organizations
in
The
visited.
i
basic problem that managers
The underlying problem
finding good people and keeping them.
is
people who have the
kind of catch-22 for the support manager:
skills to
is
do
the job generally don't want to, and people who don't have the skills require
managers
they become really useful.
of training before
many months
Several of the
interviewed offered the opinion that 6-9 months of training
I
required before someone can handle calls competently on their own.
are trained, they no longer want the job.
bind
is
that technical support
manager explained,
an end
"it's
always
"burnout."
somewhere
else,
it's
never
in
managing
it
a
problem.
is
that's just what's expected;
a
result,
a
scapegoat.
so
by the time they do,
When
a
problem
is
fixed,
praise and positive feedback from customers
support staff get yelled
at
all
Some
day.
is
of the
interviewees claimed to be able to take indefinite amounts of abuse without
bothering them, but they acknowledged that
while.
Like
(Hochschild,
many other kinds
of service,
it
gets to most people after
hot line work
is
it
a
emotional work
1983).
The other factor contributing
support hotlines are quite routine.
a
First
many cases, they have been
In
for quite some time before they call,
they are tense, angry, and looking for
As
technical support group
a
Several factors make hot line support staff prone to burnout.
almost every caller has
working on
scarce.
to
As one
itself."
in
But an even bigger problem
of all,
stepping stone
a
Once they
Part of the reason for this skills
seen as an unglamorous function.
is
is
to
burnout
is
the fact that most calls to
As mentioned earlier, support people spend
great deal of time answering trivial questions,
31
repetitively explaining
installation
procedures, and so on.
experience
in
wants
diagnosing tricky systems errors,
to explain to
someone how
better things to do, and
moving out
After amassing
to
couple of years of
a
senior support person rarely
a
use an editor or load
when they decide
to
go do them,
They have
tape.
a
it
usually involves
of technical support.
Several of the firms visited have innovative systems for limiting burnout
and providing growth opportunities
CaseCo uses
a
to technical
support
For example,
staff.
two-tiered system where "primary" support people talk on the
phone with customers and handle
all
of the routine
problems.
"Secondary"
support people are used as backup for the "primary" people and generally don't
As
talk to customers unless they need to.
work and are spared the boredom
SpreadCo divides
its
a
result,
they get more challenging
of explaining trivial things to novices.
support group into three sub-groups, each of which has
This position entails additional status and
"technical group leader."
responsibilities and provides a
growth path for people
in
support.
Several of the firms (including SpreadCo and CaseCo) also
of time that
practice
is
support people actually spend taking
used, half-time (4 hours
spent away from the phones
is
calls.
In
a
devoted
to
a
chance
the amount
where
this
The time
researching outstanding calls and
break from the emotional stress
customers while also providing
firms
limit
day) seems to be the norm.
a
special assignments like quality assurance or consulting.
give the support person
a
to learn
new
These other
of
activities
listening to
angry
skills.
6.3 Relationships within the organization
Technical support
is
generally not an isolated part of
32
a
software company,
but the particular ways
in
which
relates to other functions
it
important set of managerial issues.
support had
a
organization.
In
the organizations visited, technical
variety of different relationships with other parts of the
In
general, technical support gathers information that
this
information
is
sometimes used.
Product development
is
an area that
is
potentially very interested
Every support group
information collected by customer support.
played some role
is
This section outlines some
potentially useful to other parts of the organization.
ways
represents an
I
in
visited
Customers
reporting and prioritizing bugs and enhancements.
in
report bugs through the hot
line,
so this
group
is
in
a
position to
the
know which
ones are relatively more important and urgent. Quality assurance and testing
another role that technical support participated
in.
In
is
some firms, there was
a
separate quality assurance group, but others firms used technical support peopi e
for this purpose.
The
bug reporting and
prioritization function.
chance
to learn
about
a
job of testing a product before release fits well with the
also gives the
new product before customers get
The natural continuation
management
It
of the quality
of the beta test process.
support staff
a
it.
assurance function
is
the
"Beta test" refers to the common
practice of giving advance copies of new software to selected customers for
actual field testing.
Customers who participate
in
beta test typically receive
discount, free copies, or some other special consideration.
support
in
beta testing makes sense for
technical support
is
a
Involving technical
variety of reasons.
First of
all,
oriented towards identifying and reporting bugs, which
the objective of the process.
Also,
a
is
technical support knows which customers
have requested features that are present
33
in
the new release and therefore likely
to exercise
them during the test period.
manage the testing gives them
a
chance
develop experience with the new
to
release before the entire customer base gets
The manager
support
is
at
allowing the support group to
Finally,
it.
SpreadCo provided some interesting reasons why technical
new
well situated to orchestrate the beta test of a
release.
When
product development ran beta tests, only 10% of the customer given the new
release would actually install
result,
very
little
it,
and of those, only
testing actually went on.
When
running beta tests, the installation rate went up
extremely thorough.
to following
who
few would use
it.
As
a
technical support started
to nearly
The difference was attributed
carefully (with an emphasis on customer
and
a
really
100% and testing was
to selecting the test sites
wanted the new features),
up to make sure that software was actually being installed and
used.
Technical support can also provide valuable help to marketing and sales.
At SmartCo, support staff were often called upon
could serve as sales references.
Support people
to identify
at
customers that
PlanCo were able to identify
follow-up sales opportunities by noticing that large construction management
firms often need to transfer plans from place to place.
software but the other didn't, that was
a
If
one location had the
sales opportunity.
SpreadCo takes
calls
from customers whose maintenance contracts have lapsed, but then refers
them
to sales for follow-up.
the customers, they are
in
Because technical support
a
is
in
close contact with
position to get timely and detailed information
that a sales department could not easily get.
Likewise,
customer contact
provides the opportunity to identify market opportunities and trends that
transcend specific customers.
34
7.0 Preliminary Implications for Coordination Theory
Hot line support
come
in,
when
a
a
is
fairly
the answers go out.
hard problem comes
The
routine process for simple problems.
But
a
hot line takes on
a
very different quality
Hard problems require the involvement
in.
of
and they almost always involve multiple exchanges
multiple support people,
information between organizations before the problem can be identified.
problem
is
software.
defined as
a
"bug", then the solution involves changes
The change process
is
predominantly
serial,
calls
in
If
of
the
the
with the problem moving
sequentially from customer support to engineering to quality assurance to
release management.
In
support person may need
the middle
a
lie
range of problems where the individual
to consult others
(or do some other kind of research)
before providing an answer. One can analyze this as
a
series of different
coordination processes that depend on the complexity of the problem being
Figure 2 shows the layering of routines that correspond to different
solved.
degrees of problem escalation.
Figure
2:
Problem escalation hierarchy
Problem
Number
Difficulty
Call-backs
Number of
S upporters
Me cha nj_s_!lL
Trivial
None
One
Pooled
Easy
Few
One
Pooled
Moderate
Few
Few
Distributed search
Hard, no bug
Many
Many
Distributed search
Hard, bug
Many
Many
Serial
The terms "pooled" and
of
"serial" in figure 2 are
(1967) classic discussion of interdependence
process
is
Coordination
appropriate where there
is
little
35
in
meant
to
organizations.
evoke Thompson's
A "pooled"
interdependence (except perhaps
through
situation
where
In
a
hot line,
to the
needed when one step (e.g., recoding) depends on another
is
problem diagnosis) and must be completed
"distributed search"
corresponds
this
can be handled easily by individuals. A "serial" or
calls
sequential process
(e.g,
common resources).
utilization of
not from
is
Thompson, and
in
it
kind of coordination mechanism whereby knowledge
a
is
is
meant
interdependence arises because knowledge
is
to imply a different
shared among
A "distributed search" process
organizational members.
The term
specific order.
necessary when
is
distributed among individuals
the
in
organization.
The sharing or
distribution of knowledge within the organization
important aspect of coordination
in
software hot
a
line.
an
is
the examples
In
I
described, two general kinds of knowledge distribution can be identified.
there
is
"pre-distribution", which
have
First,
the pre-condition for "pooled" coordination.
is
This phenomenon could be modeled as
Many organizations
diffusion process.
a
promote the dissemination of knowledge with training, memos, meetings, faceto-face work settings,
knowledge
in
and other practices.
Second, there
The
is
know where the
actual
skills
1986).
something that might be called "meta-distribution" of
shared or diffused, but
knowledge or
a
skill
required to accomplish
description of that knowledge
are located.
established to the knowledge.
In
is
a
computational terms,
a
36
task
"pointer"
By "knowing who knows," members
pre-condition for efficient task assignment
a
is
not
shared so that others
is
support group can locate needed expertise very quickly.
knowledge
of
question, one would expect these efforts to be more or less
effective (c.f.. Winter,
knowledge.
Depending on the particular kind
is
of the
This form of metain
systems with
as well.
specialists,
In
some cases, the surface features
may signify organizational sub-units
other cases,
deeper understanding
a
which
to
of the
the actual ability to solve the problem
is
a
of
problem descriptions
problem can be referred;
problem
is
not required,
required.
in
either case,
In
because the problem can
simply be referred to the specialist.
The use
of
search process.
who does.
meta-knowledge
to locate resources within the organization
When support people
know what
don't
they ask someone
to do,
When they don't know who knows, they "ask around"
someone who does.
Search
suggest someone else who
is
directed towards somebody
Analytically,
will.
(multiple individuals) and no search
to find
who may know
Shared knowledge
reduces the need for search, while meta-knowledge facilitates search.
way, the knowledge gained by individuals within the organization
Over
time,
available change.
this collective
In
kinds of learning which occur
symbolic, and structural.
identified and solved.
is
in
all.
the organization learns.
One can
the context of technical support:
Substantive learning occurs when
By adding knowledge
a
occurs when the significance of
a
it
identify three
substantive,
new problem
is
to parts of the organization,
substantive learning changes the constraints on task assignment.
learning
Either
made
knowledge and the routines for making
this sense,
or can
one can distinguish between sear
(single individual).
collectively available for the benefit of
a
is
call,
a
caller,
or
a
Symbolic
problem area
changes (e.g., when an important new product starts having "one too many"
problems). Symbolic learning changes the significance of the work for the
people involved.
St-^uctural learning
changes the routines used
and therefore the coordination processes themselves.
37
to
conduct work,
These categories have been identified
but usually
learning,
in
in
the literature on organizational
Researchers with an interest
isolation.
issues tend to emphasize substantive learning (e.g.,
and Olsen, 1976)
1985),
Fiol
in
strategic
and Lyies, 1986; March
cultural theorists emphasize symbolic learning
(e.g.,
Schein,
and organization theorists emphasize structural learning (e.g., Leavitt and
March, 1988).
in
the practical context of hot line support,
all
three aspect of
learning are important and interdependent.
Learning represents an important dimension to coordination theory that we
Our analysis
are just beginning to explore.
to date
(e.g., Malone,
1987;
Crowston, Malone, and Lin, 1988) has compared static organizational forms
one moment
in
While this may be appropriate for computational models,
time.
the ability to learn and change
is
a
crucial aspect of social organizations.
Coordination processes
in
not be static,
Recent organizational simulations
either.
provocative results
relative
advantage
in
organizations are not static,
real
this area
of specialists
(Narayanan, 1990).
is
a
vital
element
in
will
have yielded some
These simulations tested the
The
results indicate that
choosing the most efficient organizational form.
This finding needs to be pushed further.
research to explore learning
so our theory should
versus generalists under differ-ent assumptions
about task assignment, learning, and task load.
learning
at
in
I
am currently planning additional
the technical support context.
This research
emphasize the relationship between learning and coordination and
hopefully enrich our understanding of coordination processes
organizations.
38
in
real
will
.
References
Crowston, K., Malone, T. W. and Lin, F. (1988) Cognitive Science and
Organization Design: A Case Study of Computer Conferencing Computer Human
3, pp. 59-85
Interaction
,
Fiol,
C.
M.
and Lyies, M. A.
Management Review
10,
,
(1986)
pp. 803-813
Academy
Organizational Learning.
of
Hochschild, A. R. (1983) The Managed Heart: The commercialization of human
Berkeley, CA: University of California Press
feeling
Leavitt,
B.
and March,
J.
G.
(1988) Organizational Learning
Annual Review of
Sociologv
F. (1980) Knowledge: its Creation, Distribution and Economic
Princeton NJ
Princeton University Press
Significance, Volume One
Machlup,
:
Malone, T. W. (1987) Modeling coordination
Management Science 33, pp. 1317-1332
in
organizations and markets.
,
March, J. G. and Olsen, J. P. (1976) Ambiguity and Choice
Bergen, Norway: Univeritetsforlaget
Organizations
in
,
Narayanan, K. (1990) A Simulation-based Comparison of Specialist and
Generalist Organizations Unpublished M.S. Thesis, Sloan School of Management,
Massachusetts Institute of Technology
Thompson, J.D. (1967) Organizations
in
Action
New York: McGraw-Hill
Rockart J. and Flannery, S. (1983) The Management of End User Computing
Communications of the ACM 26:10
Schein, E.
H.
(1985) Organizational Culture and Lea d ership San Francisco,
CA:
Jossey-Bass
S. (1986) The research program of the behavioral theory of the firm:
Orthodox critique and evolutionary perspective, in B. Gilad and S. Kaish (Eds.)
Handbook of Behavioral Economics, Vol A. Behavioral Economics (pp. 151-187)
Greenwich, CT: JAI Press
Winter,
,
39
e 1:
jonvm
Software Firms Included
in
the Sample
•T
Date Due
AUG
3 1S9?
dEC
Lib-26-67
MIT LIBRARIES DUPL
3
TDfiO
00701Sm
E