Client Fears - Freelancing Digest

This post is an except from my book The Freelancers Guide To Long-Term Contracts. If you want to learn how long-term contracts can stabilize your revenue, simplify your project scheduling, and make your business more enjoyable: make sure you check it out.

One thing you might be asking yourself is, “If I’m just a solo freelancer, why would a client trust me with a long-term contract?”

First let me say, this is probably a fear that only you as the freelancer have. It may or may not be something that the client is actually thinking about. And even if the client is thinking about this, they are probably thinking about it differently than you. The client is more likely to be looking at what their options are if you don’t deliver or deliver a poor project.

What if you don’t deliver?

The first client fear is “what if you don’t deliver a project at all?” This commonly happens if a client has never hired a freelancer before, or if they’ve had a bad experience with a freelancer in the past. Basically, it boils down to trust. The client doesn’t know you enough to trust you and trust your word that you will deliver. Can you blame them? Everyone has met a salesperson who says they can do something and fails to deliver. This is just part of the sales process.

To counter their concern there are three paths you can take:

1. Start small and prove you deliver.

The absolute best way to begin to build trust is to prove that you can deliver. What has worked very well for me is to start with a small, prototype project with a very limited deliverable. Pitch this to them as a way to “test you out and see how the working relationship will be”. That way the client will have a limited risk (small amount of money tied into the project) but they will still get part of the end result they need. These are what I call the “foot-in-the-door” projects and almost every one of my long-term projects have started out this way.

2. Referral and reputation.

There are other ways you can increase their trust in you but depending on how far along in the negotiation you are, they may or may not be effective. Having you referred to the client by someone they trust is a huge confidence boost. Testimonials from past clients can also help your client to feel they have a fuller sense of how you do business.

Building reputation takes time, but being prolific in whatever industry you’re in can also help ally your client’s fears (e.g. the Ruby and Rails community for me, an iOS forum for an iOS developer). Your reputation can and does precede you when you are part of an active community.

3. Be transparent.

In addition to trying to increase their trust in you, there is another method that I’ve had great success with against the fear of non-delivery. What I’ll do is describe upfront all of the different ways that I will act so they can see that I work transparently. Basically you want them to feel like you could disappear one day and they would have access to everything you’ve been working on up to that point. For developers, that means giving the client access to the source code on a daily basis, taking notes on what is done or not done, and keeping an updated bug list. For designers, that might mean publishing your source PSDs to a shared directory like Dropbox, exporting clean formats every day, and keeping copies of different concepts you’re working on. Yes, there is a risk of the client bailing on you and taking all of this with them to a new freelancer but that is a risk you just might have to take to win this client over.

What if you deliver a poor project?

The more common fear clients have is that the end project you deliver will be poor or not meet their standards. The common “9 out of 10 software projects fail” faux-statistic comes to mind when I hear this. You can overcome this objection by educating a client ahead of time.

It is true that sometimes you will unintentionally deliver a poor quality project because of a rushed schedule or a miscommunication. What is more important is how you correct that mistake, and how you communicate this to your client up-front. If they raise this objection, say “I’m glad you brought that up. While I try to produce the best [design, software, etc] as possible, sometimes there are changes that need to be made after the final product. I’d like to go through the process I use to correct those mistakes now, if that’s okay with you?” At which point, they’d agree and you’d outline something like the following:

For projects that can be delivered incrementally, like web software – “Once this project has started, I’ll be delivering versions of it to you with parts of the functionality complete. I don’t expect you to review every part but when you do get a chance to review the partial version, we can discuss any inconsistencies or changes that you’d like to make. Depending on the extent of the changes, we might have to adjust the project a bit but the important thing is that we both agree to remain open to changes because many times the changes are an improvement neither of us could see at the beginning.” This approach is very similar to how agile software development works, where the client can adjust the scope of the project as it goes. It will take practice delivering this message and following through with it, but it has made several of my projects quite successful.
For projects that cannot be delivered incrementally, like a logo design – “Once this project has started, I’ll create an initial version of the [logo] and present a working copy to you. Then based on your feedback I’ll tweak the [logo], adding in the rest of the requirements, until I have the [final design] complete. Now, this final design isn’t the last design I’ll do for you, it merely means it’s the starting point for some detailed revisions. At this point I’ll give you the opportunity to review the [logo] and make any changes you’d like. I’d make these changes and give you a new revision of the [logo], where you can then review it again. We can continue this revision process 3 times or until you are completely satisfied with the [logo]. The main thing is that we have a collaborative back-and-forth discussion about the [logo] as quickly as possible.” You can see that this approach is similar to #1 but the client’s feedback isn’t asked for or incorporated as early in the project. While it might not sound ideal, it might diffuse the client’s objection enough to move the project forward.

How can I trust you?

Trust is the underlying emotion behind most business agreements. Without trust each side doesn’t believe what the other is saying.
Your client might not feel like you can deliver over a long period of time. This is especially common when you’ve only know each other for a short time but it can also arise when your only projects together have been short (under a few weeks of development). One specific way to counter this is to propose some medium length contracts or a short retainer. For example, if the longest project you’ve done with them has been 3 weeks and they balk at a 12-month contract, propose a 6-month or even a 4-month contract. Trust takes time to build and a shorter commitment lowers the risk until trust is in place.

What if you disappear on me?

The freelancer who disappears is sadly a common story I’ve heard about from clients and fellow freelancers alike. Even if you or I would never disappear without warning, the fact that a few people have leaves clients fearful of it happening to them.

Reassurance and risk-limiting are the best ways to counter this and help the client feel more comfortable. By reassuring the client that you are reliable and that you won’t disappear on them, you might help address their fears. Asking a previous client to speak on your behalf, especially if they were a long-term client, could help convince your current client that you’ll be sticking around.

Risk-limiting involves adding processes and checks into how the contract is run so that even if you do disappear, the client still gets some value from the contract. This involves giving the client intermediate deliverables and backup copies of the source material you’re using. Any steps that prevent the client from feeling like all their eggs are in one basket can help alleviate this concern.

What if something happens to my business (or your business) that stops the contract?

A valid concern, for startups and large enterprises alike, is “What if my business changes drastically and makes the contract not useful?” This can happen if a startup decides to pivot and your project or specified services are no longer needed as part of their new direction, or if a sweeping change is made across the organization and your client has no control over it.

The best way to respond to this concern is to make the specific deliverables in your contract valuable. Instead of listing the exact deliverables your client is asking for like “Consultant will deliver X, Y, and Z” phrase it like “Consultant will deliver their services to the Client based on the decisions and requirements of the Client, including but not limited to X, Y, and Z”. With this style of phrasing, you and your client have the flexibility to add or remove deliverables from the contract without renegotiating the contract. If their business does change, both of you can decide how the changes can impact the contract without cancelling it out-right.