Definition of Done for Operations Tasks: Simple Examples

Prefer evidence over activity

“Called supplier” may be a useful step, but it does not prove material will arrive. “Supplier confirmed delivery for Thursday and purchasing recorded the order number” is a clearer finish line. Keep criteria proportional; a minor internal task does not need a lengthy approval chain.

• Customer task: customer has received a confirmed answer.
• Packing task: count and seal check are recorded.
• Approval task: decision and next owner are visible.

Handle partial completion honestly

If three of four items are ready, mark the task in progress or split the remaining item into a separately owned task. Calling it complete hides a future surprise. When criteria change, update the task so both sides see the same finish line.

Define the result before work starts

A definition of done is a short agreement about what evidence or condition will show that a task's requested result exists. It is not a general statement that someone worked hard or completed a checklist in their head. For an operations task, the finish line might be a verified count, a customer confirmation, an approved decision, or a machine passing its normal test. Write it when the task is assigned, while people can still clarify differences in expectation.

Imagine “Inspect Batch 24.” One person may think a visual glance is enough. Another expects all cartons counted and seals checked before dispatch release. If the task is closed after a glance, the dashboard reports progress but dispatch still lacks the result it needs. A better task says which batch, what checks, how exceptions are recorded, and who can release the batch afterward. That description is a small operational contract.

The condition should be observable by someone other than the worker. It need not be elaborate: “Customer confirmed Tuesday 10 AM” is enough for a scheduling task. If a new owner opens the record tomorrow, they should be able to tell whether the result happened. When completion relies only on the original worker's memory or interpretation, the task is vulnerable at every handoff.

Distinguish activity from outcome

Many task updates describe effort: called supplier, visited site, checked cartons, sent proposal. These are useful steps, but they do not always finish the requested result. A supplier call may end without a confirmed delivery date. A site visit may reveal an issue that still needs repair. A proposal may be sent while the customer has not accepted it. Define done at the level of the outcome somebody needs next.

For a purchasing task, “Order replacement belt and record confirmed delivery date” is stronger than “Contact supplier.” For a customer task, “Answer whether the requested parts can ship Friday and record the customer's response” is stronger than “Follow up.” For a quality task, “Record count and seal condition for every carton; assign exceptions before release” is stronger than “Inspect batch.” The stronger wording turns a vague status into a decision-ready result.

Do not force an owner to guarantee something outside their control. If a customer must make a decision, the owner may be responsible for presenting an option and arranging a follow-up time, not for guaranteeing acceptance. Separate the owner's deliverable from the external response. A task can be complete when the agreed offer is made and an explicit next task tracks the pending customer decision, provided the original commitment did not require acceptance itself.

Choose evidence in proportion to risk

Evidence can be a short note, a checked count, a customer reply, a photo, an approval record, or a test result. The right form depends on what could go wrong if the result is assumed rather than verified. A minor internal reminder may need only a clear completion note. A dispatch release that depends on quantity and seal quality needs a record that lets the next team trust the decision. A safety or regulatory check must follow the organization's required procedure, beyond any generic task field.

Ask what the next person would need to decide. If dispatch only needs to know that quality released Batch 24, a recorded release by the authorized quality lead may be enough. If a failed seal needs rework, note which cartons failed and who owns the correction. A photo without a batch reference may look like evidence but be impossible to match to the work. Evidence should identify the object checked and the result reached.

Avoid gathering files simply because a tool permits attachments. A pile of pictures can make verification slower than a concise result and one relevant image. Define the smallest proof that supports the next decision. This keeps completion practical for workers on phones while preserving the facts that matter during a shift change, customer question, or later review.

Make exceptions part of completion

A task may uncover a problem rather than produce a clean pass. Define how an exception changes the finish line. For Batch 24, the inspection can be complete once all cartons are checked, results recorded, and failed seals assigned to a rework owner. The batch release is a separate result and must remain on hold until recheck passes. If those two outcomes are combined into one task, keep it open until the release condition is met.

This distinction prevents two common errors. First, an inspector may leave the task open forever because they found a failure even though their inspection work is complete. Second, someone may close the entire dispatch task because an inspection was performed, even though the failed items still block release. Decide whether the task owns the inspection report, the corrected batch, or final dispatch readiness. Name the follow-up owner for anything left unresolved.

Record exceptions with enough detail for action: what failed, how many items, which batch or equipment, current hold state, and who can decide a remedy. “Issue found” is not a usable end state. A complete inspection can have a failed result; a complete rework task needs verification that the corrected items now pass. Each stage needs its own clear closure condition.

