Re: Fair software pricing models

Paul:

I suppose I should say that I don't sell products, so I don't care what pricing 
model is used. I do have a few "products" that I believe could easily be made 
commercial grade though, so it might become a personal concern someday.

Further, the company I work for does sell software and does use a tiered price 
scale with probably uncounted ways of eventually agreeing on a price; they 
couldn't be totally inflexible -- I suspect the tiered prices have to be the 
way of giving some reasonable way to start.

But here I'm purely interested in learning "what's fair", not defending or 
promoting a given way. I'm posting in this thread simply as an AS/400 
programmer, not a marketing guy. (When I post here, I try hard to give a real 
answer when I know one is available rather than simply promoting my employer's 
products. I haven't been asked by them to stop yet.)

Okay, so... back to the dabate.

On Thu, 01 November 2001, "Paul Raulerson" wrote:

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

I'm pretty sure the sales and marketing people would think exactly that though 
I don't know. I suspect it would happen often enough to be a concern. However, 
the question has two aspects. First, how do you establish a fair flat price? It 
has to be low enough that smaller customers will pay, but the product has to be 
sophisticated enough to handle larger customers. Do you start with what it cost 
to develop and deliver and just divide by your projected sales?

For the spoolfile management example I mentioned, you can't use the simple APIs 
to list 200,000 spoolfiles although they work fine up to a bit short of that. 
To get to the larger numbers, you are forced to program to the 'Open List...' 
APIs. This can be very different programming. How do you work out pricing to 
cover that while staying within reach of smaller customers?

If it's a flat price, smaller customers are paying for capabilities that aren't 
relevant to them, subsidizing larger customers. Larger customers are getting 
software worth more than what they're paying.

I suppose you could create two products and sell a basic and advanced version, 
charging accordingly. But that will raise the cost of both. There'll be 
dual-maintenance and compatibility issues for upgrades among other problems. 
Both large and small customers would pay more to subsidize having the other 
product available.

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

Visiting sites is easy when the price justifies it. Of course, significant 
AS/400 software may be internationalized. It's not a trivial item, even when 
it's all USA. I suspect you're focusing on big-ticket products here with a 
large sales/marketing staff.

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

I'd guess this also has to do with what type of software it is. We provide 
network access control, security auditing and security monitoring. For any 
given piece, there might or might not be an individual user involved (often 
it's just user QTCP for example); with the various servers and access methods, 
it's often impossible to tell. There may be system-to-system communications 
that must perform at very high efficiencies, but always with a single user 
profile through a single connection. Or there may be thousands of individual 
connections each doing an individual, single task. The programming to handle 
both is much more expensive if you must have the highest possible performance, 
but small customers pay too even though there might be near zero effect for 
them; might as well write in CL for many of them.

Or... Maybe there are extremely few connections and the entire point of the 
purchase is to *KEEP* it that way. How do you set a price there? Certainly not 
by user. And the value to large and small customers may be the same for that 
service or might have no relationship at all.

A product such as PDM, OTOH, would clearly be user-based. The point is that a 
given pricing model might not fit every product. So, what's fair? Should every 
sale require an analysis of the whole customer business to set a price? Or do 
you guess on most of them and only check the ones that sound fishy?

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

This brings up the very difficult questions "What's a charged user?" and "How 
do you bill?"

Then, for a significant product, a customer support call can often totally tie 
up a developer for a day, a week or more. If the cost of the developer is 
$50/hr (with benefits, etc., the cost to the employer), we're talking 
$400-$4000 per call. And that's just the pure hourly cost of a developer; add 
in the costs to have multiple test systems, etc., and the real cost can be 
sky-high. When the number of customers goes up, so do the support calls.

We constantly receive calls that require detailed study of the customer's 
environment; what OS/400 level, what cume level, what group PTFs, when/how 
IPL'd, what authorities/ownerships are set, etc. Keeping track of what a DB2 
Group PTF can do to exit programs in OS/400 V4R3 without a current cume PTF for 
a user profile without sufficient authorities to itself can be a nightmare. 
(I'm mentioning an actual issue that's part of a common category for us.)

We get calls from many small customers that have no significant IT staff. How 
should they be charged especially when they can't afford staff? They have no 
technical background, so many calls are effectively pure training on practical 
ways to configure and use their AS/400, not necessarily our products at all. 
("What's a 'journal'?") Small customers make more fundamental calls; large 
customers make technically demanding calls. (On average; naturally it varies.)

A per-incident scheme would kill support for small customers if we charged what 
the support costs for many incidents. And for many incidents, it's absolutely 
impossible to estimate the eventual cost. Trying to get useful, detailed info 
out of IBM on some issues is like trying to prove to everybody that one pricing 
scheme fits all products for all customers.

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

Amen. That's why we take calls even from competitors' customers. (An issue with 
DB2 Group PTFs was one.)

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

Hmmm... the effect of 'open source' may start being felt in products such as 
ours someday. It'll be interesting to watch.

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

But that's okay while it's not okay to get burned through tiered pricing? 
Again, I don't care what the pricing model is; I'm just interested in 
understanding what's fair.

Of course, "fair" has to have two sides -- customer and vendor. (A customer 
always has the option of simply hiring a programmer.)

Tom Liotta

> ----- Original Message -----
> From: <thomas@inorbit.com>
>
> 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?
>
> > ----- 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/