# Handoff overview

> How the assistant hands a conversation to your team, which targets it can use and how routing chooses between live chat and offline delivery.

Source: https://shopassist.coec.dk/docs/handoff/overview · Updated 2026-10-01

A handoff passes a conversation from the AI assistant to a person on your team. It happens when the shopper asks for a person, when the assistant cannot help (for example after repeated failed answers), when a shopper requests an action the assistant may not perform itself, or when your guardrails require it.

[Open handoff settings](/app/go/handoff)

## Live or offline [#routing]

Every handoff takes one of two routes:

* **Live:** the conversation waits in your [live inbox](/docs/handoff/live-inbox-and-takeover) until an agent takes over. Live chat is used only when it is switched on, your plan includes the live inbox, [office hours](/docs/handoff/office-hours) are open **and** at least one agent is online.
* **Offline:** the conversation, an AI-generated summary and the transcript are delivered to the first matching target in your list (email or a helpdesk). The shopper is told that your team will reply by email, and the assistant keeps helping in the meantime.

If nobody takes a live chat within the maximum wait (30–900 seconds, set under **Handoff → Routing**), the handoff moves to the next offline target automatically.

## Targets [#targets]

You order the targets under **Handoff → Routing**. Shopper-facing targets can be offered in the widget; notification targets only tell your team.

| Target                                                                                                   | Kind                     | Plan              |
| -------------------------------------------------------------------------------------------------------- | ------------------------ | ----------------- |
| [Live inbox](/docs/handoff/live-inbox-and-takeover)                                                      | shopper-facing (live)    |  *(Starter and up)*               |
| [Email](/docs/handoff/email)                                                                             | shopper-facing (offline) | every plan        |
| [Zendesk](/docs/handoff/zendesk), [Gorgias](/docs/handoff/gorgias), [Freshdesk](/docs/handoff/freshdesk) | shopper-facing (offline) |  *(Growth and up)*               |
| [PrestaShop Customer Service](/docs/handoff/prestashop-customer-service)                                 | shopper-facing (offline) | PrestaShop stores |
| [Slack](/docs/handoff/slack)                                                                             | notification only        |  *(Starter and up)*               |
| [Webhook](/docs/handoff/webhook)                                                                         | notification only        |  *(Growth and up)*               |

Targets that your plan does not include, whose integration is not connected, or (for email) that have no verified recipient are skipped. If no shopper-facing target is left, ShopAssist falls back to emailing the store's owners and admins, so a handoff is never lost.

## What your team receives [#payload]

Every offline delivery contains, in this order:

1. A warning line **"Email NOT verified — verify before disclosing or changing account/order data"** whenever the shopper's email is not verified.
2. The identity line ("Identity: Guest / Order verified / Signed in · Email verified: yes or no") and, for signed-in customers, the customer id from your platform.
3. "This conversation includes AI-generated messages (ShopAssist)."
4. The reason, the shopper's message, an **AI-generated summary** (labelled as such), order numbers named in the chat, the last 50 messages of the transcript and a link to the conversation in your dashboard.

Helpdesk tickets are tagged `shopassist`, `shopassist_handoff`, `shopassist_ai`, `reason_<reason>`, `lang_<language>`, `identity_<level>` and, when the email is not verified, `shopassist_unverified`.

> **Always check identity before changing orders:** A typed email is not proof of identity. Only treat a request as coming from the account holder when the delivery says
> **Email verified: yes** or the shopper is signed in.

## Escalation settings [#escalation]

* **After failed answers:** offer a handoff after 1–5 answers the assistant could not give.
* **On action requests:** hand off when a shopper asks for something the assistant may not do itself (for example a cancellation outside your policy).
* **Require email for guests:** for offline handoffs, guests must leave an email before the handoff is sent.
* **Share notice:** the text shoppers confirm before their conversation is shared with your team (up to 300 characters per language). The shopper must agree to it; the consent is recorded.

## Test conversations [#test]

Handoffs from the [playground](/docs/assistant/playground) and test links are dry runs: nothing is sent to your helpdesk or email, and the conversation shows what would have happened.