Show whether a project is waiting on your team or the client

“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.

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.

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.

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.

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.

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.