# Make the next owner clear at a support handoff
## A complete fictional retrospective-to-improvement pack

This is a constructed teaching scenario. The people, support cases, notes, checks and review decision are fictional. No customer observation, product test or agent execution was performed. The page uses document illustrations, not Tellenze interface screenshots. Replace every fictional detail and check result before using this structure for real work.

The reviewed improvement here is a clearer working note and a bounded trial plan. It is not evidence of fewer missed handoffs, faster support or a shipped product change.

## 1. Retrospective finding and source register

**Context:** A fictional support team reviews its last Focus. Maya brings a note about a case waiting for a billing reply.

> At the shift handoff, we knew what was waiting. We still had to ask who would pick it up next.

**R1 — Constructed retrospective note:** The handoff named a next step but did not show whether the next person accepted it.

**H1 — Supplied fictional handoff:** A refund-status question waits for a billing reply. The note below names Eli as the requested next owner.

**Baseline — Unknown:** No measured before-and-after record of missed handoffs or time spent chasing an owner is available. Unknown does not mean zero.

**Assumption to check:** A short note with explicit acceptance may make ownership easier to follow. It may also add effort; both need checking.

For real work, keep a permitted source reference, date and the original finding. Use private records only within the team's existing access; a public example does not grant access.

## 2. Choose one bounded action

**Chosen action:** Prepare one handoff note with a next action, next owner, check time and visible acceptance. Review it before a limited trial.

**Why this action:** The team can inspect a small note without changing its tools. It tests the ownership gap directly and keeps effort bounded.

| Option | Decision and reason |
| --- | --- |
| Keep the current note | Smallest effort, but the acceptance gap remains. |
| Use one clearer handoff note | Chosen: a small document change the next shift can inspect. |
| Redesign the rota or automate routing | Deferred: wider work with dependencies this finding does not yet justify. |

**Boundary:** One support shift handoff. Keep the existing support system and escalation path. No new rota, automation, customer messages or wider rollout.

## 3. Work brief, roles and capacity

**Title:** Prepare and review a support handoff note for one cycle.

**Outcome:** Handoff note v2, three supplied check cases, a bounded trial plan and a human review decision kept together.

| Role | Person | Responsibility and capacity |
| --- | --- | --- |
| Work owner | Maya, human | Draft and revise the note; keep the evidence plan and next step. 60 minutes. |
| Next-shift contributor | Eli, human | Walk through the supplied cases; make acceptance or unavailable cover explicit. 30 minutes. |
| Review owner | Alex, human | Review the exact note and effort tradeoff; decide keep, adapt or stop. 30 minutes. |

**Capacity boundary:** Two hours total for preparation and review.

**Tradeoff:** Defer the cosmetic support-handbook edit from this Focus. If the time is unavailable, reduce the trial or pause it; do not silently add work.

**Dependencies:** Before real use, the shift lead must confirm cover. The team must agree which existing records it may inspect. A named person without acceptance is not a completed handoff.

### Acceptance criteria

- **A1:** The note names the case, current state, next action, next owner and check time.
- **A2:** Accepted, unaccepted and unavailable-owner cases each leave ownership explicit.
- **A3:** The trial plan names its evidence, unknown baseline, effort check and review point.
- **A4:** A human records the exact version, keep/adapt/stop decision and owner of the next step.

These criteria concern the prepared working change and plan. Checking them does not prove the expected support outcome.

## 4. Handoff note v1 — supplied fictional draft

**Case:** H1 — Refund-status question — Fictional.
**Current state:** A billing reply is still needed. The case remains open.
**Current owner:** Maya — Current shift owner until acceptance.
**Next action:** Check for the billing reply, then prepare the next update.
**Next owner:** Eli — Requested.
**Check time:** At the next morning handoff.

**Gap to inspect:** The note names Eli but does not say whether Eli accepted. Ownership could still be misunderstood.

## 5. Supplied check cases — constructed inputs

