AnyHosting

Now that I’ve settled into my new day job, I am going to start blogging here and working on web stuff again.

I’m getting very interested in the analytics and accounting side of things, so expect to see more of that here! I’ve got some articles in the pipeline, too.

In particular, I’m very keen on exploring more about how small businesses can take advantage of hosting services (managed hosting, cloud computing, etc. etc.) and how to determine when it makes sense to build your own infrastructure.

There’s a ton of business advice out there, and I tend to get one idea stuck in my head - do one thing, and do it well. There’s a similar idea behind the concept of the Unix shell and commands, although arguably fragmentation has muddied the waters quite a bit.

The tough part seems to be balancing what you think you do best against missed opportunities. Amazon saw the potential to lease out it’s datacenter, which is a huge shift toward developer-facing web services, from direct customer-facing web sites.

I don’t know yet whether this is a good or bad move for them, but it certainly takes guts. I wonder what kind of internal decision-making route this took, to get from someone’s idea to final implementation; it’s surprising to see this from a company already seeing huge success in it’s core business.

I guess I can see parallels in Google and Microsoft, who were able to parlay dominance in one area to success in others. Still, they tend to only actually be wildly successful in one area, and use that to support ventures in the others.

One key to managing a small business that you do not spend full-time on is to spend the little time you have automating the processes that you know you will need, such as:

• billing
• account management (create/remove/update/delete)
• monitoring
• backups

It can be tough to know when you should do a particular task (say, moving records from one billing system to another) by hand, or take the time to automate it. My advice would be to do something by hand the first few times, and if you expect to have to do it again you’ll have the hands-on knowledge you’ll need to automate.

When I have a persistent task that I’ve had to do a few times, I first look for a system to suit my needs, before trying to write it on my own. Since I’ve done a bit of programming in the past, my priority is usually:

1. find an external service that can do this for me
2. find a suitable, well-supported, open-source application
3. create a custom application, using as many open-source modules as possible

#1 is a fairly new addition there, for me I prefer not to used closed-source software with my own business, because it means I can directly modify (or hire someone to directly modify) the processes that run my business. I’m less concerned with software and processes that other businesses use, as long as I can easily integrate and replace their services as necessary.

Google Apps is one example of #1 for email/calendaring services. On #2, for instance managing server rollout, I’d look to things like kickstart and cfengine (or maybe puppet) to keep my servers in sync and up to date.

Account creation and possibly billing can be an example of #3, depending on how your business works, exactly how you configure customer’s accounts, etc. For billing, some find that a spreadsheet or other “offline” software is enough; personally I need a system that reminds me.

The most important things, to me, when writing custom software are:

1. don’t do it if you don’t have to
2. do the simplest thing that could possibly work

Both of these will save a lot of time, energy and money down the road, both your own and in contractor fees.

A simple, custom system is easier for someone to get started with, understand, fix and modify than a complicated, custom system; a system that other people actually know and use will ideally save you more time still, and make people who already understand the implementation easier to find.

In this excellent article on remarkable customer service, Joel Spolsky lays out seven things he learned from doing customer service himself for his “bootstrapped” software company.

I’ve done tech support and customer service in the past, and a lot of these points resonate with me, but particularly #4 (”Take the blame”) and #6 (”Practice puppetry”). I think the title on #6 is pretty self-deprecating, and I wouldn’t put it just the way he does, although his description certainly brings vivid imagery to mind, and packs a more visceral punch.

I’d emphasize more that, when doing customer service, you are on the customer’s side, representing them to the rest of your company (and not the other way around).

“Practice puppetry” is about how to handle abusive or otherwise offensive customers, and not take it personally. This is absolutely key to running a worthwhile business, in my opinion. There’s nothing to be gained by winning an argument with your customer (that link is a poignant response to this post showing someone taking their customer’s frustration personally).

#7 (”Greed will get you nowhere”) really got me thinking. AnyHosting is purposely a very small operation, and we tend to be flexible about billing (e.g. if someone signed up for a year and decides to move, there’s no contract lock-in), but the idea of having an explicit no-questions-asked money-back guarantee sounds like a really great idea. We have a lot of policies about putting the customer’s needs first, that we need to be more explicit about.

(EDIT - removed “over the phone” from “customer service” )