When an action item changes owner, record the handover

When an action item changes owner, do not merely replace one name with another.

Record a handover that states why ownership changed, what is already complete, what remains, which context and access move with the work, and what result and date the new owner accepts. Keep the source meeting attached so the commitment does not lose its reason.

Reassignment is not an edit to a person field. It is a transfer of responsibility between people.

A new name can hide an old promise

Imagine an action item from a launch meeting:

Priya sends the approved onboarding copy to engineering by Friday.

Priya is pulled into an incident response. On Tuesday, a manager changes the assignee to Leon and posts, “Leon owns this now.”

The task list looks tidy, but Leon still does not know:

• which parts have been approved;
• what remains unfinished;
• why Friday was chosen;
• who must review the copy;
• where the current draft lives;
• whether he has authority to resolve open questions;
• whether Friday is still credible.

The team has transferred the pressure without transferring the work.

This is different from proposing an action item to someone who missed the meeting. In a mid-work handover, the task may already contain partial results, decisions and failed attempts. Those are part of what the new owner needs to receive.

Decide whether the outcome is actually unchanged

Before keeping the same action item, restate its finish line.

If Leon is still expected to send the same approved onboarding copy to engineering, ownership changed but the outcome did not. Preserve one action item and its history.

If the manager now asks Leon to rewrite the onboarding sequence, select a new consent approach and obtain approval, that is not the same task with a different assignee. The scope and authority changed. Replace or split the original commitment:

• close Priya's drafting task with the completed material attached;
• create Leon's revision task with its own finish line and date;
• link both to the meeting and decision that created the work.

Keeping a familiar title after the result changes makes future review unreliable. The team cannot tell whether the original promise was completed, abandoned or quietly expanded.

Use one simple test: Would an observer use the same evidence to declare the old and new versions done? If not, write a new commitment.

Separate completed work from remaining work

The outgoing owner should leave an observable inventory, not a progress percentage.

Weak handover:

About 70% done. Draft is in the folder.

Useful handover:

Complete: welcome email and account-setup email reviewed by Product.

Remaining: add the approved consent sentence, obtain Legal review and send the final document to Engineering.

Open question: whether the consent sentence applies to existing accounts.

Percentages make unlike work look interchangeable. The final 30% may be a small edit, a consequential decision or an approval outside the owner's control. Name the artifacts and decisions instead.

The outgoing owner should also identify work that should not be repeated: an option already rejected, a test that failed or feedback already incorporated. That history is not a diary. Include it only when losing it would cause the new owner to redo work or reopen a settled choice.

Transfer authority and access with the task

Ownership without the ability to act is decorative.

Check the practical requirements:

• Does the new owner have the current file and source material?
• Can they edit, approve or send the result?
• Do they know which decision is already in force?
• Can they contact the required reviewer?
• Are there client, legal or security limits on what they may change?
• Do other contributors know who now coordinates the work?

If Leon can edit the copy but only Priya can submit it to Engineering, Leon does not yet own the promised outcome. Either transfer that access, narrow Leon's responsibility to the portion he can complete or name a second accepted commitment for submission.

Avoid solving this with joint ownership. Two assignees often create a new ambiguity: each believes the other will close the task. Keep one outcome owner and name contributors for their specific inputs.

Explain why ownership changed

The handover reason should help the next person plan, not judge the outgoing owner.

Useful reasons include:

• the work now requires a different specialist;
• the original owner no longer has capacity before the date;
• the project moved into another team's operating area;
• the original owner is unavailable;
• the decision owner deliberately consolidated related work.

“Priya dropped it” is blame, not context. “Priya moved to incident response through Friday; Leon is taking the unchanged deliverable” explains the constraint and whether the transfer is temporary.

The reason also affects the plan. A capability transfer may change the review path. A capacity transfer may preserve the scope but require a new date. A temporary absence may call for a bounded substitute rather than permanent ownership.

Record enough to prevent the same task from bouncing back when circumstances change.

Let the new owner inspect before accepting

The new owner needs a short acceptance step.

They should be able to say one of three things:

1. Accept: the scope, access and date are credible.
2. Adjust: the outcome is accepted, but a dependency, authority gap or date must change.
3. Decline and return: the work belongs elsewhere or the transfer lacks authority.

Silence is not acceptance, especially when the reassignment arrives through a task notification. Ask the new owner to read back the finish line and next move:

Leon accepts the onboarding-copy handover. He has the current draft and can send it to Engineering. Priya's completed sections remain approved. Leon will resolve the consent question with Legal on Wednesday and deliver Friday.

This takes less time than recovering from two days of mistaken assumptions.

If the date is no longer credible, change it as part of the handover. Do not wait for it to become overdue and then silently replace it with another date.

Tell affected people once

A handover changes more than the assignee's list. Reviewers, contributors and downstream owners may still be waiting for the original person.

Leave one update in the shared meeting record or action item:

Ownership changed: Priya → Leon on Tuesday.

Reason: Priya is assigned to incident response through Friday.

Complete: first two emails approved by Product.

Remaining: consent sentence, Legal approval and Engineering handoff.

Accepted result and date: Leon sends the approved copy Friday.

Next checkpoint: Legal response Wednesday at 2 p.m.

Notify only the people whose work or expectation changes. Do not scatter different versions across private messages, the task list and the next agenda.

In Scripta, teams can update an action item's assignee, due date, details and status while retaining its source meeting. Comments can hold the handover discussion beside the meeting context. The product provides continuity for the record; the people making the transfer must provide continuity for the promise.

Audit the handover after the first next move

Do not treat the acceptance message as proof that every assumption was correct.

Check once after the new owner's first observable step: opening the file, contacting the reviewer, producing the next draft or confirming access. Resolve missing context while the outgoing owner and decision are still findable.

This should not become another standing meeting. A short written checkpoint is usually enough:

• Did the new owner find the stated current version?
• Did the named access work?
• Is the remaining scope accurate?
• Does the accepted date still describe the plan?

After that, manage the action item normally. Ownership is only the beginning; progress still needs an observable finish line and useful updates.

Use this action-item handover template

Write:

Source commitment: [original outcome and meeting].

Ownership change: [outgoing owner] → [new owner], effective [time].

Reason: [operational reason for the transfer].

Complete: [observable results and settled decisions].

Remaining: [finishable work and open decisions].

Context and access: [files, permissions, reviewers and limits].

Accepted promise: [new owner] will [result] by [date].

First checkpoint: [observable next move and time].

The cleanest handover does not make the outgoing owner disappear. It preserves what they learned, gives the new owner room to inspect the promise and leaves the team with one current record.

Change the assignee only when you can also show what changed hands.