============================================================= -----Original Message----- From: "Charles Mills" <[EMAIL PROTECTED]> Sent: 6/4/2006 10:35 AM To: "[email protected]" <[email protected]> Subject: Re: the "why" of tiered pricing (Was RE: Using Java in batch on z/OS?)
> bigger datacenters should pay more for electricity Well, yes, they probably do. Not more per kwh, but more in total. Less per kwh, but more in total. And that's how most MIPS charging works also, I believe. As I more-or-less said in my last para., no one thinks anyone should pay more, but most think some should pay less. Unfortunately, some paying more is a necessary corollary of some paying less. > you joined the party because of incomes, not because it is more fair model You bet! And yes, I thought I was quite frank in my first post about how yes, we were "looking for more efficient ways of extracting money from customers." It sounds like a bad thing when you phrase it that way, but we were in that business, we had significant expenses, and were not - if you look at the month-to-month picture - consistently profitable or consistently cash flow positive. We needed money from customers to survive, and I think greater efficiency is generally a good thing. While we're on the topic, the "right" way to charge more IMHO is to charge for something that parallels the business benefit. We were a file transfer product. I would have liked to have charged by the megabyte, not by the MSU, but we had no rigorous and enforceable way of doing so - plus we would have been a small company fighting the industry "standard" which is seldom a good thing. The sales guys say "when you explain, you lose." The MIPS pricing model is terrible - it's just the best model we had. I used to give the example that you buy a couch for $500. Several years later you add a new bedroom onto your house - and the furniture store calls you up and says that now that your house has more square feet, you owe them another $100 for the couch. Charles ============================================================= Greetings, 1. Charge by machine size: The implication is that a bigger machine means that your product is used more. Thus, the business benefit somehow correlates to the machine size. This is a dinosaur, but still widely used because it's simple accounting, but not fair. Downside: Someone, either the software vendor or the customer, is benefitting at the expense of the other, because there is no accurate measurement of benefit or actual usage. It's just a guess that there is some correlation of machine size with usage/benefit. 2. Charge by transaction. More transactions means more business benefit, thus your customer pays for higher usage that correlates to the benefit. Downside: How to account for the transactions in a non-intrusive, yet accurate manner? Monthly SMF reports or custom reports sent to the vendor? Tedious and error prone. Automatic TCP/IP transfer of accounting from customer to vendor? Some sites may have security concerns with this approach. Also, a "spike" in usage may cause an unpleasant invoice to appear without warning. May use a "governor server" that limits the number of transactions per second/minute/day/whatever. When the limit is reached, subsequent transactions are delayed to limit the throughput. The governor must be aware of "hot" and "cold" times for transactions (multiple service limits through-out the day, week, month, etc.), instead of using "one size fits all" transaction limit. A phone call to the vendor (or an on-line web page) to order a higher transaction limit can increase capacity in just a few minutes. The governor may even be configured to increase capacity, within pre-defined guidelines, by automatically contacting the vendor website to avoid service delays. 3. Charge per seat: For human-interactive products, like a debugger, more concurrent users means more business benefit. Like renting a delivery truck to send stuff to Phoenix. If you also want to send stuff to Portland, you must wait for the truck to return from Phoenix, or rent another truck and concurrently send stuff to both places (and pay for two trucks instead of one). Concurrency can be measured through various means, including global enqueues or TCP/IP-connected servers that manage floating licenses. When the limit is reached, no new sessions can start until some sessions end. A quick call to the vendor (or an on-line web page) to order more seats can increase capacity in just a few minutes. The floating license manager could be configured to increase capacity by automatically contacting the vendor website. Downside: Applicable to human-interactive products and difficult to extend to "behind the scenes" products (like automatic compression or encryption services -- see item [2]). All of the above are dancing around the fundamental notion of usage-based pricing. The more a product is used, the more benefit the customer is getting from the product and the more that customer should pay (throw in whatever volume discounts you like to stay competitive). Jeffrey D. Smith Farsight Systems Corporation 24 BURLINGTON DR LONGMONT, CO 80501 303-774-9381 direct 303-709-8153 cell 303-484-6170 fax ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
