I like fixed pricing for all sorts of reasons. Mostly I think it’s fairer to the customer who no longer feels a need to track the time you spend at their office – or raise an objection that they’re being billed while you take an emergency call from another client.
The most important thing I’ve learned about fixed pricing is that the process takes much more effort than the old method of quoting a rate.
Under the old hourly pricing model the conversation goes like this:
CLIENT: So what’s your rate
CLIENT: So how long should this project take
CONSULTANT: Oh, (shuffle feet) probably 40 to 60 hours — but if it’s less we’ll bill you less – and if it’s more we’ll bill you more.
See any potential problems with the old method?
There are two major issues. First, the hourly rate is not predictive of the value that the customer gets. Secondly, as Ed pointed out, who goes to the store to pick up milk and would be agreeable to a price that’s ‘between $3 and $5 – could be more could be less’.
This year we’ve been doing fixed pricing almost exclusively. There have been a lot of lessons learned. And I’ve compiled a list of my top 14 mistakes – I call them tips but in reality they are all mistakes I made this year and worked to develop a policy to make sure they didn’t happen again.
The Top 14 Mistakes I Made This Year (AKA 14 Tips For Improving Fixed Fee Pricing)
1. Don’t price a proposal for a slower month and then have the client delay it into November/December. I have one now that I quoted in June, started, found some issues the client needed to fix — and the people just came back (due to their own slow speed performing tasks) asking if we could finish the upgrade next week.
2. Include a statement in your proposal that you expect any issues to be brought to your attention within 10 days — and after that time you’ll be willing to provide a proposal for items which require changes. Do not allow a customer to come back in 3 to 6 months (or longer) after they finally get around to testing their data (and when it’s nearly impossible to easily fix).
3. Include language that you are able to schedule a start date within (pick a # days – we use 10) of receipt of payment (a lot of clients want to give you a verbal and then drag their feet on payment). Stress that verbal commitments are tentative only until you receive the downpayment (we collect 50%)
4. Always price in:
– Project Management (we set every project up in Basecamp)
– One potential call to Sage
5. Include a guarantee that the client will love your services. This increases value — we provide a 10 day guarantee (see also #2 above) on data issues and up to 90 days after our fixed proposal ends we’ll answer any questions/provide support on services provided as a part of the project.
6. Not responsible for hidden damage. This is the phrase we use in every proposal. I started using it after I got a fixed quote from my auto body shop and noticed the phrase on their quote. This gets you out of almost all jams. It also means you can price proposals without having to work in the potential for damaged data requiring lengthy consulting (because if that occurs it is a change order).
7. Assume that there are going to be one or two things that you’re not going to be able to get a change order on. Rather than lose sleep over it — price that into your proposal. The more complex the more you need a cushion.
8. I feel that a fixed fee bid really supports a minimum fee. Even “two second fixes” are never that quick. There’s always a hidden gotcha. In general we don’t quote anything under about $600-$800 (and that would be for work where we don’t travel)
9, Ed touched on this — I started off with a fixed fee billing mentality — yet was using subcontractors who I paid hourly. That didn’t work. The subs wanted to do a perfect job — and because it was fixed the clients wanted them on-site all the time. Instead I split the fee with them ( A good one is probably worth 40%. And I bring them in on the quote so they don’t feel like I’ve underbid).
10. An upgrade means upgrade. Do not spend time on old issues if they’re unrelated to the upgrade. If the client owned a program with a feature they weren’t using — then unless it’s stated in the upgrade you should not be training them on it. Put them on an issues list. This is HUGE. Because of #11 below….
11. Always remember that the last consultant to touch a broken computer or software program is considered by the client to “own the problem” and then needs to fix it. Don’t take on work that is within scope or you may wind up spending days figuring out why a printer keeps dis-connecting from a workstation when in fact you were just trying to be nice when you stopped to “try to fix” an issue.
12. Do a LOT of prep work. Before you go on-site give the client a list of what you need exactly. This helps a lot. If you need a computer make sure you specify that it has your software loaded, you need user rights, etc. Remember when it’s fixed fee you have to be more efficient because the client doesn’t have as much incentive to be efficient themselves.
13. Use the lowest priced option as your safety valve for being “too expensive” — the low option in my quotes is always heavily do it yourself for the client who wants to save money (most won’t choose it) and gives you a handy way to ward off the complaint of expense.
14. Never price an engagement as “up to xx hours” or “up to 1/2 day” or “up to … ” — clients
will see this as “The price will not exceed xxxx” . Don’t believe me? Try pricing this way once or twice.
If you’re done with the work early – the client only wants to pay actual time.
Guess what they’ll want to pay if you go over your time limit/estimate… (Tip: They’ll suddenly demand the fixed fee).
Congratulations – you’ve just re-invented the world’s worst billing method — and it’s called “Not to exceed” which guarantees you shoulder all of the risk and none of the benefit of being efficient or smart enough to solve the problem quickly.
Moral of the story? The price is either fixed or it isn’t – don’t try to ride two horses.
How about you? Are there any that I’ve missed? Any that are so wrong that I should change my methods?