JournalSep 2014

Our agency billing model was completely broken—here’s how we fixed it

Back when I first started freelancing, I billed on an hourly rate. And initially, it was good.

At first, I picked up smaller clients, on small projects where giving an estimate for the 10 hours or so of work, was natural. The hourly rate was a great way to define the scope at a level I knew I could deliver to, while at the same time, protecting me if the client asked for further work and spec changes, since we’d both know how that extra work would be billed.

There were lots of these smaller clients, each wanting small jobs done, as well as ongoing availability for fixes and improvements. This was a good thing–any business needs a stable source of income, and you can’t aim to win new clients for every project–it just costs too much, in both time and resources, to acquire each client, and then commit the time to build a relationship with them, to then discard them.

As we grew, as with many other small, and medium-sized agencies, we retained this hourly billing model, but now applied it to more projects, and also slightly bigger ones. We taught ourselves to get better and better at prioritising and scheduling, and to deal with the pressures that juggling multiple projects like created. But it was still tough.

The problem is that you think you’re giving clients what they want. But in reality, you’re not. Clients don’t just want great work–they want reliability and consistency, too. And despite your best intentions, if you’re jumping in between projects everywhere, you’re just not going to be able to find the focus you need.

Is it really possible to deliver genuinely new thinking and solve complex design decisions, when your attention is divided?

As we struggled to juggle projects like this, it bugged me–I’m fully aware that if you’re introducing a new tool or process into a team, it requires work to get the team into the habit of using it effectively. But if you have to constantly chase and harry people because tasks are being missed, timesheets aren’t getting filed, and your team is overloaded, then it gets to the point where you have to recognise that it’s the system that’s the problem, not the people. The people in our team, while equally determined to work through this, tried to improve their ability to juggle tasks, and find a solution to the problem we faced. Clearly they were feeling pressure from the demands of the projects we were running, and the process we were using to run and bill them.

I had some really valued early critics (including some who were our clients and collaborators) who, when they saw we were working remotely, challenged me on how we intended to deliver the sort of innovation that the top players in the design world (like IDEO) manage to deliver. Our team was geographically dispersed, juggling between several different projects, and not able to focus solely on one thing at once. This left us with little room to build sustained, deep collaborations between team members. While our critics definitely wanted us to overcome this struggle and succeed, their doubts weren’t without merit.

I’m sure this applies to many other industries where you’re not doing routine, interchangeable, process-driven tasks (where you’re doing a similar task again and again, even if it’s for different clients). But it was even more of a challenge given the sort of work we were doing–we’re talking about working with startups, here. It’s widely accepted that launching and scaling your own startup successfully is a tough challenge, and usually requires a huge amount of time and attention. Surely that’s a red flag, if you’re trying to build a team that’s going to divide their attention and attempt to help 5-10 startups succeed, all at the same time?

The issue we faced wasn’t about profitability–we had plenty of great clients, and were billing well. It was about figuring out how we could do a better job, minimise internal stress (even if this wasn’t always visible to clients),and build a happier, healthier team, who could in turn do better work.

So what was the solution?

Well, first, we switched from billing in hours, to billing in half-days. That helped almost immediately. Now that clients were being billed in half-day blocks, they would batch up requests to give us to work on, and prioritise these. We found that with the improved communication and better grouping of tasks, we were able to make much faster progress, and deliver more for their money.

But at the same time, we also had a few projects going on which were big enough to have the team booked on them for full-days at a stretch (even though those days were split in half, two half-day ‘blocks’). It quickly became apparent that these projects were moving far faster, and the team were getting more done.

So we quickly switched to billing by the day, which was better…

But it wasn’t without problems. Since we were available by the day, we still found ourselves sandwiching projects in between one other–splitting a week up to work on 3 different projects. And since our attention was divided, we struggled to keep momentum on the projects that were running–the client would understandably have other priorities, and so projects would stop, and start. Team members would rotate, and you’d still have 5 or 6 people working on a project over its duration.

Internally, it was hard to keep track of time spent–we were constantly chasing timesheets from the team, and trying to figure out whether we were ahead, or behind on our pre-agreed deadlines, making sure we were communicating this to the client.

And pretty soon, we realised we had to change, again

This time around, we went all-out. Instead of quoting a day-rate to clients, we quoted a weekly rate, and reduced our rate slightly (i.e. to be less than we would have previously charged for 5 days of work) to allow for the fact that clients would be committing to less flexible weekly blocks of work.

Instead of having 5 different people on a project over its duration, we pre-booked smaller teams of 3. These 3 people would totally be committed to the project while it was running, with no other project priorities. While we were confident about this before we tried it, we were all surprised by how effective it turned out to be.

It became dramatically easier to estimate the scope and cost of projects when we estimated them by the week. And it was far, far simpler to handle billing. Instead of intermittent, seemingly random invoices, once we’d gathered and checked all team timesheets, we now sent just a single weekly invoice. And that invoice is utterly straightforward. Take the number of team-members involved, and add up their weekly rates, and you have the weekly billable total right there. Simple, flat billing, which is perfect for both the client (who knows how much everything will cost) and for the team, who doesn’t have to be concerned about admin, and can instead focus on the project. If it’s a project running for a longer than a few weeks, with a consistent team, it’s simple to set up a recurring invoice to be sent out at the end of every week.

Even more importantly than admin efficiency, the client knows exactly when work will be happening, and can make themselves free for this–clients are incredibly busy, too–they can’t drop everything, at any point, to give you the information or the feedback you need.

And being less flexible has helped us do better work

When we’re first learning our trade, and how to run projects, I think it’s natural to make the assumption that clients want work done faster. And they do. But they don’t want this at the expense of quality and predictability. Sometimes, it’s better to be less flexible–to say “No, we’re not available right away–but we do have capacity in 5 weeks, and before that point, you can be planning and preparing for the project, so that we can make as much progress as possible once we kick off.”

Of course, it’s nice to be able to tell a client what they want: “Yes, we can get started in a week or two”. But our job is not to go for the easy option and give people short-term satisfaction. Instead, we’re responsible for looking out for their long-term goals, and telling them what’s needed at our end, in order to help them hit them.

And man, it sure leads to far, far better results in the long-run. I couldn’t even contemplate going back to that old way of doing things.

Posted by
Jon Lay

Jon is a Partner at Hanno. He wears many hats, but his primary focus is on leading our engineering and technical operations.