The Difference Between Acceptance and Completion Criteria in a SOW (View of a SaaS Attorney)
As a SaaS attorney, I have been running into this issue a lot recently, so I thought it warranted a blog post. What is the difference between acceptance criteria and completion criteria in a SOW, and why should you care? Well, there are many differences — with significant consequences — and you definitely should care. Let’s go through it.
Acceptance Criteria. While this has many flavors of this concept in SaaS implementations, you usually see it drafted (by the customer) and it says something like “subject to acceptance” or “customer can accept, review and test the deliverables…” (i.e. a subjective measurement). The customer usually says something like, we need to check that what you deliver meets our requirements.(By the way, there are actually two flavors of customer acceptance wording–see chart below)
Completion Criteria. This is a different way of addressing the same issue. It is an objective measurement (i.e. not subject to distortions by prejudices or interpretations) of did you, for example ‘deliver’ the report to the customer or ‘hold’ the training session call. Said another way, this is something you can prove or demonstrate, and is not subject to the interpretation or opinion of the customer of whether it was done or not.
Summary Chart. Take a look at this chart, as I have tried to outline the issues are clearly as possible.
Rookie Mistake. I think it is a rookie mistake to trust the customer who says I just need to check if you did the work, and therefore we need our acceptance wording (well, What about scope creep? What about payment? What about delays in their acceptance? What about if the requirements change? What about you do the work but they just don’t like it? What about someone thought that your sales guy said that the software would cure cancer?). Now having subjective acceptance criteria may work fine for your first few SOWs, but I think you will find that over time too many customers will ‘without justification’ not accept (or delay) acceptance of your work. My suggestion is to negotiate up front for more objective measurements of ‘completion’ (be specific), and then work towards delivering things that you can prove/demonstrate were completed (plus try to get paid in advance, as that always helps).
What are the big guys doing? Well, glad you asked. I consider an IBM SOW I found on the web to be the gold standard, as it is clear, simple and uses ‘objective completion criteria’ instead of very customer favorable ‘acceptance.’ Oh yea, IBM has probably been contracting for complex IT services engagements longer than anyone, so you know (and I know) that they have spent a lot of time thinking this through.
So keep this blog post handy (maybe print it out or give it to your implementation team), and read it before you take your customer’s word for … “we need our acceptance wording as we just need to check that you did the work.”
This post is for informational and educational purposes only, and is not legal advice. You should hire an attorney if you need legal advice, which should be provided only after review of all relevant facts and applicable law.