Quick answer: When a client input is missing, record the exact item, who can provide or approve it, the date you need a response, and which work can continue without it. Ask one clear question through the agreed channel. If the missing item affects scope, quality or a committed date, let the account owner confirm the revised plan before anyone treats a guess as approval.
For: small agencies, consultants and service teams delivering work after a proposal is accepted. This is a practical operating template. The example is hypothetical, and the dates in it are illustrative.
Separate missing information from an approval
A missing photo, an unanswered design choice and a request to add another deliverable are different kinds of blockage. The first may need a file; the second needs a named decision maker; the third may change agreed scope. Put each in the right queue. The proposal-to-kickoff handoff establishes the accepted scope and open questions. The onboarding route decides how answers are collected. This guide starts when delivery is under way and an answer has not arrived.
Keep the client request short enough to answer. “Please send everything for the website” gives no test of completion. “Please send the three approved team photos for the About page through our agreed upload link by Thursday” names the material, version, route and date. If a person must approve a draft, include the exact version and the choices available.
Choose what can move while you wait
| Missing item | Safe next step | Stop or escalate when |
|---|---|---|
| Reference material for one section | Continue unrelated sections; mark that section blocked. | Someone proposes invented facts or an unapproved substitute. |
| Decision on a draft | Prepare the next independent task; retain the version awaiting review. | Later work would assume approval or overwrite review evidence. |
| Access needed for a task | Use the approved access request route and do work that needs no access. | The task cannot be checked without the right permission. |
| New request outside accepted scope | Record it as a proposed change, separate from the agreed task. | Time, cost or deliverable changes need the account owner’s decision. |
“Waiting on client” is useful only with an owner and a next check. Do not make a whole project look blocked when one component can progress. Equally, do not report a milestone complete when it depends on an unreviewed placeholder. The delivery owner owns the work plan; the account owner resolves a commercial or scope question.
Use one input and decision record
Keep a short record beside the project task: item requested; why it is needed; current version or source; client contact or approver; request date and channel; response date requested; internal check owner; work affected; safe work continuing; next update date; outcome. Use requested, received, usable and approved as distinct states when they matter. A file arriving does not mean it is the right file or that it may be used. The client-file route guide helps choose where files should arrive and who reviews them.
If you use a project tool, a dependency can show which task waits on another. Asana’s official dependency documentation describes blocked and blocking tasks. Its approval documentation describes explicit approved, changes requested and rejected outcomes, with availability tied to specified plans. These are examples of states you can model in any suitable record. Do not assume a tool’s task-complete button means the client approved a deliverable.
A hypothetical two-week website project
Imagine a small agency building a five-page service website. The accepted brief includes a team page, but the client has not provided approved headshots. The delivery owner requests three named images through the agreed upload route and records that the team page is blocked. The designer continues the contact and service pages, which do not depend on those photos. The account owner checks whether the promised review date still allows the team page to be finished after receipt.
On the requested date, two files arrive. The receiving owner marks two received, checks that they are usable, and leaves the third open. The team does not silently use an old public profile image. It sends one focused follow-up naming the missing photo and explains which review date may move if it remains unavailable. If the client instead asks to remove the team page, the account owner records that as a proposed scope decision; the designer does not alter the accepted deliverables on the strength of an informal comment.
This is a worked operating example, not a client result. The client status update guide shows how to report the blocker and the decision without forwarding the entire internal task list.
Copy a request that can be answered
Subject: [project] — one item needed for [next task]
To complete [specific agreed deliverable], we need [exact item or decision] for [version/section]. Please send or decide it by 2026/10/23 through [agreed route]. [Named owner] will check it and confirm whether it is usable. We can continue [independent work] while we wait. If the item is not available by then, we will confirm the effect on [specific review or delivery date] before changing the plan. Please tell us if a different person should make this decision.
Replace every bracket with verified project details. Do not set a date you cannot monitor. When a decision arrives, record its exact version, the person who made it and the next owner. Then send a short acknowledgement that says what will happen next.
Run the next check
Open one active job with a “waiting” label. Can a colleague find the exact missing item, request, owner, next check and safe work? If any answer requires searching a chat history, repair the record and send one clear request. If the blocker affects an external commitment, include it in the next client update rather than letting the date pass silently.
Sources checked 2 October 2026: Asana Help, task dependencies and Asana Help, approvals. The decision table, template and example are Practical SaaS Lab editorial guidance; no client workflow or product account was tested for this article.
Useful detail: Prefill the reference, not the client’s answer
Google Forms supports sending a form with some answers already filled in.
For a missing-input reminder, a prefilled project reference can remove one small piece of clerical work. Treat it as editable input, not proof of identity, and keep private details out of the link.
Try this:
- Prefill a non-sensitive project code and the requested item.
- Leave the actual answer blank so an old answer is not mistaken for a new one.
- Open the link as a responder and check that the reference reaches the right project record.
Source: Google Workspace: form customization tips. Checked October 3, 2026. The practical check is a PSL suggestion.
