My client said 'yes' to my estimate. What now?

You might be thinking “that’s a silly question”, but there are several important things to do before you start working on the project. Let’s unpack some of the main things.

Always agree a contract (and assume you won’t be using it)

It’s supremely important that I make clear that we are not lawyers, and this isn’t legal advice. I’m just describing our experience running a successful consultancy in the UK. If you think we’ve got it wrong, please speak to a lawyer you trust (and pay for).

Alrighty, here we go then.

We never, ever (ever) start work without a contract being agreed with our client in advance. There are a couple of important reasons why it’s important to have one.

Having a contract shows you’re serious

For us, the usual conversation with a client at the point of the sale goes like this:

Client: We’d love to work with you!

Me: Fantastic. We’re very excited to get started. We have a standard contract - can I send it to you?

Client: yeah, that would be great

You’re already on the front-foot by having a standard contract. Instead of the client dictating terms to you, you can start the conversation with them based on what you’d like from the agreement. Don’t forget, buying your services might well be a novel experience for your client too, so guiding them by having a contract is a great thing to do.

 A contract protects both parties

Having a contract should be in the interest of your client. If they demur at having one, you need to question why, and make sure you’re working with the right people.

 Assume you won’t use the contract

This might sound perilously counter-intuitive, and I’m being a bit dramatic with language here. What I’m trying to say is that you should assume your contract is the last resort when sorting out differences which might arise.

You will, inevitably, have a difference of opinion with your client during the course of a decent-sized project. You might have forgotten to do something, they might be unreasonably asking too much of you. They might pay you a few days late because of a banking screw-up.

I always tell our clients that the contract is important to get right, but is going in a drawer in the hope it’ll never be used. If you’re thinking “what does the contract say?” often during a project, I’d argue that your relationship with your client isn’t right.

Note that I’m not saying “don’t care what’s in the contract”. Not at all. Just expect that you’ll find more humane ways to resolve your differences.

 What should be in my contract?

I think this is a good time to remind you that I am not a lawyer, and this is not legal advice!

A great friend of mine, who runs a big data consultancy, gave me some sage advice on the bare minimum you need to have, and understand, in your contract:

  • Cost: how much the project will cost the client
  • Term: how long you’ll be working on it for
  • Termination: under what circumstances you (or the client) can stop the project
  • Remedy: what happens if things go wrong

There are plenty of other things it would be useful to agree: who owns the intellectual property you produce when the project is over? Under what circumstances can you sub-contract the work? What liability do you have in the case of a consequential loss1?

You won’t always get to use your standard terms: invariably we negotiate to reach a point where everyone’s happy, and some of our terms are removed or modified. The larger the organisation, the more risk-averse they’ll be to taking on someone else’s contract terms. But it’s totally worth a discussion. There isn’t a single organisation we’ve worked with - including large multi-nationals - who haven’t been flexible on the terms when it’s presented reasonably, and with flexibility on both sides.

If you don’t understand something, speak to a lawyer whom you pay for advice. There are points of statute and case law which you can’t possibly know if you’re not a lawyer. They might be expensive, but a claim against you for breaching your contract could be much worse.

Agree payment terms and schedule

Cashflow is the lifeblood of your business, and you should make your payment terms and schedule part of the contract. These fall into 2 parts:

  • The payment terms: how and when you’ll get paid when you present an invoice
  • The payment schedule (or ‘milestones’): when you can invoice for work you’ve done

 Payment Terms

This is quite an easy one: how long can your business survive without the cash you’ve asked for? It’s in the interest of the client for you to give them as much credit as possible, and in your interest to be paid as soon as possible!

Our standard payment terms at Error are “15 days, paid electronically to a nominated account”. That’s a little over 2 weeks for the client to receive an invoice and send us payment, which we think is fair.

Clients might well suggest longer terms - 30 or 60 days is not uncommon. I always baulk at 60 days - 2 whole months of credit! - but sometimes agree 30 days. In the UK, if you don’t stipulate a term, it’s 30 days.

Note the 'electronically’ bit in our standard terms. A few clients have tried to send us cheques to gain time on credit (“it’s in the post”). Very irritating. Plus it’s a massive pain to cash cheques, and costs money too. Insist on an electronic transfer if you can.

 Payment Schedule

Clients might expect to take delivery of everything you produce / deliver before giving you money. We unapologetically disagree with this. For a small business, cashflow is paramount, and if you’re delivering stuff to the client, they should expect to pay as they go.

The process should look like this:

  • Decide on delivery milestones for the project
  • Roughly apportion the effort to each of these milestones
  • As a proportion of the total, decide how much you’ll charge at each point

For example, if you’re doing some workshops, going away to work on something, and then testing it with the client, there are 3 distinct phases to the work.

We always ask for a proportion of the total cost upfront - usually 25%. It shows goodwill on the part of the client, and allows us to bankroll the initial work without worrying about running out of cash.

Similarly, in a show of good faith on our part, we tend to hold back 10% of a project cost until 30 days after delivery, so they client can be satisfied that any kinks and snags are ironed out.

 Understand the client’s purchasing process

When you win a piece of work you get a big buzz and can see the money rolling into your bank account. But what actually needs to happen on the client’s side before you send them an invoice? I always ask, explicitly, “what needs to happen before we invoice?” to find out for sure.

Have you spoken to the decision-maker?

At the risk of sounding like Mr Pessimism, have you really won the work? I always ask “is there anyone else who needs to sign off on this work?”. I’ve been surprised more than once when the response is “our finance director needs to agree it first, but that should be ok”. Hmm. I haven’t really won the work yet, have I?

Do you need to be added to their procurement systems?

A larger client, or one who has very formal processes, will need you to be added as a supplier to their procurement or finance systems (they might refer to an 'ERP’ - Enterprise Resource Planning - system). Invariably that’s just a form to fill in, but you’ll need at least:

  • your company number
  • your company name
  • your VAT (or other tax) number
  • your bank details

You will often have to fill in their form, but sometimes they want the details on 'headed paper’ - a misnomer in these paperless times. I have never had any problem sending a PDF with our logo and company address.

You probably need a purchase order (PO)

For any decently-sized organisation, you’ll need a purchase order before you start work. This is a document (or sometimes just a number) generated by their finance system to confirm that the work has been ordered. Keep a note of this because you’ll need to quote it on your invoice.

OK, can I go ahead and do the work now?

When you have an agreed contract and a PO, you are in a pretty good place to start work.


  1. Our standard terms say 'none’, and I try my hardest to make sure that clause stays in the contract. Having liability for consequential loss is a scary thing: “we’ve lost £x thousand because of your failure to do y” is a nasty conversation to have. 

Billy logo is an app that'll help you put these articles into practice for your business.

Start using Billy

15 days free (no card required), £5 a month

Screen vectors
Logo error

Billy has been made by the nice folk at Error. We create digital products and brands for companies like the BBC, Sony, Bupa and Tate.