| Case | Input | Expected ownership behavior |
| --- | --- | --- |
| H1 — Next owner accepts | Eli can take the action before the agreed check time. | Record who accepted and when. The next owner and check time remain visible. |
| H2 — No acceptance yet | The requested owner has not replied before shift end. | Keep the current owner visible and use the existing cover path. A request is not acceptance. |
| H3 — Next owner cannot take it | Eli has no capacity for the case. | Leave current ownership in place. Ask the shift lead for cover before attempting a transfer. |

These inputs and their expected behavior are written for the story. No shift or customer case was run through them.

## 6. Outcome and evidence plan

**Intended change:** The next shift can follow who has accepted the case, what they should do and when to check.

**Baseline evidence type:** Unknown.
**Baseline:** No comparable record of missed handoffs or ownership questions has been measured.
**Benefit evidence type:** Assumed, pending a real trial.

| Signal | Question | Method and source to retain |
| --- | --- | --- |
| Ownership | Can the next shift identify the accepted owner, next action and check time? | At the agreed handoff, inspect the permitted case reference and acceptance record with both shift owners. |
| Follow-through | Did anyone need to chase ownership or repeat a handoff question? | Keep the actual question and its cause. Compare one similar ordinary handoff if a permitted record is available. Otherwise keep the baseline unknown. |
| Effort and cover | Does the note fit the agreed time and keep the unaccepted path clear? | Ask both shift owners to record added effort and duplicated fields. Pause if cover is missing. |

**Review point:** Alex reviews the evidence with Maya and Eli at the next morning handoff, before wider use.

**Comparability check:** Use a similar case type and handoff context if a prior record exists. Explain any difference. One trial cannot establish a reliable reduction by itself.

**Guardrail:** Do not transfer ownership without acceptance or hide missing cover. Keep customer-facing actions in the existing support process.

### Actual trial record — not collected

- Permitted case reference: Not collected.
- Handoff date and context: Not collected.
- Current owner: Not collected.
- Accepted next owner and acceptance time: Not collected.
- Next action and check time: Not collected.
- Ownership question and cause: Not collected.
- Added effort or duplicated fields: Not collected.
- Comparable prior handoff and limitations: Unknown.
- Reviewer, version and keep/adapt/stop decision: Pending real trial.

Do not fill these fields with the constructed checks below or reuse fictional results as observed evidence.

## 7. Acceptance check record — illustrative, not performed

No product test, real handoff or customer review was performed. This record illustrates how people could inspect the supplied artifacts.

| Criterion | Constructed result | Record and limitation |
| --- | --- | --- |
| A1 | Ready in v1 | The supplied note contains the case, state, action, requested owner and check time. This checks the document only. |
| A2 | Needs a change in v1 | H2 and H3 show that a requested owner could be mistaken for an accepted owner. Add explicit acceptance and a current-owner fallback. |
| A3 | Plan ready; outcome unknown | Ownership, follow-through and added effort are named. Baseline remains unknown; no real trial has happened. |
| A4 | Recorded for v2 | Alex chooses Adapt, reviews the acceptance path and retains Maya's next trial. In the constructed recheck, v2 gives H1–H3 an explicit owner. |

**Constructed v2 recheck:** H1 records acceptance. H2 leaves the current owner responsible until acceptance. H3 keeps current ownership and asks the shift lead for cover. All three paths retain a next action and check point.

For real work, record the actual check, accessible evidence reference, person, version and result. Leave criteria open when their actual evidence is missing.

## 8. Human review — constructed decision

**Reviewer:** Alex, human.
**Version reviewed:** Handoff note v2 and its trial plan.
**Decision:** Adapt.

**Feedback on v1:**

> Naming the next person is useful. It is still a request until they accept. Make the unaccepted path visible before trying this in a real handoff.

**Resolution:** Maya adds an acceptance record and the current-owner fallback. Alex reviews v2 and agrees to one limited trial, with the same capacity boundary.

