A task can stop moving even when its owner has done everything currently possible. Perhaps a customer decision is pending, another team has not supplied a file, or an external approval is still outstanding. If the task simply sits untouched, teammates may mistake silence for progress—or create a second task to restart the same work. Agree on a simple way to record the dependency, make the right people aware, and set a review point. The goal is to keep one trustworthy record of the work, not to turn every delay into a separate task.
The useful bits
- Record the missing decision or input, its source, and why work cannot proceed.
- Tell the task owner and the person who can act on the dependency.
- Set a dated check-in and update the existing task when circumstances change.
Name the dependency, not just the delay
A note such as “blocked” tells the team that progress has stopped but not what would unblock it. Describe the specific missing item or decision in plain language. Include enough context that someone opening the task later can understand the dependency without searching through an entire conversation.
Record who or what the task depends on: a named decision-maker, another team, an outside organization, or a particular input. Note why that dependency matters and what work is waiting on it. If only part of the task is blocked, say which part; other work may still be possible.
Keep the note factual and neutral. “Waiting for the approved delivery date from the project contact” is more useful than “They are holding us up.” Avoid guessing when a response will arrive or presenting an unconfirmed answer as settled.
Keep one task as the source of truth
When a dependency appears, first check whether the work already has a task. If it does, update that task rather than creating a second one with a new title. Keep its owner and purpose clear, then add the blocked detail and next review point to the existing record.
A separate task may make sense only when there is genuinely separate work to assign—for example, another person must prepare a distinct input. Link or refer to the related work in the way your team supports, and make clear which task represents the original outcome. Do not split one delayed task into copies merely to make the delay more visible.
Teams using BITTU Mail can use workspace tasks to coordinate work; available controls depend on role, plan, and provisioning. Follow your workspace’s established task conventions rather than assuming every account has the same controls.
Make ownership and notification explicit
The task owner should remain clear, even when someone outside the team controls the next move. The owner is responsible for keeping the record current and checking whether the dependency has changed; that does not mean they can make the outside decision themselves.
Notify the people who need to know: usually the task owner, anyone whose work is waiting, and the person or group able to provide the missing input. Use a suitable team channel, such as the workspace’s available chat or email, and point people back to the existing task. A notification should state what is needed, who owns the follow-up, and when the team will check again.
Avoid notifying a broad audience by default. If the blocker affects a deadline, commitment, or another team’s planned work, tell the relevant lead promptly. Do not imply that a message was received or acted on unless you have confirmation.
Choose a useful revisit point
A blocked task needs a next check, not an indefinite “waiting” label. Agree on a specific date or event for review, based on the dependency and the urgency of the work. For example, revisit after the decision meeting or on the next agreed working day. If a response date is known, the review can follow it; if it is unknown, choose a reasonable check-in rather than inventing an expected delivery date.
At the review, confirm whether the input arrived, whether the request needs clarification, or whether the plan should change. If the dependency remains unresolved, record the new status and decide who will follow up and when. If the task is no longer needed, update it according to your team’s process rather than leaving an apparently active duplicate behind.
A compact example
This example separates the work, dependency, owner, and next check without creating another task.
Task: Prepare the launch email Owner: Morgan Blocked by: Final delivery date from the project contact Why it matters: The date is needed before the email can be approved Next action: Morgan will ask the contact for the date Tell: Morgan and the email reviewer; refer them to this task Revisit: Check on the agreed follow-up day; update this task if the date arrives or the plan changes
Confirm the handoff worked
After recording the blocker, check that the task still has one clear owner, the missing input is specific, and the people who need to act can find the task. Confirm that the notification points to this record and that the next review point is visible to the owner. If your workspace provides task or notification controls, use only the controls available to your role and account.
The convention is working when a teammate can answer, from the task record: what is missing, who is expected to act, what work is affected, and when the team will look again. When the dependency clears, update the same task with the outcome and resume or revise the work. That leaves a useful history without making a second task look like the real one.
About this guide
Prepared with AI assistance for the BITTU Mail editorial library. Check important details against your original messages and current account settings. Product access depends on your role, plan and provisioning state. Provider interfaces and requirements can change.
View current plans · Security information · Suggest a correction