This is a response to the opinion written by Michael Catalani in the December 1991 issue of MC. He had written regarding his opposition to tiered pricing for AS/400 software.

As an AS/400 software developer, we spent a lot of time analyzing the different options for pricing our software. We wanted to price our product low enough to help our customers realize a sizeable benefit, yet high enough for us to be able to make a profit and stay in business.

There are a number of ways that AS/400 software companies structure prices. Some charge one price for a software package, regardless of model size or number of users. Others use tiered pricing based on model number, which as Mr. Catalani correctly assumes, was founded upon the notion that a larger AS/400 would support a larger number of users. A few other companies charge based on the actual number of users that will use a particular software package. Each of these approaches has its own advantages and disadvantages.

An advantage with a "one price fits all" approach is that after the initial investment, the customer does not have to worry about the upgrade charges as he upgrades his processor. The biggest disadvantage to this method is that it may cost the average customer more overall. One might guess that a software company could sell the product at the average of the tiered price structure and end up with the same revenue. At an average price, however, many of the smaller customers can no longer cost-justify the purchase. Since the software company must produce revenues to cover the same development costs on lower volume, the price would have to be raised. The one price approach would allow the large system shops to invest in software at a reasonable price, but many small shops would not be able to afford it.

In contrast, tiered pricing causes companies that stand to gain the greatest benefit from the product to carry the largest burden of the cost. This can be justified since the larger shops are probably going to require more support and additional development time may be spent in efficiency and allocation routines when there is the potential for hundreds of users to work with the product simultaneously.

Mr. Catalani mentions that a problem with tiered pricing is that you would have to include the software upgrade charge when planning a system upgrade. This doesn't seem like that big of a problem. You probably have a whole checklist of additional costs that all come with a change as major as a system upgrade.

Another problem attributed to tiered pricing was that of a company spending a lot for software to be installed on a large system, although only a few users would be working with it. The example involved buying a software development tool like CASE. As Mr. Catalani stated, he could solve his own problem by having a small secondary system for development. Obviously, the production system would not have to be as large. Since the ideal development system has different performance requirements than a production system, there would be many other benefits to separating the environments. Thus, this problem begins to look like an opportunity to structure both hardware and software for lowest cost and highest benefits.

The third pricing approach--charging for the number of actual users--has some of the same benefits as tiered pricing. But there are some disadvantages to this approach, too. Unlike tiered pricing, where you can retrieve the model number through OS/400, this method could require a lot of extra development to track number of users. The programming resources used to handle this would be better spent adding important features. There are also some software products where this scheme really wouldn't apply. For example, a software documentation package might be run by just one person, but the output could be distributed to a large development staff. There is another issue when comparing this approach with tiered pricing. Every time your were to add a user, you would have to consider whether there was to be an upgrade charge. With tiered pricing, you would only have to consider this at system upgrade time. The assertion can be made that most companies add users more frequently than they upgrade their hardware.

Of course, any pricing approach will have its detractors. One is tempted to relate licensing software to other kinds of purchases and it just doesn't work. AS/400 software companies may, in time, decide that some other approach to pricing might be better. For now, tiered pricing remains the best balance of fairness and workability.