yes i paid this man 1000

He’s actually pretty good. Interesting to see some of the younger (my?) generation coming up in the world but not leaving the culture behind. Scrivs how about a trip to Ikea with my thousand bucks, looks a little sparse in there.

Scrivs original post


live page rank

Interesting tool for finding the page rank of any page. Uses AJAX to poll 80 different Google servers so you can see the difference across the Google network. Wonder how kosher this is with Google?

via Ajaxian

maintenance pricing model is win win

I’ve really learned alot about pricing since starting UserScape and after this next big HelpSpot release I plan on writing it up, but for right now I just want to share this little nugget.

One of the things I’m most happy about with the pricing of HelpSpot is the decision to use a maintenance model. How the HelpSpot pricing works is that customers pay the license fee only once when they first purchase. After that they pay $49/year per user to continue receiving updates and support. This entitles them to all updates so even when HelpSpot moves to version 2 they owe nothing as long as their maintenance is in good standing.

The reason I love this model is that it’s win win for everyone. The benefits to me are assurance of a reliable stream of income from maintenance, less expense publicizing and pushing for major version upgrades and more freedom to innovate (more on this below).

My customers win because their budgeting is much easier since they know the yearly cost and won’t be surprised by a new expense when the next version comes out, they only pay for the license once, and most importantly they never have to wait for new features.

Since I don’t have to artificially hold back on new features in order to justify people moving to version 2 I can go ahead and add innovative new features right now. That means I have alot more fun building the product and they get to have the new features they want much sooner. No waiting a year for the next version, then getting budget approval and so on.

On top of all that I think it really puts my product at a competitive advantage. The pricing is much easier to understand since there are no variables. There’s no version 2 coming out in an unknown timeframe with unknown features that they might want to upgrade to. It’s all very clear right from the beginning.

And finally the last big win win is support. Since everyone who has a current maintenance agreement is entitled to the latest version it makes support much easier. If there’s a bug that’s been fixed and they haven’t upgraded, they simply upgrade. No fighting with them over purchasing the next version to get the fix. It also means most customers are running the same version (the current one) since there’s no back versions to support.

ads are so layout sensitive

I was reminded of this today because the only ads for HelpSpot I currently run are on the blog of the 9rules network founder Paul Scrivens. The ads were doing OK, but recently he changed the layout, moving the ads off the side and towards the top. Since doing this click through has been much better! Something to look out for if you’re buying ads.

Here’s a sample of his new layout: (you may need to refresh a few times to see the HelpSpot ad)

Thanks Paul!

helpspot bayesian filter accuracy

Minh has posted an interesting tidbit in the HelpSpot forums. His installation currently gets over 100 spams a day and HelpSpot is running at 99% accuracy in identifying them. Excellent!

He also has an issue due to the number he receives and I’m going to work on fixing that up shortly.

helpspot from the customer perspective

Tony Edgecombe has a nice post about his recent transition from FogBugz to HelpSpot for product support along with a great write-up of the installation process and his early feelings about the product.

I love reading these type of posts because it’s feedback you really can’t get any other way. There’s just something different about the feedback you get when someone writes under their own name in a publication (blogs and other types) that you just can’t get in a survey or during support interaction. He points out some of the places where he had a little trouble which is also great to hear.

I agree with his analysis that those areas are too difficult. Specifically the organization of settings and general confusion in the early learning curve about public/private notes and general configuration. These are definitely on the list to be addressed.

Thanks Tony for the write-up. I’m looking forward to your follow up posts as your experience with HelpSpot grows.

beat open source competitors by raising your price

Sparked by comments in this JOS discussion, I thought I’d relay my thoughts on how you compete with open source competition.

First let me summarize the normal arguments:

  1. Companies want support (not just forums, but actual support with phone numbers)
  2. Companies don’t want to rely on part time developers who have no obligation to work on the product
  3. In theory OS gives the customer power to change the code. In practice they lack the skill and/or desire to do so.

OK that’s great and I agree with all of it. But that’s not how you beat open source competitors. That’s not how you stand and fight in a market saturated by open source competition. You need a strategy which leverages the above. Be prepared, I’m about to blow your mind…..

Money is not that important to many people

Yes it’s true!!! I’m not making this up. What is important to them are problems. Problems which cost them far more time/money than a software license.

Take that statement and combine it with the knowledge of the downsides of open source applications. The only logical thing for you to do is raise the price of your software. I see people all the time talk about lowering their prices because of open source competition. That’s exactly the wrong thing to do.

