When your contract includes deliverables, make sure it also explains any limits on or requirements for the customer's acceptance.
Most contracts use the term deliverable to define anything created from the services the customer purchases in the contract. So if a customer hires a vendor to write a software program or prepare a graphic design, the vendor's output is the deliverable.
When I represent vendors providing deliverables, we prefer minimal acceptance criteria, if any.
The argument is that the customer is buying the vendor's time, not a product, and is bound to take what was created with that time. With detailed criteria, the vendor may have to reperform the services (losing money in the process) or face cancellation and nonpayment for all that time spent.
When I represent customers, we focus on making sure that we receive something usable.
If the vendor spends 100 hours creating something that doesn't work, we don't want to have to pay for that. Vendors argue that we are buying the vendor's time, but as customers, we think of it as buying the deliverable created during that time.
It is important to be clear on these points in the contract. That way, the vendor and customer can evaluate whether to proceed with the deal with that risk in mind.
Here are some common deliverable acceptance criteria, ranked from pro-customer to pro-vendor.
- Buyer will accept the Deliverables if approved by Buyer in its sole discretion.
- Buyer will accept the Deliverables if they conform to the Specifications.
- Buyer will accept the Deliverables if they conform to the acceptance criteria in the Specifications.
- Buyer will accept the Deliverables unless Buyer provides objective proof that the Deliverables do not conform in all material ways to the acceptance criteria in the Specifications.
What other things do you include in your contract to address the deliverables
