I think you created the pricing schedule based on your costs. The more keywords being tracked the more "crawlers" necessary, meaning the more servers you need and thus more cost. However, I think you need to establish a pricing schedule based on the customer's math. i.e. something that's directly related to revenue (most likely traffic, or maybe number of pages) so that the ROI calculation is easier.
Right now maybe I have a few hundred thousand keywords, is that going to cost me $100K/month? Even though 95% of them generate a small amount of traffic? So now I'm doing a blind ROI calculation. Essentially I have to use your system (and pay for it) before I know how much I'm going to be spending.
If you make your pricing based on something I know (# pages, monthly uniques, pageviews, etc) I have an actual idea on how much I'm going to be paying and I can make an intelligent decision accordingly.
I guess I could use the "personal" free service to see just how many keywords your system will find and be able to do a better calculation, but that seems a little obtuse.
So I think the goal is to come up with a pricing structure that is easier to calculate, and on your end not have people crush your system with too many keywords. This can be done pretty easily I think: bucket keywords in priority (refreshed daily, once a week, once a month, etc).
Priority is based off of a few factors: traffic and historical volatility.
In this way you can intelligently and efficiently monitor hundreds of thousands, even millions of keywords with 1 cheap server (maybe $100/month) and charge out 500-1000/month. In that way you're still seeing fantastic margins, I'm getting great use out of the system, and everybody's happy.