The client call that opens with "where are we?" isn't nagging. It is a signal of an information gap you left open.
A client who knows where their project stands doesn't call to ask. One who doesn't will call — and will call again a week later, and with each call a little trust erodes without a single technical error having occurred.
Why Projects Stall at Stage Boundaries
Most delay in engineering offices doesn't happen during the work — it happens between stages: a stage finished and waiting on client approval, or waiting on information from them, or passed to another department without anyone knowing it arrived.
These gaps show up in no report, because everyone is "busy". The design genuinely finished, the next department hasn't started, and the days in between are charged to the project — and then to you.
Stage Handover: A Recorded Event, Not a Message
Work moving from one stage to the next — or from one department to another — should be a recorded event, not a message in a group chat.
A documented handover carries four elements:
- What was handed over, as counted deliverables rather than a general description
- Who handed over and who received, by name
- The handover date, which sets when the receiver's responsibility begins
- Receipt status: accepted, or rejected with a written reason
The last element is the most valuable. A rejection recorded with its reason prevents the same problem recurring — while a verbal rejection is forgotten and returns on the next project.
Client Approvals: The Longest Wait on a Project
Many offices treat client approval delays as beyond their control. They are partly right — but the part that goes undocumented turns against them.
When a client takes a month to approve the concept design and it isn't recorded, that month is later counted against the office in the delay calculation. When the issue date and the approval date are both recorded, the gap is proven — and becomes a legitimate basis for a time extension.
Recording it isn't an adversarial stance toward the client. It is simply a record of what happened, and it serves both parties when they disagree.
What Should the Client See for Themselves?
Not everything. A client doesn't need to see your internal team discussions or your drafts.
But they do need — and are entitled — to see four things without calling anyone:
| What the client sees | The call it prevents |
|---|---|
| Project stages and their status | "Where are we?" |
| Approved documents issued to them | "Where is the latest drawing?" |
| What is awaiting their approval | "Is anything needed from me?" |
| Invoices, certificates, and payment status | "How much do I owe?" |
Note that three of the four serve you before they serve them: a client who can plainly see what awaits their approval, and what they owe, delays less.
Transparency Speeds Up Collection
This counter-intuitive result is noticed by every office that opens a portal to its clients: presenting certificates and invoices clearly shortens the collection cycle.
The reason is that much late payment isn't stalling — it is an unanswered question: what is this amount exactly? Against which stage? Was the advance deducted? When those answers sit on the same screen, the objection dissolves before it is formed.
What Changes When Handovers Live Inside a System
Inside an engineering consultancy management system, five things change:
- Every handover between stages and departments is recorded with sender, receiver, and date
- Rejections are recorded with their reason, so the same problem doesn't repeat next project
- What awaits client approval is visible with its issue date — your evidence in any delay calculation
- The client sees their stages, documents, and invoices without calling
- Projects stalled at a stage boundary appear in one list instead of being forgotten
Frequently Asked Questions
What is a stage handover record?
A record documenting the movement of work from one stage to the next, or from one department to another, carrying the deliverables handed over, who handed over and who received, the date, and the receipt status: accepted, or rejected with a written reason.
How do I document client approval delays?
By recording the date a deliverable was issued for approval and the date approval was received. The gap between them is self-evidencing, and becomes a legitimate basis for a time extension or for discussing the delay's effect on fees.
What should a client see in the portal?
Their project stages and status, the approved documents issued to them, what awaits their approval, and their invoices, certificates, and payment status. Drafts and internal discussions should not be exposed — showing them creates more questions than they answer.
Does a client portal increase questions or reduce them?
It reduces them in practice, provided it stays current. An outdated portal is worse than none, because it costs the client's trust in everything it shows. And keeping it current shouldn't be an extra task — it should be an automatic by-product of the team's daily work.
How do I know where a project stalled?
By comparing the date of the last recorded handover against today's date for each project. Projects sitting a long time at a stage boundary with no movement are the first to review — and they are usually waiting on a decision from a single party.
Doesn't documentation slow the work down?
Documentation done as a separate step does. But when the handover itself is what gets recorded — one action at the point of transfer — it adds no time, and saves far more at the first discussion about who delayed what and why.
Conclusion
An office is judged by its client not on drawing quality alone, but on whether the client feels they know what is going on. That feeling is built by available information, not by reassuring phone calls.
Ask yourself: if your client logged in right now to look at their project, would they find a clear, current picture — or would they pick up the phone?
Read next: Running an Engineering Consultancy — The Complete Guide From Proposal to Handover.