Thanks! We're getting a bunch of signups right now.
If anyone has questions about Tender, feel free to comment here, tweet @tenderapp, or email support@tenderapp.com — Will's girlfriend is in town visiting, so let's keep him as busy as possible!
ZenDesk pricing has always confused me. They always pitched themselves as 'for the small smart guys' with all the 37s type philosophies that were popular at the time.
And I looked at the product and thought "Wow, this product is actually quite nice!".
But we had 5 staff and only one full time support person, but everyone needed an account. The starting price was a bit rich for how small we were and I met the head evangelist and told him I thought the pricing was a bit off.
I said it was too much for the small guys, and not high enough for the big businesses who pay ridiculous amounts of money for software services (Joel Spolsky has a post on this somewhere...).
His response was "Oh, you guys can have it for free for 6 months!", and I said "But then we'll be locked in, and have to pay heaps in 6 months time."
We ended up using eSupport (which is a complete piece of shit) and now we have a different set up of support users, we could justify the cost of ZenDesk given the current size and set up of the company but now we're locked in to eSupport!
If they just had lower prices for the little guys they'd have got us. They're bloody mad, I tell you.
"We ended up using eSupport (which is a complete piece of shit)"
Whenever I read something like this I can't help but think "Here's a potential customer to whomever can get this right and at the right price". It seems like there's still a huge opening in this market for someone to come in and take all of ZenDesk and eSupport's customers.
Yep I agree completely. We painstakingly trawled through a very large number of support products and in the end it wasn't a case of picking the one that was the best but picking the best of a worst bunch.
I do believe there is a gap in the market for a good but well priced product, but it wont be a simple little ticketing app, the creators would have to understand how support grows out of a one man job into a 50 man job.
eSupport offers a lot of tricks (well hidden in their horrific UI and UX) that save you time, you also have to handle that not just make a 'Oh a Customer has many Tickets!' ROR app with a nice logo.
Weve been with esupport for about 1.5 years now. I find it somewhat cumbersome to do certain things, and there are 2 minor things that really piss me off, but overall, it being a piece of shit, sounds a little of an over statement. I wouldnt exactly rant and rave about it, but it seems to do its job and its not that expensive. Maybe im missing something...
Regardless of who's side you fall on, I think this is a pretty good example of why allowing public comments is a bit of a dangerous move.
(Clearly the more dangerous move here was the price hike, but I do not know the internals of the company that led to the decision, or the interest that it was in, so I will not comment on that so much.)
It is tough to imagine them recoverving from the sort of mob-rule that has formed in that comment thread, even if they restore current pricing plans. So much doubt was created amongst the users, which of course spread to twitter, here, and others, and you can see the discussion clearly degrade from concern to rage.
Public interaction with users can be helpful to show a personal side of the company and try to show a strong effort for support/interaction, but do not forget that this risk exists. As with anything, use with caution.
The backlash would be expressed elsewhere, here at least it's in a place they cannot afford to ignore.
Their actions going forward, e.g. if they purge the posting with the links to competitors, will tell us a lot about them and how they're going to deal with this.
Also note this could be part of an internal faction fight, one faction who's against this move may have wanted this so that they can show this immediate and detailed feedback from current customers to those in the company who put this in place.
In general, I find most "supress information and communications" strategies to not work well, and this is ever more true the more we build our communications infrastructures.
"The truth is out there" and pretending otherwise is likely to be futile.
My main argument is now that they have allowed public comments and such backlash occurred, they cannot feasibly double back on it. Any purging of comments would only further feed the fire and damage there PR as you mentioned.
I don't believe that the avoiding the creation of a public forum on your service's site is surpessing information and communications though, but I will agree that once one is made it must be dealy with judiciously and should not have its contents purged or modified after the fact just because they are not in the companies best interest. This would only hurt further, and from what we have seen so far here, ZenDesk has left all the comments intact.
I also don't think such a backlash would be felt if originated from elsewhere, even from many other sources. The main issue here is that all of the users who are first discovering the issue have no time to think about how it truly effects there business, but are only tossed into a frenzy of doubt and anger.
Many of the users would not know about the complaints and discussions on twitter, and there competitors would not be getting so much attention if it were not directly linked and discussed on their page.
Of course I cannot know how much different it would be if they did not provide such a public discussion area, but it seems now they have provided a universal entry point into the user-mob that they must actually maintain.
We allow public comments on our SaaS blog, but we don't use things like UserVoice for these reasons…
If the issue is a minor annoyance, people will be minorly annoyed. They will probably write support; we'll handle it; they'll get personal service; everybody's happy.
Until they see that other people have it too, and have the option to "vote it up," etc. That way, a minor annoyance a person would live with -- and be happy that you fixed -- becomes a major gripe.
Basically, your customer's interaction should be with you, not other customers, unless other customers are part of the "features" of your product. Because other customers will misrepresent, inflame, etc., meanwhile the initial irritated customer will have his/her first interaction with a tool, not a human being.
The moment they interact with a respectful person AT the company, they will calm down. Not so with a comment form.
Basically, it's an argument that goes both ways :)
But at a certain point in its growth if a company doesn't maintain their own forums alternative ones that they don't have any control over or maybe even knowledge of will spring up. And that will happen instantly in the case of an atrocity like this one.
"Keep your friends close and your enemies closer." If you pull a move that turns a lot of the former in to the latter, well, that bit of advice is probably all the stronger.
Of course, you need to actually respond to them if it's to be of any good and that doesn't seem to be happening as of yet.
Do my eyes deceive me or are companies with 20 employees at their help desk complaining that a thousand bucks is a lot of money?
I think we are seeing a later day MMORPG forum. At some point, it is easier to argue for a patch for your class than get 1 pct more stats, so you stop playing the game and start playing the boards. ZenDesk is the vendor most likely to drop prices by 1k for a single fauxraged posting, so start your keyboards.
It could be 20 third-world employees. A client of mine uses ZenDesk and staffs it out of the Philippines. $1,000 is a ton of money in that regard especially when the hefty increase comes out of the blue. It's also straight users so if you have part time people it adds up quickly. Especially so when you factor in management that have accounts just to check up on staff.
However I think the biggest thing is they didn't sign up for $1,000. They signed up for half that. Regardless of the figures no one likes seeing a 74% raise in cost.
And there's nothing wrong with raising your price by a large amount, even if people are locked in with your product - you simply grandfather existing users.
You accomplish what you want, and your existing users win too because all of a sudden they're getting a great deal.
If there is one thing that I have learnt from "Predictably Irrational" book, it is that humans make their money-related decisions by having a reference point. Zendesk could have always been priced at thousand bucks and no one would have complained. But once you set the price, you provide your customers with a reference point which they are going to use. You can't run away from that.
For example, even though Microsoft Office probably provides a lot more value than what it costs, it they doubled their prices overnight, would you not expect any outrage?
Its funny as we move to SAAS models this seems to be a bigger issue. With Desktop apps you could just stick people on a version and let them keep their existing pricing plan with some sort of dedicated EOL. Anyone wanting a newer/better/prettier version would need to pay for the upgrade.
This breaks down severely on these web models, where you're more inclined to start out with a lower price and feature set while you gain customers, but want to increase the price as you add features (and value)
Its sticky and makes setting your first price point a more critical game.
I wonder if people have thought about "versioning" their SAAS apps. (do they? I don't have a ton of familiarity here). Personally I think Zendesk has to reward their early customers by keeping them at their current rate.
You could try introducing a tiered pricing model. Allowing users on a lower tier to trial features on a higher tier (or introducing the higher-tier features at a limited mode) might help convert users up.
This is what we're looking at with our new startup. We have a core featureset that will probably carry a subscription but other than scaling with more 'users' (in our case, employees), I'm not sure of other ways to increase the price without screwing people.
Short summary: anchor points play a great role in setting human expectations. When plaintiffs ask for exorbitant amount of money*, then usually will get more money than they really deserve because jury's anchor point is set high.
Relative to what they were paying, a thousand bucks is a lot of money. It's also a lot of money relative to what other companies are charging for similar services.
The definition of an "agent" is pretty vague for many places too. We, for instance, could probably have 40 "agents" handling help desk duties if we let our volunteer forum moderators help out with user support issues like I'd like to.
It's not just your help desk though. If you want to escalate tickets to other teams or have your whole company be responsible for customer service (like ours) having users for 20 people isn't that extreme. We have <20 people and everyone has a Zendesk account because we all do customer service. Plus we use it to track resumes, sales opportunities, etc. The users add up fast.
This seems to be a good example for the idea of setting your prices at the right level from very early on. Much better to err on the expensive side then drop them later than significant rises like these. Or initially offer a special deal so people know it will eventually cost more.
Similar thing happens when going from freemium/ indirect revenue to charging. There was a big backlash when invision board did that, even though they could say there product was as good as the paid competition (Vbulletin). They had built a lot of their success on the back of a free product.
I don't think there is anything wrong with raising your prices. The main problem here is how they handled their existing user base. "Grandfathering" is not a short-term, temporary thing, what they're doing is a grace period.
The right way to handle this would be to just let everyone who was on an old plan stay on those plans. Then, instead of a backlash, they'd be getting a sales bump as people who were on the fence signed up before the price change deadline.
Exactly. Anchor that price high, sell it low. Everyone at the old price will think they got a deal and "now its back to normal". Everyone coming in now won't know any better. If they didn't have sales at the old price, they wouldn't have anyway with the higher price anchor. There is never a reason to go too low early when you can just put that price up as a "discount" from the start.
Well, the backslash against Invision Board was mainly because the main guy that was working on it had promised that the product would stay free forever, and suddenly he started charging for it.
I have two licenses from 2005 and 2006 respectively and each one of them was fairly cheap compared to the $149.99 that it costs now, also I've got a perpetual license meaning I get free support, and free downloads of the latests versions for life, whereas the new ones are for 6 months of support, and for 6 months of new downloads, after that you are stuck on whatever version you happen to have purchased.
$149.99 is pretty expensive for a piece of software, considering I can get an entire OS upgrade for $129 from Apple, which does MUCH more than a forum. I'll just keep my luck and my grandfathered accounts alive, knowing I am going to get the value I want out of those accounts.
The issue isn't about an OS being much more than a forum (whatever that means), the issue is actually size of potential market. There are millions of users who would use an OS, but do you think the size of market is same for forums as well? Software doesn't cost high because it costs high to make it, actually it costs higher because the company making it has to survive and make profit (given the total size of market). (Or, of course, it can start making OSes).
I don't understand why they're charging more per user as you scale. I don't know that I've ever seen a service like this.
More typical would be $12 per mo per agent from 1-3. $10 from 4-20, etc.
What's crazy is their service is considerably more expensive than hosted Exchange servers (which give you volume discounts, not increases) though Exchange probably costs a lot more to run. We use Zendesk and like it, but if we ever get to 20 or more support guys the business case for building our own ticketing system will be a slam dunk.
I don't know that there's much of a difference between a company with 3 support guys and one with 4. But regardless, like I mentioned, hosted exchange will service a fortune 500 company at a lower price per inbox than they will service my little group of 11.
We used Zendesk over a year ago with about 4-5 agent accounts. We cancelled it because no one wanted to log into it and we were having a lot of support issues. Fast forward some time and we start up an account again because our support definitely grew beyond a shared support Gmail interface.
We're still using it now but we're also using Assistly.com in tandem. Assistly is in beta but there are great guys behind it and they listen very closely to product feedback. I absolutely expect a full transition from Zendesk in the near future.
Is it just me, or do they have a terrible home page (as far as telling you what their products do)? I had never heard of them before this post, and from the name my first thought was that it was some kind of computer desktop sharing service. I think I figured out from the HN posts that it is helpdesk software. I think that's a pretty major failure on their part.
You can also think one step ahead. When you build your business around a SaaS offer, it is exactly like the old Microsoft way, you depend on the offer and you can be locked in.
Surprisingly people get all excited by the new services with great API, nice teams behind them, bootstrapped, etc. but forget that when you do that you explicitly tell: "Yes provider XYZ, I accept to depend on you and to let you partially control my business.".
This is why for my small bootstrapped project management/code hosting offer I propose a full daily backup and the software as GPL at the same time.
That way my customers get the comfort of SaaS and the freedom of the GPL as they can migrate away without pain. I secured a couple of companies with 10+ active coders this way. They know they can download the software (which has an active community) and install it on their system if they want, when they want, for free. Finally a bit like what Wordpress is doing.
> "As a result, the new pricing reflects the added business value of each individual plan."
I read that entire post and I was unable to find the added business value, these features all seem like they should be part of the product not really premium stuff.
They said "you can change your billing cycle to a quarterly cycle in order to extend grandfathering beyond July 1st billing cycle" - so one additional quarter, if you prepay for that quarter, followed by the increased prices.
The only way you get current prices for another year is by prepaying by July 1.
I don't see why changing prices is a big deal. Apparently there's some pent-up frustration, but there is a real cost to keeping services online. If the price of electronic books doesn't increase over the next two years, I'll be astonished.
And in fact, there's real danger to a business in terms of how they price their product. We were early adopters of RightNow, and we still pay an absurdly low price for their product (which we host) compared to other people, all because it's grandfathered in. Now this hurts them less because we host it, but you can imagine if they had to grandfather us in at the prices they were charging when they were new, it could really hurt them.
I don't get the impression that they prepared their customer base for this. E.g. you know why you're paying "an absurdly low price" for RightNow and you should't be surprised if things change in an adverse way. E.g. I don't know anything about your and their situation, but say they grow so big they have to move to AWS and now providing service to you costs them cash money. You wouldn't be surprised if at the very least they passed that new cost of "goods" through to you.
It seems like the are requiring the grandfathered customers to pre-pay a full year because maintaining two monthly pricing structures is more trouble to manage.
But I'm curious what kind of blowback a company like this might face if existing customers were grandfathered into the old pricing plan for life. Would new customers resent existing customers? Without knowing Zendesk's financial situation, it's hard to know whether they're doing this out of necessity ... but it seems like the goodwill to the customers that made them what they are would be worth the trouble of managing two different pricing tiers.
It seems like they could just create a new product/sku/whatever for each of the new pricing points and then stop selling the old products. You can't buy into the old subscription but it's no biggy to continue to bill it.
The way they're doing it looks like a money grab (pay more now or pay up front for a year and then more later!).
Unfortunately this kind of moves from different companies affect the entire SaaS space.
There has always been a degree of uncertainty when committing your business to one service like this... what if they increase the prices? what if they will close? what if they turn bad and close my data behind a payed wall? will they be able to keep the service up most of the time (just think of the time when Gmail went down..)? And so on...
This is only going to make this worries a bigger issue when choosing to commit to one of these services.
Why don't they change the price for new users, and leave the price for existing customers? Seems like the default way to increase your prices with minimal friction.
I had been evaluating using ZenDesk for our new help desk. Does anyone use any other help desk products that are inexpensive (3 agents) and easy to use?
I think anyone who uses ZenDesk will know that they don't love their users, or treat their tool like a serious business. (More like a cashcow.) Their software is horrible.
There are 6 different ways to view the single table of incoming messages, and it's nondeterministic which one you will come to at any given time. And the first time you accidentally send an internal message to a customer, instead of your team - since the form is the same - you will realize that they must know about that problem, for months even, and have never fixed it.
We were paying $100/mo for ZenDesk around a year ago, and the price was fine. Theoretically good value for the money. But every one of my team hated it so much, they would never actually log in.
o Our legal team uses to track contracts
o Our helpdesk uses to track 20-30 requests a day. With SLA Timers.
o Our Project Teams use to track $20-$30 Million Dollar Projects,
with 30-50 subtasks each with independent dates.
And, oh, Yes.
o Our engineering team uses to track software defects (It's original purpose)
The 4.0 product is mind blowingly awesome, particularly with it's _super_ fast full text query (thanks Lucene). And, you can't beat the price for small shops - $10 for 10 users. (It goes up quickly after that, but the inexpensive buy in is great for small companies.)
It is big, it covers alot of ground, therefore it has large software product illnesses - complicated to setup, hard to master, tricky to optimize to run fast. However, it is a nice product for some heavy-duty task managing once you have it set up and running, absolutely nothing is horrible.
For a smaller project, though, I would roll your own to specific requirements, or would use a smaller package or product - because JIRA does everything and that could be too much sometimes.
The main issue it has is that the management tools are a hack. They (Atlassian) started with a very simple system built around their relational database schema. As more users adopted the system, there was increased demand for a number of additional features to be added in. These have all been tacked in and the fact that they are all an afterthought really shows through in how you setup and manage JIRA projects.
From an end user point of view, JIRA is bad because it is slow, has a bad user interface, and really doesn't quite fit most workflows. If you're trying to track a trouble ticket, which is what JIRA was originally designed for, then it will perform the job adequately. However, anything else forces you to fight more against the system design to get things just the way your work process needs to be.
Very, very, rarely do I burst out in complete and utter laughter to the point at which I actually drop my Laptop. This is one of those times.
I'll take these one at a time:
1) "These have all been tacked in and the fact that they are all an afterthought really shows through in how you setup and manage JIRA projects."
Slowly, but surely, Jira is going to a consistent role/schema/custom field mechanism format for managing issues. Jira _did_ start off as a "Software Defect Tracker", and, if you look closely, you can still see the DNA in the product, but, with things like issue-type-screen schemes, and custom workflows - you really can make it look like whatever you want.
2) "Jira is slow" -
I don't know how one makes it slow. I suppose it's possible. But our 8 Gigabyte Hard Disk, 2 Gigabyte Memory virtual machine currently has 45,000 issues that it's tracking, and searches come back pretty much instantly. Perhaps your Issue database is a lot larger than ours. I find it hard to believe your virtual machine is slower.
3) "Bad User Interface"
- simple. Straight forward. Create, Edit, View, close. Dashboard for custom views of your data.
4) "Doesn't quite fit most workflows"
- Uhm, it has a world class workflow _editor_.
5) "Trying to track a trouble Ticket, which is what Jira was originally designed for" -
Now we're going to inaccurate to completely polar opposite of reality - Jira was originally meant to go head-head with Bugzilla - Jira is a take off of GoJira, which is an alias for Godzilla, from which Bugzilla is named courtesy of Mozilla. Yes, it is rather indirect. Anyways, the point is Jira _evolved_ into an issue tracker from a defect tracker, in much the same way quicken evolved into an accounting package from a personal finance tool.
Anyways, as One who just spent four years using (and dearly loving) jira, and is now having to suffer the absolutely and utter agony of "Upgrading" to a Remedy ITIL suite, I can tell you that the Jira interface is a delight compared to this godawful web interface in Remedy. Now _that_ is a bad user interface - I challenge any remedy user out there to argue differently.
We're not quite ready for prime-time, but my startup (Mad Wombat) is developing a helpdesk application called Tracker, which might suit your needs, provided you don't mind us still being early in our beta.
Tracker is a very tightly focused piece of software; it doesn't have public forums, or a wiki, or a knowledgebase. It just tracks problems, which can be submitted via email, via the web interface, or via the REST API.
Now keep in mind, it's still early in our beta. The major features all work, but there are plenty of bugs, which we're fixing as fast as physics allows. Although we do use Tracker as our own customer support and bug-tracking application, so we've got a lot of motivation to make sure that it works.
Shoot me an email if you're interested: don@madwombat.com
Tender (http://tenderapp.com/ ) is pretty nice, and it looks like it's almost always cheaper than Zendesk. (I think the only time Zendesk would really be cheaper is if you're a 1- or 2-person team that can get by on the starter plan.)
As a support person, I don't find Tender especially amazing, but it gets the job done and never really gets in the way. But, more importantly, as an end user, I find Tender to be much easier and more pleasant to use than Zendesk. I cringe whenever I go to someone's support site and it's Zendesk.
We user Tender and absolutely love it. They've occasionally have issues with delayed jobs, but they were minor quirks. We use it all the time and cannot recommend it enough.
I was evaluating both zendesk and tenderapp last week. Tenderapp had serious confirmed email problems so I had to wait one day to see mails appearing on tenderapp.
This is not the thing we would like as an early startup.
We've to evaluate other services now because neither zendesk nor tenderapp are usable (imho)
Hey rmoriz. I just wanted to follow up on your email issues with Tender. Did you have an open support discussion I could pull up? We certainly strive to provide the best service possible as we built Tender for supporting our own services and clients and are highly dependent on it.
My co-founder wanted to give up tender because no mail were processed so I checked google apps mail forwarding and found no errors.
As I was unsuccessful I've tweeted to @tenderapp and got a reply some hours later stating that there was indeed a mail receiving problem.
As tender/entp also uses google apps, it's kind of scary to see that there was a problem. I mean that's probably the easiest combination to deal with imho.
Sending email isn't processed by Google Apps though, only incoming. We have a dedicated email server that handles outgoing mail. Sorry about the issue though and I would love to take another look at the problem directly. Some edge cases come up that take some pretty deep digging to find out what's wrong between the main email server and the setup on the users end, but that's typically pretty rare. I've only had that happen on a few isolated instances.
I don't recall if RT from Best Practical has the particular feature, but otherwise it's a well-rounded and battle proven solution. It's ugly as hell though.
I love RT. Real solid product with great hackers behind it. And you did not mention that it is open source and takes hardly 1-2 hours if you know your way through CPAN and Apache.
The latest 3.8 is not that bad with new theme.
I can even do a free install/setup for any non-profit.
Incredibly powerful, free, customizable. Expect to learn a little Perl if you want to integrate with external systems, as you can write Perl scripts to handle any transaction.
However, it has both the features that the GP wanted out of the box.
In my haste to up vote this, I accidentally down voted.
We've handled a couple hundred thousand support tickets in RT, some of them hundreds of interactions long, and it's still scaling happily.
Using email for support is liberating and using the web interface is phenomenal too. Can't complain about the licensing, but you'll definitely want someone who knows Perl and or the O'Reilly book.
Another vote for RT. It is ugly and looks (or at least looked) really hacky and old, but once you actually sit down and use it, it blows everything else out of the water. RT is the only help desk software that I've used that felt like it was written by people who had spent real time in the help desk trenches, studied the problem up close and actually got the whole help desk procedure.
The software is awesome to use and was clearly made by someone who spends lots of time using help desk software -- minimal clicks to get things done, automation rules based on predefined responses, etc.
It's also extremely flexible, and fairly affordable. We manage a pretty decent request load (many 100s/day) with a fairly minimal support staff.
If you're raising prices because of a profit issue, then you are prepared to lose some customers (the least profitable ones) so you can better serve the ones that give you a profit.
Which is why I asked for strategies that worked, not "Don't."
I'm thinking the marginal costs to providing this service, as well as the marginal costs for providing FogBugz (and many, many other SAAS apps asides), are so low as to be almost incalculable. Every customer is profitable almost by virtue of being there.
Also, in a company which is growing rapidly, the average price per month paid at any plan level is going to quickly converge on your currently published price per month. That is another factor which suggests using Joel's solution, if you're growing.
How is that not an answer? Do you think ZenDesk has anywhere near saturated their market? Why should a company that's aiming to grow take the marketing hit that comes from pissing off their current customers? Why turn potential evangelists into angry detractors?
Why would you assume that market saturation is the goal instead of the highest possible profit margin?
Not everyone thinks saturation is economically viable, or even desirable. And honestly, in a market like SaaS web apps, it would be very hard to achieve, even at rock bottom prices. A help desk tool, no matter how crappy, is not a true commodity. One will serve a given customer better than another.
Also: I wasn't asking about ZenDesk, I was asking for other examples.
In my consulting business, I raised my rates from $75 to $300 in a couple of years. I wasn't going for saturation, and I didn't grandfather at all. But that is a 1:1 relationship with clients, and I radically changed my business over that time. I also raised the price of my ebook package from $24 to $39 but that was not the same customers, being that it was a one-time sale.
I am a big believer in raising prices. I like more money from fewer customers, which means I can simultaneously work less, and have higher quality interactions with my customers. It's a win/win/win.
My SaaS is one of the most expensive in our category, and for good reason. We're growing at a nice pace, too. I want to think about how we might raise prices, if we decide to, and for future products that I am planning.
And that is why I wanted real examples. Which other people were able to provide me.
I didn't say saturation should be a goal, I said that they didn't have anything like it and therefore had room to grow. When each additional paying customer over a certain number is almost pure profit, the number of customers you have is a pretty important factor in determining how to reach the highest possible profit margin, but you know that.
Nobody in this thread ever said "don't raise prices", so I don't really understand why you're preaching the price-raising religion so hard. Fine, yes, raise prices, but grandfathering existing users might be an easy way to do so without causing a backlash that might hurt your ability to acquire new customers at the raised prices. It's certainly not such a stupid idea as to be "not really an answer", like you claim.
We increased prices at 80legs from on-demand ($2.00 per million pages) to subscription + on-demand (starting at $99 per month + $2.00 per million pages).
It was a success for us. Here's why:
1. It was early on - just a few months after our public launch.
2. We offered a limited free version in conjunction with the price increase.
3. We lost some customers, but they were only worth max $10 per month. We were able to work with some of those customers to setup custom plans that met their needs.
4. The customers we did keep went from being worth $50 - $100 per month to $100 minimum per month.
5. Our major competitors charge thousands per month, so we were still absurdly cheaper than them.
Well, it might have been a success from your point, but I liked your service a lot better on the previous level. I haven't had the need to scraping LOT's of pages yet, but one the previous plan, I felt like I could experiment with it for almost free. Now it's too expensive for that...
You can still experiment with pretty much everything except the API using the basic (free) plan, as long as you crawl fewer than 100,000 pages per job.
At TekPub we raised our monthly subscription from $15 to $19 and we didn't get one complaint. We warned the users ahead of time and told them anyone currently paying $15 would keep paying $15 as long as they kept their subscription going.
http://www.kayako.com/
http://webhelpdesk.com/
http://www.atlassian.com/software/jira/default.jsp
http://tenderapp.com/
http://www.cerberusweb.com/
http://www.thevisionworld.com/
http://www.autotask.com/software/service_desk.htm