Re: Fair software pricing models

That is a very thoughtful Post Tom, and I really enjoyed reading
it. You brought out several points I glossed over. :) Comments below.

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

I'm in the same position. I have about three packages that
are commercial grade, but I haven't pushed marketing yet,
especially on the AS/400 platform. They are primarly deployed
under OS/390 and AIX, which are about as far apart as you
can get I suppose. :)

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

Marketeers will be the death of us yet. Sure, there may be some
idiot out there running a company who thinks that stealing
software is going to get him ahead, but sooner or later he is
gong to get caught and hung up. It's inevitable.

I'm usually against basing the price of software on the development
cost. It is quite fair to charge a "fair market" price for the software,
and you can usually recoup your startup costs in a reasonable period.
This kind of stuff requires lots of spreadsheet manipulation, but
in general, and from what I understand from people whose opinions
I respect, you should count those development costs as "lost."

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

Don't expect to get much revenue from a smaller customer. Which is
also fair, since their needs are generally gonig to be simpler.
In this case, perhaps two separate products makes sense, if the
high end product is so complex it cannot be made to easily fit
a simple low end application. Oor simply don't market to that
segment of the market at all.

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

Tis true - but nobody ever went broke giving their customers
more value for their money. Only by ignoring customers, treating
them rudely, or not meeting their needs. :)


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

Well, you always have the option of trusting the customer.

<grin> I have been stiffed three times in about 20 years,
and I actually let one customer down once. (And I am ashamed
of that, but there is no way to correct it. The ex-customer
is still pissed, and there is *nothing* I can do to fix it.
(*sigh*))

I guess it is one of those live and learn things. Customers are
generally looking at a vendor to solve some need, and *want* to
trust the vendor. Treating them like a criminal is just plain
counter-productive.




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

Me, I would go for the fishy ones if I was that worried about it.
While a customer depends upon a vendor, a vendor also depends
upon a customer.

This is all tied into "Customer Relationship Managment", for which
there are a lot of different points of view. Mostly, the industry
you are servicing has wildly different points of view. For example,
a customer who tenders a credit card that is declined is no big
deal in the life insurance industry. They just take the premium
out of the value of the life insuance contract; but it may be a
huge deal to a company that is trading stock, and a serious issue
to a company that sells birdfood over the internet and has already
extended terms.

By the way, did I mention that one of my software packages is a
CRM tool... ;)




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

Like you pointed out, for some packages it is easy to tell.
For others, difficult, and for some impossible. Teired pricing
is certanly valid in a lot of cases. I'm just not sure it is
valid with most AS/400 (iSeries) products in 2001. The world is
changing...


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

This speaks very well for your company and for
you personally. :)

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