Most unhappy clients in a project never complain to the company that upset them. How project teams surface a complaint early, before it lands on a public review page.
Most unhappy clients in a project business never complain to the company that upset them. They complain to a partner, a colleague, a neighbour on the same development, and eventually to a review page. The company reads its inbox, sees nothing alarming, and concludes the project is going well.
That is the argument at the centre of Hug Your Haters, Jay Baer's book on complaint handling. A complaint is not the failure. It is the one case where a client tells you what went wrong instead of telling everyone else.
In construction and property development the gap is wider than in most sectors, because the client has been trained not to ask. Delays get explained as normal. Questions get answered late often enough that people stop asking them. By the time a buyer or a client raises something formally, they have usually rehearsed it for weeks.
So the useful question for a project team is not how fast it answers complaints. It is how many complaints it never receives at all. A team that answers every email within the hour can still be flying blind, because the clients who gave up stopped writing months ago and the ones who are still writing are the patient ones.
An offstage complaint reaches you directly and privately: an email, a phone call, a remark in a site meeting, an answer on a satisfaction form. An onstage complaint is published where other people read it: a Google review, a Facebook comment, a post in a local buyers' group. Baer's point is that companies answer the first kind and ignore the second, which is exactly the wrong way round.
The two behave differently on every axis that matters to a project business.
| Offstage complaint | Onstage complaint | |
|---|---|---|
| Where it lands | Inbox, phone, meeting, form | Review site, social post, buyers' group |
| Who reads it | You and the client | Every prospect researching you |
| What the client wants | A solution | To be heard, in public |
| Cost of no reply | One relationship | Every deal that starts with a search |
| Shelf life | Ends when the issue ends | Stays online for years |
A frustrated client on a twenty-month development does not walk away. They wait. The contract holds them in place, the money is already committed, and the irritation compounds quietly through every phase where nobody asked them anything.
That is why the complaint, when it finally arrives, rarely matches the incident that triggered it.
A prospect comparing three developers reads the negative reviews first, and then reads what the company said back. That reply is the only place where a stranger sees how a project team behaves when something goes wrong.
A defensive reply confirms the reviewer's story. A legal-sounding reply reads as a company protecting itself. A short, specific reply that names what happened and what changed does more for a prospect than a page of five-star ratings, because it answers the question they are actually asking: if this goes sideways on my project, will these people show up?
The same logic runs through the way a team communicates before anything goes wrong. Trust in a construction project is built in the quiet months, and it is lost there too: we wrote about what happens to homebuyer trust in the silence after the signature.
A project team catches complaints early by asking narrow questions at fixed moments, not by waiting for the inbox. “What is frustrating you most right now” gets an honest answer. “How are things going” gets a polite one.
Three habits do most of the work. Ask at the end of each phase rather than at handover, when the answer can still change something. Give every complaint an acknowledgement inside a working day, even when the resolution takes a fortnight. And keep the reply in the same place as the project record, so the next person to open the file can see what was promised.
That is the part a client portal is built for. In Ziggu, forms collect satisfaction and NPS answers at the milestones you choose, so a phase closes with a written answer instead of an assumption. Conversations keeps client, team and partner messages in one project inbox, so a complaint raised on a Friday afternoon is not sitting in one person's mailbox on Monday. Reports handles snagging and aftercare: points get logged with photos, an owner and a deadline, and the client validates what is theirs, which turns the most complaint-heavy phase of a project into a list both sides can see.
None of that removes complaints, and no system should promise to. It moves them from the review page to a channel where they are still fixable, early enough that the answer is a decision rather than an apology. That is the whole point of hugging your haters.
