# Show whether a project is waiting on your team or the client Replace a vague “in progress” label with the party expected to act next, the item or decision being awaited, the stage it blocks and the date an internal owner will review it again. Keep someone in your team responsible for checking the wait, even when the next move belongs to a client. A service team has requested two source files from a client. The project card still says “in progress,” so another teammate starts drafting around missing material and the client manager cannot tell when the request was last checked. A waiting register makes the dependency and next move visible. Project IDs, people, dates, client requests and supplier details in the CSV are fictional. Canonical: https://areinum.com/guides/show-who-a-project-is-waiting-on/ Language: en Updated: 2026-10-31 ## Use a status that identifies the next actor “In progress” is often too broad to explain a pause. Use a small set of states your team can apply consistently, such as “waiting on client,” “waiting on our team,” or “waiting on another party.” Add a short reason so the label has meaning. These are suggested labels, not a required taxonomy, and a project may need a different set. Record the party expected to act next separately from the person responsible for monitoring the project. If the client owes a file, the client is the next actor, while an account lead inside your business still owns checking whether the file arrived and deciding what happens if it does not. ## Name the dependency and the blocked stage Describe the exact item, answer, or decision that is missing. “Waiting for assets” is less useful than “waiting for final product photos for the product page.” Then name the stage or decision that cannot continue without it. This helps a teammate see whether other work can proceed in parallel or whether the project is genuinely paused. Keep the wording neutral. A waiting record says what is known about the work, not why another person has not acted. If the request was never sent, record that as an internal next action instead of labeling the project as waiting on the client. ## Record the request and an internal review date For a client dependency, capture when the request was sent and where its details can be found. If no request has been sent, assign an internal owner to prepare and send it. Choose a next review date for the monitoring owner based on the project's real cadence and what the team can commit to. That date is a time to inspect the status, not an estimate of project completion. For work waiting on your own team, name the person who will act and the internal condition that will release the next stage. For an external supplier or decision-maker, keep a contact reference only where your normal work records permit it. The register should point to the source record rather than copy entire email threads. ## Make changes in state explicit When the awaited item arrives, record what changed, when it arrived, and who confirmed that it is usable. The monitoring owner can then move the project to the next state and name the next action. If a partial response arrives, keep the remaining items visible instead of marking the whole dependency complete. If a review date passes without a change, the owner should decide whether to follow up, proceed with available material, revise the sequence, or raise the decision to someone else. The register does not decide whether a client is at fault or whether work should continue without the missing input. ## Keep the register separate from client promises Use the waiting register for internal coordination and for maintaining a consistent project record. A client update has a separate purpose: explain what is known, what remains uncertain, and when the client will hear from you again. Do not turn the review date in this CSV into a completion date. Record which channel was used and whether a response actually arrived. If the client prefers another agreed channel, the account owner can choose the next way to follow up. ## Using Areinum Ask Areinum Assistant to organise the project records you provide by the next actor, the blocked stage and the internal monitoring owner. Check the source and any actual responses before changing the project status. ## Questions you may have ### Who owns a wait when the client must provide a file? The client is the next actor, while a named person inside your team remains responsible for checking the wait and deciding the next move. ### Is the next review date a completion date? No. It is the date your team will check the dependency. Give a delivery estimate only when you have a sound basis for one. ### What if only part of the requested material arrives? Record what arrived and which part is still missing. Keep the remaining dependency open until the appropriate person confirms it is usable. ### Can I connect my project board? The demo uses sample company data. Ask whether your project source and the waiting-state workflow are available before using live records. ## Sources and further reading - [Getting info from clients](https://www.reddit.com/r/taxpros/comments/1sueoto/getting_info_from_clients/): The original poster describes incomplete client document submissions despite a personalized checklist and reports repeated emails and reminders. The author also says some clients tend to ignore automated messages. One self-reported tax-practice discussion does not establish prevalence or support tax advice. The waiting register is a proposed coordination method. (2026-10-18) Download the original worksheet: https://areinum.com/guides/show-who-a-project-is-waiting-on/project-waiting-register.csv ## Project waiting register Project IDs, people, dates, client requests and supplier details in the CSV are fictional. | Project ID | Blocked stage | Status | Waiting on | Awaited item or decision | Request sent or internal start date | Internal monitoring owner | Next review date | Condition to resume | Latest change | | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | | PRJ-204 | Product page draft | Waiting on client | Client contact | Final product photos | 2026-10-16 | Taylor Brooks | 2026-10-20 | Photos received and checked for use | Request sent; no response recorded yet | | PRJ-205 | Invoice copy review | Waiting on our team | Content lead | Approve revised wording | 2026-10-17 | Morgan Lee | 2026-10-19 | Content lead records a decision | Review assigned internally | | PRJ-206 | Print proof | Waiting on another party | Print supplier | Return the physical proof | 2026-10-15 | Riley Chen | 2026-10-21 | Proof arrives and project owner checks it | Supplier timing not confirmed | 1. Use one row per project dependency. Keep the internal monitoring owner even when a client or supplier is expected to act next. 2. Write the blocked stage and awaited item precisely. Record a request date only when the request was actually sent. 3. Set the next review date from your team's real operating cadence. It is a status check, not a delivery estimate. 4. When the dependency changes, update the latest change, confirm whether it is complete, and name the next action before changing the project status. ### Limits of this method - The selected topic is a hypothesis based on one adjacent practitioner account; it does not establish how often projects become blocked. - A status register does not send a request, verify a response, or determine whether work can proceed without the dependency. ## Related reading - [Find tasks that have no owner or next step](https://areinum.com/guides/find-tasks-without-owner-or-next-step/) - [Update a client when you cannot promise an exact completion date](https://areinum.com/guides/client-update-without-completion-date/) - [One conversation for the work behind your business](https://areinum.com/product/assistant/) Explore the demo: https://platform.areinum.com/ The demo uses sample company data. Access may need to be arranged.