By Dave Hecker

Managing Client Expectations: User Acceptance Documentation

By Dave Hecker

A common question on Sitepoint’s Business & Legal forum is, “I’ve delivered what I promised but my client keeps asking for small tweaks, support, and advice. How do I determine when a project is over, and how do I communicate this to my client?

Most web developers have experienced the ‘never-ending project’ and can sympathize with a developer in that predicament. It’s not easy to balance great service with the need to put some boundaries and limits on what you are willing to do for your client, and it’s especially tough when you are just starting out and you need to have 100% client retention!

The good news is that there’s an easy and simple way to prevent this problem: the User Acceptance document.

User Acceptance is just what it sounds like – an acknowledgement from your client that you’ve fulfilled your part of the deal (as set out in the original contract) and the project can end. User Acceptance is commonplace in the software industry and usually consists of a User Acceptance (UA) document which the client signs and returns once the work has been completed
to their satisfaction. In addition to putting some legal structure and accountability around the completion of the project, the UA document also serves as a crystal clear message to the client that you’ve come through on your end of the deal. It also makes the client explicitly accept the work, which will make them think twice about asking for ongoing free changes. The UA document also serves as a clear starting point for a warranty period or the beginning of a next phase.

An effective UA document can be just one page long, and have a single paragraph containing language like,

‘The undersigned agrees that ABC WebDev, Inc. has fulfilled the requirements
set forth in the agreement signed on Jan 1, 2006 and that the project is complete.”

You can expand the UA document to explain the billable rate (or other terms) for ongoing work or the length of the warranty period, which would ideally begin when the UA document is signed. Any other points that you want to make clear should also be included in the UA document.

For a UA document to be effective, the following elements must be taken into consideration:

  • The client needs to understand what the UA document means. The UA concept should be introduced in your original contract, and the client should know how it fits into the overall project flow. Make it clear that when you’ve completed the work, you’ll send the UA document for them to sign.
  • There has to be some motivation for the client to sign the document, and some clarity about what happens if they don’t. A good way to address this is to add language to the original contract and the UA document which dictates fair terms for the end of the project, such as:

    1. Starting on the day the client receives the UA document, they have 30 days to report any functionality gaps or other deficiencies in the delivered product (things that you promised to do but did not). Make it clear that you will fix any such deficiencies as quickly as possible, free of charge.

    2. The warranty period of xxx days will begin once the UA document is signed. Bugs (but not substantial changes that deviate from the original agreement!) will be fixed for free during this time.

    3. If the UA document isn’t signed within 30 days, the contract will automatically end and the warranty will be terminated. Any enhancements, bugs, or changes found after the project termination or beyond the warranty period will incur a new bill.

Using the above simple terms, the average client will want to sign the document to ensure that they don’t void their warranty period. You benefit by having a clearly signed UA document because you don’t have to worry about never-ending change requests – if the client asks for changes following UA, they’ll understand that they will be charged.

Obviously, each developer will need to customize the UA concept to fit their individual project’s needs. In some cases, a developer may not deliver a finished website until the UA document is signed. In other situations, the signed UA document must be accompanied by a full payment. Regardless of how you apply the UA concept, you’ll do both yourself and your client a big favor by having formal, signed documentation at the end of the project instead of just at the beginning!

  • EXcellent! This is just the kind of advice we need!! We have been having problems lately with a never ending warranty period and we need to build UA into our process.

  • ASJ

    Good Post. Welcome to SitePoint(this is the first of your blogs I’ve gotten to read). I look forward to more valuable posts like this! Keep them coming!

    Happy Holidays!

  • cbtrussell

    Our contract stipulates that the project will not be released/published until the UA document is signed. For customers anxious to go live, it’s an excellent motivator :)

  • Good tip, should supplement a contract well. I’ll have to remember to write one at some stage….

  • I had the issue of the never ending project about four years ago. I have since added such stipulation in the project contract, which I get signed before any work begins. Though I have not had any “difficult” clients since, I would recommend this approach to everyone. Great Tip!

  • This looks like one of those no-brainers… not sure what that means since most of us, self included, probably haven’t instigated such a document. Would certainly help with any of those gray areas.

    Now, if we can just figure out how to move along the “never-ending-work-in-progress” projects. You know, the ones where the back-half of the billing comes at completion, but getting content, mid-process agreement, etc. seems to be taking much, much longer than planned!

  • It’s hard to avoid that, but there are certainly things you can to do a) get paid for your inconvenience and b) motivate your client to keep up

  • Johnwalu

    Very useful concept: User Acceptance.

Get the latest in Entrepreneur, once a week, for free.