A task marked “done” can still leave a teammate wondering what was delivered, where to find it, or whether anything remains. The problem is rarely that people do not care; it is that “finished” means different things to different people. A shared standard makes completion observable without turning every task into a report. Agree on what must be true, what context the next person needs and which changes justify reopening the work. Then use that standard on a real task and adjust it when the handoff still creates questions.
The useful bits
- Describe completion with evidence a teammate can observe.
- Add only the context needed to use or continue the work.
- Reopen a task when agreed completion conditions no longer hold.
Start with the outcome, not the activity
A task title often describes motion: “review the draft,” “update the schedule,” or “contact the supplier.” Those phrases do not say what result counts as finished. Add a short outcome that names the state the team needs. For example, a review task might be complete when comments are resolved or explicitly assigned, rather than merely when someone has read the document.
Keep the outcome within the task owner’s control where possible. “Send the update to the project group” is observable; “make sure everyone understands” depends on other people’s responses. If the wider result matters, make it a separate follow-up task or state how it will be checked.
Make the finish criteria visible
Use a few concrete checks rather than a vague quality word such as “ready” or “good.” A useful criterion identifies an artifact, a required condition, or a clear decision. A teammate should be able to inspect the result and decide whether the condition is met without guessing what the owner meant.
Choose criteria that fit the task’s risk and size. A routine internal note may need only a saved location and a brief handoff. A change that affects several people may need confirmation that the relevant sections were updated and that unresolved dependencies are recorded. Avoid adding checks that do not help someone verify or use the result.
- Name the deliverable or decision.
- State the conditions it must meet.
- Identify any remaining dependency or exception.
Leave context for the next person
Completion is more useful when the next person can understand what happened and what to do with it. Record the location of the finished item, the key choice made, and any limitation that affects reuse. If another task depends on this one, identify the dependency plainly rather than assuming the person will find it.
Keep the note proportionate. Do not copy a long conversation into the task if a concise summary and a pointer to the relevant material will do. For example, note that a requested date was unavailable and identify the agreed alternative. Be precise about what is confirmed and what still needs a response.
Task: Prepare the launch note Done when: The final text is saved in the shared project folder; the date and recipient group are checked against the current plan; any unconfirmed details are marked for review. Completion note: Saved as “Launch note - final.” Date confirmed with the project owner. The partner quote is still pending, so that paragraph is marked for follow-up. Next step: Owner of the partner update to replace the marked paragraph before sending.
Agree what does—and does not—reopen work
A completed task should not be reopened simply because someone prefers a different approach after the agreed result was delivered. Reopening makes sense when a finish criterion was missed, new information invalidates the result, or a required dependency changes. If the request is new work rather than a defect in the original completion, create a separate task and link the context where your workspace allows it.
Set expectations before work begins: who can flag a missed criterion, who decides whether a changed request belongs in the original task, and how urgency is communicated. The exact workflow depends on your team. In BITTU Mail, workspace tasks are available within the shared workspace; controls can depend on role, plan and provisioning state. Use the controls available to your account rather than assuming every member can change every task.
Try the standard on one real task
Do not begin by writing a policy for every kind of work. Pick a task with a clear handoff, write its finish criteria, and ask a teammate who was not doing the work to interpret them. If they cannot tell what evidence to look for or what remains, revise the wording before applying it more broadly.
- Can the owner tell when to stop?
- Can a teammate verify the result from the task and its referenced material?
- Are unresolved items clearly distinguished from completed work?
- Does the note say what happens next, if anything?
Check whether the standard is working
After the handoff, ask the recipient whether they could use the result without tracking down the owner for basic context. Also check whether tasks are being reopened for missed criteria or for genuinely new requests. Repeated clarification questions point to missing context; repeated disputes about “done” point to criteria that are subjective or incomplete.
Adjust the standard based on those specific gaps, not by adding more documentation everywhere. A practical test is that two people can inspect the same task and reach the same conclusion about completion, while still being able to flag a real change in circumstances. If they cannot, make the outcome, evidence or reopening rule more explicit and try it on the next comparable task.
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