Over the last two months, I’ve discussed how to keep track of the money you make with your web design or development business. There is some work to be done before the first payment from a client rolls in. It’s called the contract.
It defines what the project is, what you will be paid and governs disputes. It’s the silent partner that supports your endeavors.
Draft a Good Contract
If you have a contract drafted by an attorney, I’m very proud of you. You are ahead of the game. If you contract is less than a page long or – gasp! – you don’t use one: now is the time.
This is the portion of a contract that will change from client to client and from project to project. It needs to be specific. What is included? Will you do six revisions or two? Will you purchase stock art for this price point or not? Is your client limited to a certain cost for stock art pieces? This about what you won’t do as much as what you will.
What You Need
You know what you need from a client in order to get the work done. It is your responsibility to require it.
Do you need art from the client? Logos? A client’s responsibilities should be clearly delineated. Clients that want a website often have absolutely no clue about the amount of work that will be required of them. It never occurs to them that you do not live in their head and cannot magically extract all the information you need to produce a fabulous website or design.
If they are to provide content, say it. If they will input their own products into the shopping cart, say it in the contract. How should they provide direction and respond to your inquiries? How long do they have to respond before they lose their spot in the schedule? State it in the contract!
For example, the contract I have for my husband’s business specifically requires all direction to be given in writing. It also allows that if verbal direction is given and he makes such changes he is not responsible for the result. The reason for this is simple. When clients give instruction verbally, there is nothing to which he can refer back. You set yourself up for a we-said/they-said situation. Some clients refuse to use email, for some reason, and only want to talk on the phone – they must accept responsibility for the resulting work. I know you are thinking sometimes you have to talk, writing won’t cut it. In that case, the client reduces their instructions to an email after the conversation. You may find that what they said is not what they meant, or there is some aspect that was overlooked.
We also like to define whom we take direction from in the contract; this eliminates the problem of too many cooks in the kitchen. We have one point of contact. If that person sends an email, we do what is asked. If anyone else sends an email with instructions, we forward it to our point of contact for approval.
Review of Work
How will you provide the work to be reviewed? If you have a development domain to which your client will have access, put that in the contract. If you prefer to provide PDFs of designs for review, then state that. There is nothing more frustrating than sending a client a document to look at and them responding with, “I thought I’d see live versions to play with.” (Yes, of course, we code several different versions because we like to waste time.)
Believe it or not, this is often the biggest sticking point. If you’ve been designing or developing sites a while, you know this. Clients never think sites are complete and designers think all the stuff at the end is maintenance or content work. It is best to determine in the contract when the work is complete, and, therefore, when the final payment is due. For us, this is substantial completion: “The project is ready for upload to the client’s host”. It does not mean that we won’t do anything else; there are always tweaks and minor fixes.It just means that the work is complete by the standard in the contract.
If your web design or development firm has any longevity at all, at some point there will be a dispute over a contract. Often it will have nothing to do with any failure on your part; it’s just a fact of life. Deciding how and, more importantly, where they will be resolved is an important part of your contract. This is known as a jurisdiction clause.
It is important for you to address when you can stop work for non-payment, especially in a contract where monthly work is required rather than project-based work.. Projects have discrete payment milestones (we’ll talk about that later) that must be paid before work continues. For clients for whom you are providing monthly maintenance services, when do you stop work for non-payment?
You might know in your head when that is, but you need to let your client know as well. Will you refuse to continue work if they have a bill over 60 days old? Or is it 30 days? This clause also gives you an opening for bringing up non-payment with a client by making the contract the “bad guy.” For example, the contract says if you don’t pay by x, I have to stop work. It’s not me, it’s the contract.
How do you know when something is approved? This goes along with what I said before about getting direction in writing. However, we have found through painful experience that sometimes ‘approval’ doesn’t always mean ‘approval’.
It has happened on multiple occasions that clients have said “yes that’s it, let’s build it!” and, halfway or all the way through coding, they decide they want major design changes. Because it was not adequately addressed in the contract, we had to undertake the redesign and recoding without adequate payment.
To circumvent this problem, we require clients to sign a short document that gives design approval and acknowledges that if design changes are made after this point, hourly fees to revise the design may be incurred at our discretion. This keeps clients from jumping the gun.
The date of the contract does not have to be the date you start work, but if you will start at some point in the future, better have it in the contract. I like to give my husband a week to get started, though usually he gets started sooner. Sometimes a bunch of work comes in all at once and having a little leeway makes the difference between six hours of sleep and two.
So, hopefully you have a good contract from which to work. Now it’s time to create a boilerplate contract. Boilerplates make it quick to go from sale to contract to payment. It’s not a big deal, I’m sure you use an old contract to create a new one all the time, but there is a bit of a method to it. It keeps you from leaving old names and old information in a new contract.
- Refer to the client the same way throughout the document and avoid using names except at the beginning (first paragraph) and end of the document (signature block). We refer to the client as “Client” throughout our contract. You could use Customer or Owner.
- Keep all the changeable paragraphs together. For us that means the description of the project and payment paragraphs are together not spread out all over the contract.
- Save a copy of work descriptions that you use over and over to cut and paste into your boilerplate or create multiple boilerplates, if you seem to be creating the same contract repeatedly.
Know thy Client
Before sending over a contract for signature, be sure you know who the client actually is. You may have been speaking with Susie Smith and she wants to sell her Toe-Cozies, but she might have a company that should be the client in the contract. A little side note: if you are a little unsure about whether they are actually a company or if they’ve really filed all their documents (startups are like that sometimes), try to make the company AND the owner as an individual as the client collectively. Should you need to sue for non-payment, you can go after the owner individually as well.
In addition to knowing whom your client is, you should also know who has the authority to bind that client. For individuals, that is obvious. For companies, it’s usually the officers of the corporation, but some companies have other authorized personnel. Make sure they have the authority to enter into the contract and make sure their title is listed under their signature, next to the printed name of the individual.
Finally, make sure you know where your project emails go and where your billing emails go. Often they are not the same person. If you send your billing emails to your project contact, then they have to send it on to Accounts Payable or whatever. You are relying upon their good graces to forward it, and if they forget to do so, you are delaying your own payment.
A Word About Billing
For project billing (those where you have set your price by the project and not by the hour), I recommend dividing the cost by thirds at the very least. My husband used to do half at the beginning and half at the end. The problem with this is that some clients would drag their sites on forever. We would extend the term of the contract because he wanted to complete the project and get paid, but some simple sites when on almost a year! Now a third is due upon signing the contract, a third is due when the design is approved (see above) and the final third is due upon substantial completion but before anything is uploaded to the client’s host. Not only does he receive more money before the project is over, the invoices are less daunting to the client and they tend to be more forthcoming with finishing the work. You could even divide it into fourths or put clients on monthly payments (debit their credit cards automatically please!).
For monthly billing, the more descriptive you are, the more quickly you will be paid and the more work you are likely to get. I know this seems like a lot of work, but if you use a timer that integrates with your accounting system, all you have to do is describe what you just did right before you stop the timer. It takes a few seconds. That description can then be transferred over to the invoice. Easy!
If you are not accepting electronic payments like PayPal or credit cards in some other manner, you are losing business. I know that services like merchant accounts or PayPal take a percentage of your hard-earned money. However, you are more likely to be paid quickly if you accept credit cards, and you are likely to get more clients. The benefit definitely outweighs the cost. And once you start accepting credit cards, raise your rates a bit in the following year.
Getting the Contract Signed
Electronic document management is a real boon to the contract process. Although this isn’t required, it does speed up things up considerably. The less time you spend on administrative work, the more time you have for work that pays!
I like Echosign, but there are a lot of providers out there. You can do up to five contracts for free per month with Echosign (10 if you let them tweet for you when a contract is complete – and who doesn’t like to let everyone know they just go more business?). Not only is it fast, it stores the contract as a permanent record for both you and your client. Plus, it works just fine in the event of a chargeback or legal dispute. You can even create a document library so that your boilerplates (with client info left blank, please) can be quickly sent off for signature.
If you combine the tips in this article with the habits in my last article, you will find that your sales cycle is shorter, you are paid faster and your projects are completed a bit quicker so you can move on to the next one!
User Interface Design with Sketch 4
Diving into ES2015
Rails: Novice to Ninja
Designing UX: Forms
Bootstrap: A SitePoint Anthology #1
Bootstrap: A SitePoint Anthology #1
- 1 How & Why to Use the Kanban Methodology for Software Development
- 2 The Beginner’s Guide to Creating Effective Business Reports
- 3 What Entrepreneurs Can Learn from Blizzard Entertainment
- 5 Build a Powerful Freelance Portfolio Website that Gets Results