|
Thursday, June 13, 2002 |
|
Mappoint.NET I was pretty excited when I saw that someone was finally rolling out a commercial web service. The application I am working on currently is one that could benefit from some mapping and we looked for a fit. We got a demo account and started trying things out. Looked good. Now time to figure out the business side of things. Time to figure out cost, etc. We couldn't find the pricing anywhere on their web site. We finally got pricing via email from a representative. Let's hope other vendors out there do not follow Mappoints lead in regards to pricing. They have come up with a pricing model that satisfies two constituencies in my mind. Large Corporations (per user) and Ad Supported Web Sites (per transaction). Let's take a look at each model. Per User
Note that the way these fees add up are not that you get the per user fee of your highest number of users. It is cumulative. i.e. for 1500 users you will pay $299 for the first 250, $120 for the next 750, and $48 for the last 500. Total cost for 1500 users = $248,499 per year at an average cost per user of $165 per year. This might make sense for a large corporation making heavy use of the service in a GIS application. In fact it might save them money. Per Transaction
This makes sense for a public web site earning revenue on a per transaction model, i.e. advertising. If an average web site is receiving a $40 cpm and displays 3 ads per page this means that just a fraction of the revenue per page, 1/16, is going to Microsoft to pay for the mapping. This model makes sense. Lets take a third example now. I decide to come out with a web based multiple listing service (MLS) for use by small real estate offices that can't afford a dedicated MLS connection. I decide that I can charge $35/mo/agent for this service. I want to offer mapping as an addon and figure I can charge an additional $10/mo/agent. Which model do I use? With the per user model assuming I had 1500 users providing mapping is going to cost me more than I charge and I will lose $45/mo. That doesn't even take into account that I would probably like to see some margin, say 50% that I keep! Given the margin that means I would have to charge $27.61/mo/agent which is almost the cost of the initial package. If I go with the per transaction based model I could estimate the number of requests my users will use and amortize the cost of those transactions. Let say that for the same 1500 user scenario that I figure out how far 7.5M transactions will go. With 1500 users and 250 workdays per year that allows each user to have 20 transactions per day. I can provide those for an incremental cost of 2.77/user. Add my margin and we are in the ballpark as far as cost, around $5. What happens however if the users love the addon and use it more than 20 transactions per day? If they jump to 40 I just lose my margin. If they jump to 60 I am in trouble as I am now losing money and may have to adjust pricing. There just doesn't seem to be a good model for this scenario. It is really to bad because it means that huge number of isvs out there probably won't be including this functionality in their applications. Let me know what you think. 9:38:30 AM 
|
|
Well I haven't written anything in a while. Been heads down on a very large .NET project we are working on. Shooting for a beta in October and hence have been putting in some long days to meet that date. 8:31:10 AM
|
Last update: 10/25/2003; 12:28:06 PM .
