Re: WWP and support

[jeremy@xxxxxxxxx (Jeremy H. Griffith)]

On Thu, 12 Aug 1999 09:13:36 -0400, Ben Slone <SloneB@FML.Com> wrote:

>The purpose of my verbose statement was and is to bring a business view of
>this issue, not to provide scare tactics. I don't consider anything I stated
>to be "scary" - although you obviously disagree with the numbers. As I
>mentioned in my previous email, this issue is of interest to me because like
>Quadralay and many other companies and individuals who are active on this
>list, part of our business is supplying FrameMaker related applications to
>the FrameMaker market. It is in our best interest (and other companies like
>ours and Quadralay) to attempt to understand this market space and its
>customer's needs.

I certainly agree with that last statement; if we, as FM-related vendors
(in our case, mif2rtf), do not understand our customers' needs, we do
not deserve to stay in business.  And we won't; our customers happen to
be one of the brightest and most resourceful bunches around, and they
won't tolerate being treated like mushrooms, not for long at least.

That said, I've been reading the "analysis" here with much bemusement.
I'm hearing that since TAANSTAFL, customers should just accept being
charged high and unpredictable fees every time they need help.  We have
a very different analysis at Omni Systems...

We too faced the problem of a rapidly increasing load of tech support
calls as our user base grew.  But we also saw that in addition to the
*cost* of responding, we had a number of *benefits* from the calls:

1. We found the weak spots in our docs, so that we could add better
explanations.  This is an ongoing process.  We're doing a whole new
reorganization of docs right now, for the update I should be working
on instead of writing this... <bg>

2. We learned what features our customers *really* wanted, in detail.
Many software companies are engineering-driven; we were at first too.
The developers have a vision of what can be done, and they do it.  In
the best of all possible worlds, that vision would match the needs of
the market.  Do I hear laughter?  ;-)  Riiiight...  So the support
calls also told us where we needed to grow the product.  In fact, the
vast majority of the enhancements we include in mif2rtf are a *direct*
result of a customer request.

3. Every time we provided an instant fix to an urgent problem, we not
only had a happy customer, we had more sales from referrals that cheery
soul made.  The best kind of new business.


So when you say there's no such thing as free support, you're right, but 
you're also overlooking the second half of the cost/benefit analysis.
The only way you'd have no benefit would be if you were already perfect,
which belief IMHO is the real fast way to go out of business...

We were still left with the issue of making support as efficient as we
could.  We noticed that within our own company, we use email for all
our technical and business communications.  All.  We use the phone to
make a date for lunch, sometimes, though email is often used for that
too...  Why?  Because it's more effective and polite.  You are never
interrupting someone, they can always answer at a good moment for them,
not just when the phone happens to ring.  And you never get a busy, or
get put on hold, so your own work can flow freely.  It's a no-brainer,
especially for creative types like programmers and tech writers...

So we decided to make our free, unlimited support by email only, no
phone calls at all.  This had several immediate benefits:

1. The relatively few people who couldn't be bothered to look at the
manual found that looking at the index was easier than composing an
email.  They started using the docs.  When someone asked about a point
easily found in the User Guide, we simply wrote back with the paranum
reference, and apologized for our failure to provide adequate indexing.
Takes us under a minute to do that, and offends nobody.

2. The act of describing the problem often leads to realizing what the
answer is.  This is a method well-known to programmers: describe the
coding problem to your cat, and you will usually get the solution.
This also reduced the volume of support contacts.

3. When you send an email, you can easily send the files needed to
reproduce the problem as a .zip attachment.  This saves loads of time
during analysis, as what the customer thinks is the problem often is
not.  We just had one where the *names* of the files was the trouble.
Who would have guessed, without the files themselves?

4. When you *answer* a support email, you can include detailed info
for the customer to reference.  You don't depend on memory, auditory
transcription, and possibly inaccurate notes... for all of which you
will be blamed later.  

5. Your reply can also include an instant fix for any bugs the customer
has revealed.  We *always* do that; we think our customer has handed us 
an important gift, and we want to reward that immediately.  We also give
all subsequent customers the fixed version, as well as making it available
to any current customers who want it.  Again, the benefits for such acts,
in a business analysis, are major.


I could offer a similar analysis for why it is a Real Good Idea to give
your customers free upgrades over a period of time, a year in our case,
renewable at low rates (about 25% of original purchase price per year).
Believe me, you, as a business, will *not* lose by this policy!  You
won't believe how well you will do, by treating your users decently...
and not all of the rewards are financial.  The most important ones,
IMHO, are not financial at all... but the funding is certainly there
to make it work, provided, of course, that you have a good product to
begin with.  Which is yet *another* analysis... ;-)

--
Jeremy H. Griffith                        jeremy@omsys.com 
VP, Software Development             http://www.omsys.com/
Omni Systems, Inc.             California and Vermont, USA               

** To unsubscribe, send a message to majordomo@omsys.com **
** with "unsubscribe framers" (no quotes) in the body.   **