Consultants Should Always Negotiate Acceptance Clauses
Acceptance clauses can easily trip up new consultants. Learn what they are and how you can have the right provisions in place before taking on any new client.
Welcome to my new newsletter. If you want to build a thriving consultancy practice in your niche, I want to help. Please subscribe to my newsletter and check out my other articles. If you enjoy today’s article, then feel free to share it.
Why You Should Never Just Sign The Contract
In the early days, I would be so happy I had won a client that I’d sign pretty much any contract they would put in front of me.
Yippee!! New client!
These days I take a fine tooth comb through any contract we don’t write and challenge/request changes on anything which sounds iffy.
The thing to remember about any contract provided by a client is it was written by a legal person to protect them. I’m not talking about your contact at the organisation who you are getting along with great. I’m talking about anonymous procurement and legal professionals you will never meet.
They’ve made predictions about the issues most likely to arise and created provisions to protect the organisation if those issues do arise.
There are plenty of examples, but one of the most common is what’s known as an acceptance clause.
What The Heck Is An Acceptance Clause?
An acceptance clause is essentially a provision in a contract which defines whether a buyer of your deliverables has accepted them.
You might be thinking, why do I need to worry about acceptance clauses?
I just do the work they ask for and then they have to pay for it.
It’s best to illustrate the problem with this mindset via an example.
The Problem with ‘Deliverables’
Let’s imagine you hired a designer to create a logo.
You have a contract which stipulates the contract ends when the designer delivers the logo to agreed specifications.
What will you do if the designer creates a terrible logo which looks like they spend less than 30 minutes on it? It might still be in the format, colour scheme, and style you agreed on - but it’s just terrible. There’s a huge difference between specifications and quality.
If your contract simply has the designer on the hook for completion of the ‘deliverable’ they can claim the project is complete and you need to pay them.
You won’t work with them again, but you still have to pay.
The Problem With ‘Acceptance of The Deliverables’
To prevent situations like this from happening, most client-side contracts will use language like ‘acceptance of the deliverables’.
This essentially means the client has to approve that the work has been done to the agreed standard before the designer is paid.
Now let’s imagine you are that designer.
What happens if you create a logo to the agreed specification and the client complaints it’s not good enough and makes endless requests for tweaks?
The project can soon become unprofitable.
To prevent situations like this, most supplier-side contracts will stipulate the number of round of revisions an organisation may request (typically two).
This means once the logo has been shipped, the client may give one exhaustive round of feedback. Once the logo has been revised by this feedback, the client may give another single round of feedback. Once this feedback has been incorporated again the project is done.
There are two general rules to feedback.
Feedback must not contract the specifications or past feedback. If the revision would contract the specification, then that’s a client-side error which has cost the designer time and they should be compensated for that.
Each round must be exhaustive. The first round of feedback should be completely exhaustive of every required tweak required. The second round of feedback should only be provided on the tweaks made since the first round. This means feedback should narrow with each round.
In practice, it usually helps to exercise a little flexibility with clients - especially if you want to work with them again. However, it’s important to have a contract to fall back on if things don’t go well.
Agree on The Timeline And Number of Revisions
The final thing to consider is what happens if the client simply ghosts you?
What happens if they never get around to providing feedback so you can complete the project?
What happens if the organisation changes its mind about the logo and your key contact leaves the organisation?
Most contracts have procedures for terminating a contract - but they often overlook termination by stealth. Where the deliverables haven’t been accepted because the client simply didn’t get around to asking for revisions.
Some contracts tackle this by stipulating the client must provide feedback for revisions promptly.
Promptly is clearly a problematic term. In a legal sense, it can be interpreted to mean “as soon as reasonably practicable under the facts and circumstances at the time”.
This creates far too much wiggle room.
“We can’t provide feedback now, we’re in the middle of an economic crisis!” etc…
You can avoid this by simply putting a time frame in place. Within two weeks is generally a good timeline to work to. You ship the deliverables, and they have two weeks to provide feedback or it’s considered acceptable.
Balance is Key
This is you need to have a healthy relationship with a client before a project begins to openly discuss this. Recognise you each have your own concerns and you need to find a healthy midway point between them.
Clearly, simply creating a deliverable isn’t enough. It doesn’t protect the client at all.
Yet, acceptance of deliverables doesn’t protect the supplier.
A fairer balance is to specify the number of revisions the client can make and the time frame they must be given.
This probably protects the supplier slightly more than the client (even with two rounds of feedback the work could theoretically be poor quality). Yet you have to assume the buyer has undertaken due diligence before signing the contract with a supplier.
Be Specific About What You Deliver
Acceptance clauses are even more important for consultants than designers. If you’re selling your expertise, at what point does a client accept it?
You don’t want to send awkward emails like:
Do you accept my words of wisdom from last month?
This is why you need to be very clear about what your deliverables are and the process by which they will be accepted.
Some consultants tackle this challenge by selling their time at an hourly rate. At the end of the month, the client essentially needs to accept that the timesheet is valid.
Others work on a monthly retainer. This is trickier but acceptance is usually presumed if the contract hasn’t been terminated.
Others turn their expertise into specific items (strategies, presentations, budget sheets, resources, training workshops etc…). These things are more tangible. People can see them and send them around the organisation.
But often it’s still not very clear what these things are. If I say I’m going to create a strategy for an organisation, what does that mean?
Is a strategy a 10-slide overview presentation which will be presented to the entire organisation or a 200-page document reasoned document? Or both?
These things mean different things to different people. Hence why you need to agree on the medium, format, and structure of the deliverables you’re creating for clients.
Protect Yourself At All Times
There are plenty of things to look out for in a contract. We’ll cover more of them later.
For now, one of the best things to consider is what precisely your deliverables are.
How will a client know when they have received them?
And what is the process by which they can be rejected?