The thing those people are missing is the psychology of purchasing software. If you lower the price you’re narrowing the gap between your software and the open source software. Not just the gap in price but also in perception. You’re making it easier for customers to jump to open source. Why?

Because if you lower your price to $20, it’s now a very small leap to $0. Customers start to think things like: “This probably isn’t much better than the open source product because it’s so cheap”, “This software can’t be offering anything much better than the open source alternative”, “How are these guys going to stay in business only charging $20?”

You need to raise your price and get customers thinking like this: “$200 a license? This must be a lot better than the open source product”, “come to think of it that open source website did seem a bit thrown together”, “I bet these guys have Aeron chairs and plush offices in Silicon Valley. Nice to know they’ll be around long after I’ve left this stinking job”

You get the idea. Instead of devaluing your brand by lowering the price you need to emphasis your brand as premium. Price helps you do this. It’s not the only thing, but it goes a long way. Most programmers don’t think this is true but you’re wrong. A high price implies quality, that’s just the way it is.

A high price also gives your business customers some cover. Again, you think business managers want to go into their bosses and say they got something for free. Not true! Mangers want to cover their asses. You don’t cover your ass by using a free tool with no (formal) support. You cover it by buying expensive tools that have boatloads of support.

I’m not saying you have to be the most expensive product around, but just resist the temptation to lower your price. You’re competing on many levels with open source applications and a low price in many ways is the least important factor.

back up your blog

Doug Martin has got his new project out the door. It’s called and well …. the name pretty much says it all. It’s a cool idea. By adding a little piece of code to your blog his servers will download your blog data at regular intervals and back them up on his remote server. I’m looking forward to watching him grow this and especially to see how he attacks the non-technical users which are his core market.

And he’s also using HelpSpot, hurray!

fogbugz vs helpspot as a help desk

Probably because of the type of folks who read this blog I often get the question of whether FogBugz is an appropriate tool for running a help desk and how I think HelpSpot compares to it in this use. So I thought it would be best to simply post about it so I can point folks here.

First my take on bug tracking vs help desk software. In general these two types of apps are about 85% the same. They basically track requests for action. On the one hand it might be to fix the width of a UI control, on the other a request to fix your printer. In terms of creating these types of applications the database structures and code involved are similar.

I find the big difference to be presentation. The UI is very often one of the most different components. Even this can look similar, but on close inspection you’ll see differences. This makes sense because the people using the two types of products are generally very different. A bug tracking app is almost exclusively used by programmers and software professionals like project managers, etc. These people are very comfortable with the world of bugs and the terminology around software development. In addition, there are often very specific rules to be followed. For instance a bug is found by testing, it’s sent back to programming, the programmers fix it and the testers verify.

A piece of help desk software has a very different core group of users, at least ones like HelpSpot which are designed for internal and external customer support. Formal help desks often have far fewer truly technical people. There may be an IT person who installs the software and/or procure it, but often the actual techs are not programmers at all. They’re often not even overly technical, but have simply been trained to support a few specific products. Beyond that, in most organizations the help desk has little or nothing to do with tracking bugs. In fact they usually do little more than report it when they find one.

All of this leads to the big 15% difference between a bug tracking application and a help desk application. Though I am most often asked about FogBugz (Bugzilla’s a close second) it really applies to any bug tracking application. Here’s what I think.

If you’re a group of programmers who also need to provide some or all of the support for a product and your support is mostly email based then a bug tracking application is probably fine for you. It certainly simplifies things by only having to manage a single app, having one place to login, being able to easily move things between bugs and support and so on. However, if you’re mostly or entirely doing customer service and/or you have less technical users involved then a pure help desk software application is probably a better choice. Not that you don’t need a bug tracking solution (HelpSpot would be a bad solution for that), but you need it in addition to a help desk application.

Going with a help desk tool means there’s less technical mumbo jumbo getting in the way of less technically savvy staff. A dedicated tool also will have specific customer service features which can make your life easier. In HelpSpots case it’s things like the customer portal and knowledge books. Since it’s designed to be customer facing there’s also easily customizable portal templates and email templates. Finally, help desk applications tend to be more flexible with workflows, providing unlimited custom fields, allowing request escalation/automation and in general giving a bit more freedom to customize things since each help desk is different and each company is different.

I would also add that there’s something to be said for keeping these functions separate. As an organization grows, pulling your help desk system out of your bug tracking tool could be tricky, so separation from the beginning may be a good idea if you’re planning on growing your support staff down the road.

Hopefully this helps a bit!