How to Communicate with Your Client

Share this post


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.


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.

CTA Website Security Checklist

Related Posts

The Dilemma of Estimates

The Dilemma of Estimates

Estimates serve as the cornerstone of any website project, providing clients with a roadmap for budgeting, planning, and expectation management. They offer a glimpse into the intricate tapestry of tasks, timelines, and resources needed to bring a website to life.

Config Sync Overview

Config Sync Overview

When Drupal 8 was released, it came with Configuration Syncing functionality. This has been a staple ever since for Drupal 9, Drupal 10, and beyond. Configuration Syncing was a game changer and one of my favorite features in Drupal Core.The days before config sync...