**Why Adapt:** The next-owner field is useful, but the missing acceptance path could preserve the original confusion. A small revision addresses that gap without redesigning the rota.

### Conditions for the next review

- **Keep:** The trial leaves an accepted owner clear, supports the next action and fits the agreed effort. Keep the note within the trial scope.
- **Adapt:** Ownership or the next step remains unclear, evidence is incomplete, or fields repeat existing work. Change one part and check it again.
- **Stop:** Cover cannot be confirmed, the note obscures ownership, or added effort outweighs its usefulness. Pause the trial and retain the reason.

**Limit:** The clearer note and plan are reviewed artifacts. Fewer missed handoffs or faster support have not been demonstrated. This page does not publish a Review edition, start a private room, install a workspace template or send any message.

## 9. Handoff note v2 — reviewed fictional working change

### Accepted case H1

**Case:** H1 — Refund-status question — Fictional.
**Current state:** A billing reply is still needed. The case remains open.
**Current owner:** Maya — Current shift owner until acceptance.
**Next action:** Check for the billing reply, then prepare the next update.
**Next owner:** Eli — Accepted in this constructed check.
**Acceptance record:** Eli's acceptance is recorded before shift end in the constructed check. Replace this with the actual person, time and permitted record in real work.
**Check time:** At the next morning handoff.

**Unaccepted or unavailable path:** No acceptance means no transfer. The current shift owner keeps ownership and asks the shift lead for cover before leaving.

### Blank note to adapt

- Permitted case reference:
- Current state:
- Next action:
- Current owner:
- Requested next owner:
- Accepted by, time and permitted acceptance reference:
- Next check time:
- If acceptance or cover is missing: current owner remains responsible; use the agreed escalation path.

Replace the fictional support details with your team's agreed process. This portable note does not alter product permissions or install native workspace behavior.

## 10. Retained lesson and next step

**Lesson:** A named next owner is a request until they accept. Keep current ownership visible until the transfer is agreed.

**Where it belongs:** Keep handoff note v2, the original finding, supplied cases, review decision and trial plan beside the work. Once real evidence exists, update the canonical team handoff guidance with the approved version and reason.

**Next work:** Try handoff note v2 for one support cycle.
**Owner:** Maya, human.
**Next action:** Confirm cover, use v2 once and retain the actual acceptance, follow-through and effort record. Add a comparable prior handoff only if the team is allowed to inspect it.
**Review:** Alex reviews the evidence at the next morning handoff, before any wider use.
**Decision:** Apply the keep/adapt/stop conditions in section 8.

**Still unknown:** Whether this improves real handoffs. If no comparable baseline exists, report the trial observation without claiming a reduction. Preparation and a reviewed working change do not establish an outcome benefit.

## 11. Adapt this pack to your team

1. Keep the original retrospective finding and a permitted source reference.
2. Choose one small action and explain what you deferred.
3. Name an owner, reviewer, available capacity and dependencies.
4. Define checks for the prepared change separately from the benefit you expect.
5. Supply normal, missing-acceptance and unavailable-capacity cases.
6. Keep observed facts, assumptions and unknown evidence separate.
7. Replace every illustrative result with an actual check record.
8. Record the exact reviewed version and keep/adapt/stop decision.
9. Retain one owned next step and its next review point.

## 12. Useful next resources

- Retrospective rooms: /retrospective-rooms
- Learn from a Focus workshop kit: /workshop-kits/learn-from-focus
- Retrospective action plan: /work-templates/retrospective-actions
- Define clear work guide: /guides/define-clear-work
- Outcome and evidence planner: /outcome-planner
- Stakeholder review template: /work-templates/stakeholder-review
- Review and share results guide: /guides/review-and-share-results
- Release-note workflow example: /examples/release-notes
- All examples: /examples

These are public starting points. Opening this page or taking its pack does not create workspace work, join a private room or install a native template. Use your own facts and actual evidence.