Archives For January 2014

As I briefly discussed in our “New Year’s Resolutions” blog post, one of our key aims for this year is to formalise and improve the level of support we offer our customers.

We currently offer just one support package, which costs £400 p/m.

Although this works very well for some clients (and will continue to do so), it’s has proved to be simply too expensive for others. Our full support contract is designed to offer frequent, prioritised, out-of-hours support, and most clients don’t need anything so comprehensive.

Instead, they just want ongoing, occasional maintenance for their website, and the reassurance of knowing that someone is on hand to help out if necessary.

We’re therefore introducing a second-tier support contract, which I’m calling “managed hosting”.

This will cost £100 per month, and will offer:

  • Hosting on our latest dedicated server
  • A monthly website report, generated by Sitebeam
  • Access to our support email address, for emergency, out of hours use
  • Small updates and changes carried out free of charge, within limits

This last point is perhaps the most important. Up until now, all clients have been billed at £80 p/h for website updates, with an unofficial minimum charge of two hours.

However, it’s often been difficult to judge whether a very minor amend is simply too small to justify raising an invoice for £160+. In such cases, we’ve attempted to squeeze in the work for free, as a favour; but free work often slips down the priority list, or gets in the way of paid work. This doesn’t benefit us, or any of our clients.

For 2014, all work will be billable. However, for clients with a managed hosting contract, anything taking roughly 30 minutes or less will be carried out for free. We can’t guarantee a fast turnaround, but we will aim to complete all such work within five working days. (T&Cs will also obviously apply; for example, we wouldn’t expect to make more than two or three such changes a month, as a rule).

Where a change will take longer than 30 minutes, we will carry this work out at £60 p/h, with no minimum charge. This obviously represents a reduction on our previous hourly rate; the intention being that the new lower rate will be offset by the cost of the monthly support contract.

However. In the absence of a support contract, an hourly rate will no longer be available. It will be necessary for clients without support contracts to book a full day of our time, at the standard rate of £400.

I genuinely feel that this will offer a better service to our clients. This new support structure isn’t designed to increase our income; as I say, I hope that the monthly fee will be offset by the lower hourly rate.

Instead, it should mean that there will be no ambiguity about our responsibilities once a site has launched, and no confusion about whether or not a particular change request is chargeable.

(Incidentally, it will be perfectly possible to set up a managed hosting contract for a site hosted elsewhere; as long as we have sufficient access to that server, we can still offer the same support contract.)

I’ll soon be updating our rates page, and producing a more detailed explanation of exactly what a managed hosting contract will offer. This will cover the exact specification of the server, discuss the “Sitebeam” report in more detail, and generally clarify the conditions for any free work. I’ll also provide details of how a managed hosting contract differs from a full support contract, with clear examples showing how individual requests would be handled/costed under each one.

If any clients reading this have any questions, please get in touch. Otherwise, watch this space!

Resolutions for 2014

Chris Gibson  —  January 8, 2014 — 1 Comment

This might be a bit of a hackneyed blog post for this time of year, but – there you have it. These are more for my own reference than anything else; a list to check each month, to make sure we’re on the right track.

These, then, are our New Year’s Resolutions for 2014.

Stop issuing ballpark costs

We’ve frequently (and especially recently) been caught out by clients wanting “ballpark costs”. These are the chicken-and-egg projects, whereby a client won’t commit until they know the likely cost – but you don’t know what they really want until they commit, so you can’t estimate costs.

Our solution has always been to ask the client for a budget to work to, and then provide a spec for a website that delivers as much as possible, within this budget. Too often, though, we’ve failed to do this, and been persuaded to issue ballpark costs regardless.

(This merits its own blog post, I think. Essentially, by asking for a budget up-front, clients often worry that you’ll charge them that full amount, rather than possibly quoting them a figure that’s comfortably lower. However, this is the wrong way of looking at it. We should be charging them their full budget, if that’s what’s available – our job is to get the maximum return for the client’s money. I always feel that it’s similar to “sniping” on eBay, where people incrementally bid tiny amounts on an item to get a bargain. If that item then goes to someone else for a higher figure, and you’d have been happy to pay that higher sum, then you really should have just bid the maximum amount you were happy to pay in the first place. Establish how much you can afford to spend, and then get the best possible product for your money).

Anyway, I digress. A ballpark cost very quickly becomes a fixed cost, within which the client feels they can demand pretty much anything they want. No more ballpark costs — I firmly believe that if a client can’t give you at least a rough budget before you start, they aren’t really serious about the project. A quick test for a client who claims not to have a figure in mind, is to quote ~£50k. When that comes back as “far higher than we expected”, simply ask them what they expected. That figure is their budget.

There are caveats, as always. If a ballpark figure is genuinely essential (for example, if a sales department is trying to sell in a new tool to their management team, and honestly don’t know what funding will be made available), then I’ll always (a) quote high, and (b) set aside some concrete time to review the initial spec before eventually starting work. If the spec exceeds the ballpark, then the ballpark must be revised.

Offer formal support to all clients

We’ve always, since starting the company, struggled to find the best way to support existing clients and projects. As our client base has grown, the general level of support requests — bug reports, or small “can you just…” changes — has grown hugely. We can literally lose days to handling these requests, often without ever raising an invoice.

One solution we put in place was to increase our hourly rate to a fairly high level; this made it viable to carry out — and invoice for — an hour or two of work here or there. However, this still leaves a lot of very small jobs (say, half an hour or so) un-billable, as I try to weigh up “keeping the client happy” with “charging them £200 for a fairly small job”.

What I’ve realised, though, is that by keeping these clients happy, we start to let down other, paying clients, because the small pieces of work distract us from the larger, important projects. For 2014, all work will be billable.

I have a grand plan as to how we can implement this, in a fair and constructive way. My next blog post will go into much more detail. Watch this space.

Always be professional over email

OK, 99% of the time my emails are professional, calm and helpful (I hope). However, on some projects — especially those that started with a ballpark cost! — it’s easy for frustrations to boil over. I do occasionally find myself writing long, slightly tetchy emails that go into far too much detail. Emails which spend far too much time explaining why I think a request is unreasonable, or what underlying external issues I feel have caused a specific delay or problem. This is almost always unnecessary, and has no benefit.

This year, all emails will be replied to with a straight bat; polite, friendly, and to the point.

Check emails at set times

Also regarding email, I really need to stick to my own policy of checking emails at set times. This works extremely well; I don’t enforce it for staff, as I think it’s a personal decision, but I find it hugely increases my own productivity. However, I do find myself drifting back to my inbox when I need a break, or when I’m simply procrastinating. Not this year.

Drop IE8 support

Sorry, Windows users. If you’re still running Windows XP (which was released in 2001) and you refuse to use Chrome or Firefox or Safari rather than IE8 (released in 2009), then we can’t help you. The websites we build might work. Should work. Almost certainly will work. But they won’t look great, and there are no guarantees either way.

Transition to Laravel or similar

This is more of a technical goal than a resolution. This is the year that we’ll leave our current PHP framework of choice (Codeigniter, now discontinued) and switch to something more current. At the moment, the best option would appear to be Laravel, although this may yet change. What we will be doing is assessing a few frameworks, making a decision and then transitioning to it. This will be a fairly major shift, but a necessary one.