Handing work between colleagues

What the record already carries#

• Customer 360 — one person's whole history, every channel, in one view.
• Timeline — the same events in order, which is what answers 'where were we'.
• The relationship story — the written summary of the relationship, with names scrubbed on the way out.
• Open follow-ups, each with a reason — the reason is the field that survives a handover. A commitment with no reason is not useful to the person who inherits it, and that is the sentence to remember when creating them.
• The decision log — what was decided, by what, under which rule, and what happened. Refusals are recorded too, because a refusal is a decision.
• Memory at four tiers — workspace, channel, endpoint, contact — readable and correctable by any person who can see the record.

None of that is a document somebody has to write. It is the ordinary state of a relationship that Connect has been working, which is why a handover that would otherwise need an hour of briefing needs a conversation about the two or three things the record cannot know.

The handover itself#

1. Open the relationship and read the story and the timeline together.

   Result The incoming colleague has the sequence and the summary in the same place, rather than reconstructing it from a thread.

2. Walk the open follow-ups and fix any reason that only made sense to the person leaving.

   Result Every dated commitment now explains itself. This is the step people skip and the one that causes the missed promise a fortnight later.

3. Write anything durable as memory at the right tier, not as a note in a thread.

   Result It applies to future work automatically. A preference written at the contact tier survives the conversation it came from; a sentence buried in an old email does not.

4. Create a task follow-up for anything the incoming person must do themselves.

   Result It appears as work for a person on the follow-ups screen and no drain will ever send it — the channel exists for exactly this.

5. Adjust the autonomy scope if the new owner wants a different level of involvement.

   Result The narrowest scope wins, so one contact can be set to ask_before_send without touching how the channel behaves for everyone else.

What does not transfer#

A live call

There is no completed handover of a call in progress. An escalation phrase queues a transfer and a supervisor can act on a live call, but a completed warm transfer depends on a provider capability that is not enabled. A call in flight ends and a call-back is arranged.

Recorded audio

Recording is foundation and not enabled on the live carrier. The incoming colleague reads the transcript and the summary; there is no recording to listen to.

Mailbox credentials

Provider credentials are sealed on every save and never echoed back to a screen. A colleague gaining access to a mailbox connects it or is given workspace access; nobody is handed a stored secret.

Somebody's own triage marks

Starred and deleted flags on threads and calls are a person's own view of their work. Priority is different — the engine reads threads.priority when it picks work, so correcting it changes behaviour rather than just re-sorting a list.

Approval history

It stays where it happened. Approvals are recorded against the person who gave them, and the decision log answers 'who released this' months later. A handover does not reassign the past.

Handing over to Connect, and back#

The same mechanics cover the other two directions. A person going on leave moves a scope from ask_before_send to autonomous for a channel and back afterwards; a person taking something away from Connect sets that contact to draft_only, which prepares replies and never asks, so the thread is visible without anybody having to keep refusing. Needs You drains by itself as each cause clears, so a queue left behind by a departing colleague shrinks as the problems are handled rather than needing to be reassigned item by item.

Questions#

Related#

• Hand a conversation to a colleague
• The reason on a follow-up
• The relationship summary
• The decision log
• Transfer and escalation
• Sessions