Re: WWP and support

["Rick Quatro" <frameexpert@xxxxxxxxxxxxxx>]

Thanks for the thoughtful analysis; I think it is right on target. Your last
paragraph deals with my biggest problem with the latest WebWorks Publisher
upgrade: its price! I can normally be induced to buy an upgrade, especially
with the promise of new features, bug fixes, etc. But I was disappointed
that the upgrade price was the same as I paid for the original version!
Although I enthusiastically recommended WebWorks 4 to several of my clients
(2 of which bought multiple licenses), I am hesitant to recommend the
upgrade because of its cost. I can't ever remember seeing an upgrade for any
software cost as much as the original version. I understand that the retail
price of the software went up, but I look at a lower upgrade cost as a
"reward" for those that bought earlier versions and often suffered through
bugs, quirky interfaces, and incomplete features. Besides, if I buy one
upgrade, I will buy more; a reasonable price will make an upgrade addict for
life.

Rick Quatro
Carmen Publishing
716 659-8267
frameexpert@mindspring.com
FrameScript Information at http://www.mindspring.com/~frameexpert

> 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... ;-)



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