> ## Documentation Index
> Fetch the complete documentation index at: https://docs.callkaro.ai/llms.txt
> Use this file to discover all available pages before exploring further.
# Human Handoff
> How a chat reaches a teammate, who gets it, what they can send, and how it goes back to the bot
When a flow reaches a **Handoff to a person** card, the bot stops answering and
a person on your team owns the conversation. This page is what happens in
between.
Where handed-off conversations are answered.
***
## Being Available
Two separate things have to be true before anyone is handed a chat:
1. **They are online** — a CallKaro dashboard is open. Detected automatically,
and it lapses about two minutes after the last sign of life.
2. **They have said they are taking chats** — the **Available** toggle on the
Contacts dashboard.
Both are required, and deliberately so. Being online only means a browser tab is
open, which is not consent to be handed a customer. Being available without
being online means somebody opted in last Tuesday and went home.
An admin who marks themselves available is assigned chats like anyone else.
***
## Who Gets The Chat
The **least loaded** available person — whoever is currently holding the fewest
open conversations.
Least-load rather than a rotation, because a rotation hands the next chat to
whoever is next in line whether or not they are already juggling five. This
levels out on its own.
Each person holds at most **10** open chats. That cap is real: without it one
person quietly absorbs the whole queue and "assigned" stops meaning "somebody is
actually reading this".
If nobody qualifies — or you are **outside your business hours** — the
conversation goes down the [ticket path](/widget/chat/ticket-fallback) instead.
***
## Answering
The conversation appears in **Contacts** with an **assigned** badge, and a
composer under the transcript.
* The visitor sees your reply **immediately** — no refresh, on either side. The
same is true in reverse: what they type appears in your transcript as they
send it.
* Everything the flow collected is listed beside the transcript, plus the
**note** from the handoff card.
* Every reply records **who** sent it, so a transcript shows the bot's messages
and each teammate's separately.
### What Each Side Can Send
| | The visitor | Your teammate |
| ---------------------- | ----------------------------- | ------------------------- |
| Text | yes | yes |
| Image, video, document | yes | yes |
| Voice note | yes — records in the composer | yes — records in Contacts |
Limits on what a visitor can upload are on the
[introduction page](/widget/chat/introduction#limits-worth-designing-around).
Voice notes are recorded in whatever format the sender's browser produces —
WebM on Chrome, Firefox and Android, MP4 on iOS Safari. Both play on the other
side.
### Replying On Another Channel
If the contact is reachable on more than one channel, the composer lets you
choose which one to reply on. It defaults to the channel the **last message**
arrived on, which is almost always what you want — answering a widget chat on
WhatsApp because that is what the picker happened to be set to is a real way to
confuse somebody.
### Translation
The transcript can be translated in your browser, so a teammate can read and
reply across a language barrier. It runs **on the device** — nothing is sent to
a translation service — and only languages your browser actually supports are
offered.
***
## Private Notes And Events
The timeline carries two things the visitor never sees:
Written by a teammate, for the team. Context for whoever picks the
conversation up next.
Written by the system: transferred to a person, ticket raised, ticket
failed, chat ended.
Both are stored separately from the conversation itself, which is what keeps
them out of the visitor's transcript and out of their conversation list. A
visitor replaying an old chat sees only what was actually said to them.
***
## Ending It
**End chat** on the conversation hands the visitor back.
* If the handoff card has an exit wired, the visitor lands on that card and the
bot carries on from there — a good place for "Anything else?".
* If it does not, the visitor gets your account's **end-of-chat message** and the
conversation closes.
Those two are exclusive. A wired exit means the flow author has already said what
happens next, so the account's end message is not used as well — two closing
messages is one too many. Set that message under
[Chat routing](/widget/chat/chat-routing#4-when-a-chat-ends).
Either way the assignment is released, an event is written to the timeline, and
the person's capacity frees up.
There is **no** automatic return to the queue. A conversation nobody replies to
stays assigned until someone ends it — or until the unanswered timer trips and
raises a ticket, if you have configured one. Ending a chat you cannot get to is
what puts it back in reach of the rest of the team.
That timer is off by default — set it under
[Chat routing](/widget/chat/chat-routing#3-if-nobody-replies).
***
## What This Does Not Do Yet
Worth knowing before you design a process around it:
* **No routing to a team, a skill or a priority.** A handoff goes to the whole
account. You cannot send fraud cases to one group and billing to another.
* **No transfer between teammates.** A conversation can be ended, not passed on.
* **No idle timeout** on the visitor's side.
* **No CSAT prompt** when a chat closes.
If you need any of these, say so — they are on the list, and knowing which one
you need decides the order.
***
## Next Steps
Your own Python, run at handoff time
Business hours, and what visitors are told