Why generic project tools fail client-facing work
General project tools assume everyone is on the same team. Agencies manage clients. Where the gaps bite, and what to look for instead.
· 4 min read · Agency operations
The tool is not the problem, at least not at first. You chose a perfectly good project platform, built the boards, invited the team, and internally it works. Tasks move and sprints close. Then you invited a client into it, and something started to creak.
This is not a takedown of any particular product. The well-known tools are competent at what they were designed for. The trouble is what they were designed for.
Built for teams managing their own work
A general project tool rests on a quiet assumption: everyone in the workspace is on the same side. They share a backlog and they share incentives, and a missed date is a planning input rather than a broken promise. On those terms the category is genuinely good.
An agency violates the assumption on day one. You are not managing your own work, you are managing other people's expectations. Half the people who care about your board did not choose the software and will not attend a training session, yet they are paying for the privilege of being confused by it. The tool treats your client as a colleague with fewer permissions, and a client is not that. A client is a customer holding you to a promise, looking for evidence that you will keep it.
Client access is bolted on, and clients decline the bolt
Watch what happens when you try to bring a client in. There is usually a guest seat, priced and permissioned as an afterthought. There is a permissions matrix you read twice and still do not fully trust. And there is the moment you hover over the invite, wondering exactly which boards and comments this person is about to see.
That hesitation is the tell. Most general tools put all your clients' projects in one big workspace, with visibility controlled by settings rather than structure. There is no hard wall between client A and client B, only configuration, which means every share is safe only if nobody ever misconfigures anything, forever. One mislabelled board and a client is reading another client's budget, or your internal notes on their feedback. You will probably get it right every time. "Probably" is doing a lot of work in that sentence, and it is why plenty of agencies quietly stop inviting clients at all.
Suppose the permissions are perfect, though. There is a simpler failure waiting: the client does not log in. They bought outcomes, not software. Asking them to learn a project tool, however friendly, is asking them to do unpaid admin for your benefit, and they respond the way you would. They reply to the email thread instead. At that point the tool stops being the system of record and becomes a hand-maintained mirror of one, while the real decisions happen in an inbox and a WhatsApp thread. Any system a client refuses to use is a system you do not have. The fuller argument for a client-facing layer that clients will actually open is in client portal for agencies.
No concept of sign-off, no concept of a promise
Two more gaps, and for client work they are the fatal ones.
First, approval. Client work runs on sign-off. A general tool has "done", and done is not approved. A ticked checkbox does not record who agreed to which version, or when, which is exactly what you need eleven weeks later when someone asks why the printed brochure carries the old logo. This is why purpose-built review workflows pin feedback to the artwork itself and record decisions from named approvers with timestamps. A comment reading "looks good!" from someone who may or may not have had authority is not a paper trail.
Second, dates. In a team tool a date is an internal deadline, and internal deadlines slide quietly, because the only people who notice are in the same standup. In client work a date is a promise made to someone who is paying, and a promise that moves without notice is how trust erodes, one small surprise at a time. The date needs to live where the client can see it, and when it moves the client should see the new date and the reason before they have to ask. That distinction gets a full post of its own in landing dates, not deadlines.
What to look for instead
If you are evaluating agency project management software, judge candidates on the client-facing surface rather than the internal one. Internal features are table stakes across the category; the differences that matter sit where the client touches the work.
- Per-client isolation that is structural and enforced by the server, not a permissions setting you maintain by hand
- A client view so plain that nobody needs onboarding: their requests and their dates, nothing more
- Client users who are free and unlimited, so the pricing model never punishes you for giving a client team access
- Sign-off as a first-class object, with named approvers and timestamped decisions
- Dates that behave like public promises, carrying a visible reason when they move
- A route for requests that arrive by email to land in the system anyway
None of this is exotic. It is simply a different job from the one general tools were built to do.
Where HoopoeHQ sits
HoopoeHQ is our answer to that list, built inside a working agency after clients refused to log into a heavyweight ticket tool. One strictly isolated workspace per client, landing dates the client can see, reviews with named approvers, and client users free and unlimited on every plan. If the list above matches yours, start the 14-day trial and test it against the real thing; it needs no card.