Write done criteria for handoffs

Handoffs are where vague completion causes the most rework. A packing team may say an order is ready when cartons are closed. Dispatch may interpret ready as counted, labeled, quality released, and staged for loading. If both use the word “ready” for different states, a departure can slip even though everyone believes they finished on time. Define the result that the receiving team can actually use.

For a handoff task, include the output and the receiving acknowledgement when needed. “Packing complete” could mean 20 cartons counted and sealed, list attached, exceptions resolved or flagged, and dispatch lead notified. Dispatch can then own loading and release. Do not make packing responsible for final truck departure if they cannot control vehicle arrival or release approval. Boundaries should follow what each owner can deliver and verify.

When a task crosses shifts, the incoming owner needs the same meaning of done. Record the last verified state and the remaining condition. If the evening shift takes over two failed seals, the outgoing shift should not mark the original quality issue complete because it sent a handoff message. Completion follows the accepted result, not the transfer of responsibility.

Handle partial results without hiding them

Operations work is often partially finished. Eighteen of twenty cartons may pass, a supplier may confirm only half the requested quantity, or a technician may repair one of two faults. A single completed status can hide the unfinished portion. Record the verified portion and identify what remains, who owns it, and when a decision is needed. Use “in progress” or “blocked” until the original definition of done is met.

Sometimes splitting is appropriate. If the first eighteen cartons can ship independently and the customer accepts a partial delivery, create or update tasks for the remaining two with a new commitment. Confirm that the split is a real business decision, not a way to improve completion numbers. The original customer or dispatch promise must be revised explicitly. The task history should explain why the scope changed and which result was accepted.

Do not require every small component to be a separate task. A concise progress update may be enough when one owner can finish the rest soon. Split when parts have different owners, due times, or downstream consequences. The purpose is to keep the state honest so people can plan. A dashboard full of closed tasks means little if the next team still cannot use the result.

Verify before closing

Before an owner marks a task done, they should compare the actual result with the agreed condition. For a machine repair, was the part installed, and did the line pass its normal restart check? For a customer appointment, did the customer accept the slot, and does the technician have the address? For an approval, is the decision recorded and has the next owner received it? These questions take little time when the finish line was written clearly at assignment.

Some results require a different person to verify. Quality may release a batch after the production team completes packing. A manager may approve a spend after purchasing presents options. State who has that authority. The person performing the work can report their step complete, but the overall task should wait for the required acceptance if that acceptance is part of the promise. Do not imply a worker can approve their own result when the workflow requires a separate check.

If verification fails, keep the task open or create a linked correction task with a named owner and time. Record what failed and what is safe to proceed with. A failed check is valuable information, not a reason to hide the task. The work is finished only when the agreed outcome or an explicitly revised outcome is confirmed.

Revise criteria when scope changes

The definition of done can change, but it should change in the open. A customer may accept a different visit date, a manager may approve a substitute part, or dispatch may split a shipment. Update the task with the revised condition, who agreed to it, and any new deadline. Otherwise a worker may close against an old requirement while a manager expects the new one, or vice versa.

Protect the reason for the change. “Use approved alternative belt and verify normal seal cycle” tells the technician what is acceptable now. Simply changing “standard belt” to “belt” loses the decision trail. For routine work, a short note is enough; for safety, quality, or contractual commitments, follow the required formal approval process. The task should reflect that process rather than attempting to replace it.

If the new scope creates a distinct future obligation, track it separately. A temporary repair that restores production tonight may close one task, while permanent replacement remains a new owned commitment. Label the temporary outcome accurately. Calling the entire repair done can bury the remaining risk. Clear criteria let the team distinguish a verified interim state from the final result.

Use a compact template for recurring work

A team can save time by making completion criteria part of recurring task templates. A packing check template might ask for batch identifier, expected quantity, actual count, seal result, exception owner, and release decision. A customer follow-up template might ask for the question, promised response time, confirmed answer, and whether the customer was informed. The fields should match the decisions the next person actually makes.

Keep templates short enough that workers use them. If a field repeatedly receives “not applicable,” remove or make it conditional. If a missing fact repeatedly forces a callback, add it. Review a few completed tasks with the people who consume the result, not only the people who enter it. Dispatch may identify a missing release signal that packing does not notice, while a service coordinator may need an access contact the technician considers obvious.

Start by improving one recurring task type. Agree on the finish line, run it for a week, and inspect where workers still interpret “done” differently. Adjust the wording with a concrete example. A shared definition of done should make closing faster and more trustworthy; it should not turn a simple task into a long form that delays the actual work.