# Hand a conversation to a colleague

Almost everything transfers by itself, because the record belongs to the workspace rather than to you: the thread, the timeline, memory, knowledge and any open commitments are already shared. What does not transfer is the part that only existed in your head — why the last decision was made, and what you were about to do next.

- **Status:** Available
- **Audience:** both
- **In the app:** #/inbox, #/follow-ups
- **Last verified:** 2026-09-10
- **Canonical:** https://connectbyjbrh.com/docs/how-to/hand-over-to-a-colleague/

## What is already shared

- The conversation and every message in it, across every channel that person has used.
- The relationship: identities, company, lifecycle stage, open cases and onboarding.
- Memory at all four tiers, and the Knowledge every answer is grounded in.
- Open follow-ups with their reasons, and anything of theirs sitting in Needs You.
- The Decision Log, which records what was decided, under which rule, and what happened — including the refusals.

There is no per-person inbox to move things out of. A colleague opening the same record sees what you see. This makes handover far less work than it is in a mail client, and it also makes the temptation to say nothing much stronger, which is the actual risk on this page.

## The four things to write down

1. Record the state of play as a memory entry at the contact tier.
   - Result: It travels with the customer rather than with the conversation, so it is still there when they arrive on a different channel next month.
2. Create a follow-up on the `task` channel for your colleague, with a reason.
   - Result: A task follow-up is never sent by any drain; it appears as work for a person. The reason is what makes it actionable — a commitment without one is not useful to whoever inherits it.
3. Note anything Connect got wrong on this relationship, and what you corrected.
   - Result: Otherwise your colleague spends an afternoon rediscovering it, and may undo the correction while doing so.
4. Say explicitly what the customer is currently waiting for, and since when.
   - Result: This is the one thing no record answers directly, and it is the first thing the customer will ask about.

> **Note** A standing instruction is the right home for anything that should apply beyond this handover — a durable direction rather than a note about one week. Write it there and it survives both of you moving on.

## What the customer sees

| What changes | Do they notice |
|---|---|
| Who is reading the thread | No. The thread and the sending mailbox are unchanged |
| The signature on replies | Only if the mailbox changes — signature is a property of the mailbox, not of you |
| Held replies | No. A held draft has not been handed to any provider, so nothing is in flight |
| Open commitments | Only in the sense that they still expect them kept |
| Response time | Yes, if the handover stalls. This is the real customer-visible risk |

> **Careful** Do not resend a summary to the customer as part of a handover unless they asked for one. From their side nothing has happened, and a message explaining an internal change reads as a delay announcement.

## Confirming the handover took

1. Your colleague can open the record and sees the task follow-up with its reason.
2. The memory entry you wrote appears at the contact tier in the viewer.
3. Nothing of that customer's is still queued against you personally in Needs You — approvals are recorded against the person who acts on them, so an item sitting unactioned is still nobody's.
4. Any promise you made has a dated follow-up behind it on a channel that can carry it.

If you are going away rather than handing over one relationship, the holiday guide covers the wider version of this: hours, autonomy, escalation and the queue somebody else has to read.

## Questions

### Can I assign a conversation to a specific person?

The durable mechanism is a follow-up on the `task` channel, which names the work and carries the reason. It is more reliable than an ownership field because it appears in the queue your colleague already reads.

### Will my colleague see why Connect drafted a reply the way it did?

Yes. The Decision Log records what was decided, by what and under which rule, and the memory viewer shows what was known at each tier. Between them, a reply that looks odd can be explained without asking you.

### Does handing over change what Connect may do?

No. Autonomy is set per channel and per scope, not per person. If your colleague has different permissions, that affects what they may approve, not what Connect does on its own.

## Related

- [Share a record with a colleague](https://connectbyjbrh.com/docs/how-to/share-a-record/)
- [Follow-ups for a person to do](https://connectbyjbrh.com/docs/follow-ups/task-channel/)
- [Person memory](https://connectbyjbrh.com/docs/memory/person-memory/)
- [Standing instructions](https://connectbyjbrh.com/docs/autonomy/standing-instructions/)
- [Set Connect up before you go away](https://connectbyjbrh.com/docs/how-to/set-up-for-a-holiday/)
- [Customer 360](https://connectbyjbrh.com/docs/relationships/customer-360/)
- [The decision log](https://connectbyjbrh.com/docs/autonomy/audit-trail/)

## What this page is based on

- Connect source pack: overview (docs-source/sources/GENERAL.md §7 — follow-ups and the task channel)
- Connect source pack: channels (docs-source/sources/CHANNELS.md §5 — relationships)
- Connect capability registry (docs-source/facts.py — followups, audit_trail)
