If anyone has questions about Tender, feel free to comment here, tweet @tenderapp, or email email@example.com — Will's girlfriend is in town visiting, so let's keep him as busy as possible!
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.
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.
It always struck me that there was 1001 support desk providers out there... is there really that much space?
(cos if so it's going on my list of maybe projects :))
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.
Why is it a "complete piece of shit"?
(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.
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.
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.
The other school of thought says, though, that if there's not a single point for them all to coalesce around, the uproar won't happen.
If you're determined to screw your customers, of course, nothing will stop them ;)
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.
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.
Nobody leaves. Nobody complains. Everyone's happy.
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?
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.
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.
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 a scary precedent to set by saying that every new feature Zendesk adds, they're going to charge you for. Innovation should be the baseline.
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.
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.
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.
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.
Price discrimination between business types. An enterprise is not a collection of 1,200 one-man companies.
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.
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.
The only way you get current prices for another year is by prepaying by July 1.
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.
* they clearly didn't hear about it in advance
* it was buried in the midst of discussing (minor) new features
* it locked them out of features they had before (XML export)
* it's a 2-3x increase for many people
* the grandfathering option forces them to come up with thousands on short notice, or not at all
* ZenDesk's blog managed to sound totally smug
* nobody from ZenDesk is answering emails, phones, or even comments
Basically, it's a nuclear disaster.
EDIT: Fixed line break issue. I never remember...
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.
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!).
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.
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.
Our key requirement is to be able to reassign incoming tickets and have simple notification to the person it was reassigned.
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.
o Our engineering team uses to track software defects (It's original purpose)
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.
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.
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.
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: firstname.lastname@example.org
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.
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)
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.
The latest 3.8 is not that bad with new theme.
I can even do a free install/setup for any non-profit.
And don't forget the http://hiveminder.com/ from same company.
EDIT: Added links.
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.
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.
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.
We tried it and got hooked.
5 people doing support, thousands of tickets by now and not a single glitch. The built-in wiki also comes in handy.
I had to fiddle for a bit with plug-ins to get email notification and ticket handling to be working properly.
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."
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.
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.
Thanks, other commentors.
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.
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.
It's really not that hard.
Although I have no clue how they managed to do so :)