3 min read

How to Communicate with Your Client

How to Communicate with Your Client

 

I've learned to be careful when I ask a question to my developers. For instance, if I ask someone if a widget has been added to a site and the response is, 'Yes, it's all done,' I shouldn't assume that done means DONE. It might very well mean that it has been set up in the sandbox, so the widget is there; but there's a lot more to do before it can be deployed. This means that I can't go back to the client and report that the task has been completed, because they won't be very pleased when the widget is nowhere to be found. Specificity matters.

Client-speak and developer-speakClient developer communication

There are always nuances in how we communicate with each other, and the gulf between client-speak and engineer-speak can be vast. It's still English, but it may not mean the same thing to both parties. If a client asks a developer if something can be done, it's very natural to reply, 'Sure, that's easy!' The client may assume that 'easy' means about 30 minutes of work. The developer may only mean that sure, we've done it many times in the past, and should only take about a week.

If someone on our team is asked a question, I want everyone to be comfortable with answering, 'I don't know.' Researching a solution is the safest course to take. It is perfectly acceptable to say, 'I think it works this way, based on my previous experience. Let me check and I'll get back to you.' We can't have anyone stating something as a fact unless it is a fact. We need the client to respond this way as well.

Because dialogue is a two-way-street, it is important that everybody takes the time to listen, and to express feelings clearly. We may have clients who don't say enough to us. Sometimes they don't know the questions to ask, so feedback is limited. A project that isn't meeting their expectations mustn't be allowed to progress and they must be able to voice these concerns. The client can't ever worry about hurting our feelings, or asking too many questions.

Working together

The number of stakeholders on a web development project can affect its progress, so we rely on a single point person to maneuver through the politics of the situation. One person should be in charge of the job from the client's side of things, even if we are working with a lot of team members in planning. Internal debates on features, priorities, and costs are an important part of the process, but are none of our business. What matters is the final decision. Having someone to facilitate the communications, and report progress, is the best working method that we've found.

The client who is all business and no-nonsense doesn't faze me a bit. If they get right to the point, and clearly know what they want, they will almost certainly define their expectations in a direct manner. These clients are going to have smooth running projects which will come in under budget.

Many clients are very interested in having a relationship with us. For them, every meeting begins with a few minutes of social conversation, often warm and humorous, and that's always welcome. It's necessary, though, to know when to move on.

Meetings

It's important to remind everyone that time is money. We're generally working on an hourly fee. When we have a meeting which includes, on our side, a project manager, a technical lead, and a designer and the client is discussing their experience with certain functionalities which have already been reviewed and dismissed, it probably is costing them money. We can't let the meeting go off the rails.

Likewise, we have to let the client finish their thoughts. I've expressly told the team not to interrupt, even if they have something important to add. I've attended meetings in which I know someone was about to make a point when another individual broke in, and the point was lost. Moreover, we don't want any client feeling that we aren't interested in what they have to say. I tell my team, 'Bring a notebook to the meeting, jot down your point, and we'll get to it eventually.'

Diplomacy and respect

We can walk a very fine line in meetings when a client requests something which we genuinely believe would hurt, rather than help, their new website. Diplomacy can be tricky. This is their business, their money, their vision. All we can do is offer guidance on best practices and what, in our experience, would ideally serve their needs. Clients have likely hired us based primarily on our reputation, so we hope that they respect our judgment but, ultimately, it's their decision. It's their brand.

Respect, though, is the key to all good communication. Just as we have to always remember who has hired us, and therefore is paying us, the client must also remember why we were hired. Begin your professional relationship with respect, maintain it throughout the highs and lows of the project, and it will be there at the end. That's the result we all aim for.


Related Posts

1 min read

Ben Bassi Joins the NSBA Leadership Council

Ben Bassi, President of CommonPlaces, Inc. was named to the National Small Business Association (NSBA) Leadership and Technology Councils. NSBA (https://www.nsba.biz/) is the nation’s oldest...
4 min read

CommonPlaces Works with New Futures to Rebuild Company Website

New Futures: Improved Company Website Enhances Site Navigation and Provides Ease of Content Management. October 5, 2021; New Hampshire; Merrimack County – CommonPlaces Interactive is pleased to...
2 min read

Sensatronics Now Able to Update Content with Ease

Salem, NH, November 8, 2006 - CommonPlaces e-Solutions has successfully carried New Hampshire based Sensatronics Environmental Sensing's website into the automated age of the Internet. Sensatronics...

CommonPlaces CEO Attends Inc. 500 Awards Ceremony

CommonPlaces CEO Ben Bassi recently returned from the 2009 Inc. 500 Awards Ceremony, where he met and networked with founders and presidents of other fast-growing companies. CommonPlaces appeared at...