Re: Fair software pricing models

Good Lord - why do you need a key at all? Do you *really* think that large
shops are
going to try to stiff you over a support fee, or that small shops are really
going to have
so many users?

If you do, then think out of the box.

(1) Visit the site if you are afraid it is a large site. Get the facts. Then
set up a charge per
      incident, or per hour for support with them.

(2) Get the facts, if the site has a large machine because they have to
process something really
      fast, but only a small number of users, charge appropriately.

(3) If a site has multiple machines running the same product, charge support
by the number of users,
      or more likley, do #1 above. Let the customer decide what a support
incident is worth.

Of course, you better be *very* sure you provide good support in the cases
above, because if
you don't, then you are likely to wind up loosing a customer, or having a
customer who refuses
to contract with you for support. In my experience, which I bashfully admit
covers about 20
years now, we have dumped companies when they screwed us over, not when
support or their
product because or started off rather expensive. IBM still has good support,
though often you have
to deal with two levels of filtering before you get where you want to do.

Heck, they just came out with the 'Consult Line" service recently, where
they will help you with
*anything*, at a (for IBM!) reasonable hourly fee. You want them to research
how to do XYZ?
Sure thing, they will find someone who knows something about it and set them
on it.

I don't know how successful that will be, but I suspect it will be very
sucessful.

Even Microsoft does that, for $250 per incident.

Management of software companies are facing a totally new world with the
incursion of open source
software, which is what I think is the primary driver right now. How to
compete in a world where the
*cost* of the software itself is insiginfigant, but getting expert support
is a critical need?  It is something
a lot of us are learning, and yes, a few, maybe a lot of customers are going
to get burned a little.
Mostly customers whose companies are ran by clueless bean counters in my
opinion, but then,
you have already guessed I have strong opinions on this subject. <grin>

And I said *clueless* beancounters - not people who really research the
issues and give it thought.

-Paul

----- Original Message -----
From: <thomas@inorbit.com>
To: <midrange-l@midrange.com>
Sent: Thursday, November 01, 2001 12:12 AM
Subject: Re: Fair software pricing models


Paul:

On Wed, 31 October 2001, "Paul Raulerson" wrote:

> What about the simple way, flat fee and charge appropriately for support.

I'm not clear on your point. You mean support pricing should be tiered? How
should it be enforced? If I have a P05 and a P50 but only buy support for
the P05, am I not covered? Would I need a "support license" key that expired
annually? How calculated? (A vendor certainly wouldn't set support price
higher than the purchase price.) Would small customers or large pay higher
support fees?

Tom Liotta

> ----- Original Message -----
> From: <thomas@inorbit.com>
>
> Okay, so what's fair? Per user? Per concurrent user? Per instance? Flat
> rate? And how is it billed? And how should it be enforced?

--
Tom Liotta
The PowerTech Group, Inc.
19426 68th Avenue South
Kent, WA 98032
Phone  253-872-7788
Fax  253-872-7904
http://www.400Security.com


___________________________________________________
The ALL NEW CS2000 from CompuServe
 Better!  Faster! More Powerful!
 250 FREE hours! Sign-on Now!
 http://www.compuserve.com/trycsrv/cs2000/webmail/




_______________________________________________
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@midrange.com
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/cgi-bin/listinfo/midrange-l
or email: MIDRANGE-L-request@midrange.com
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.