Reference · built on requestOperator by FibricCustomer support

Bot Handoff

Reads chatbot sessions that stalled or looped and who is free to take them. Proposes a handoff with the session summary attached.

Request accessPricing ↗

About

A chatbot that cannot answer keeps asking. The customer repeats the question, the bot repeats the fallback, and the session ends with no agent involved. Bot Handoff watches chat sessions for that shape: repeated fallback intents, the same question asked again, a request for a person, or silence after a prompt. It also watches who is free: agents online and available in the contact center or the chat tool, and who is rostered.

When a session stalls, it proposes a handoff to a named agent or queue with a summary of what the customer asked and what the bot answered. A lead approves. The transfer happens once, the summary travels as an internal note, and the record shows why the bot lost the session.

This is a reference listing. It documents what Fibric would read from Bot Handoff and what it could propose, based on the vendor's published interfaces. Fibric builds it under a managed deployment when you request it; selecting it here installs nothing.

Inputs

  • Bot sessions in Amazon Connect chat where the Lex bot matched AMAZON.FallbackIntent, and the ConversationAbandon flag on the contact record
  • Chats in LiveChat and their threads, with each event's visibility, so repeated questions and unanswered prompts are visible
  • Conversations in Intercom and Chatwoot with their parts and messages, including who last spoke and when
  • Agents available and online per queue through GetCurrentMetricData, or the candidates LiveChat returns from list_agents_for_transfer with total_active_chats
  • Rostered shifts in Deputy or When I Work, so a handoff is not proposed to someone whose shift has ended
  • The customer record in Kustomer, so the summary names the order or case the bot could not find

Proposed actions

  • Target capability: propose a handoff to a named agent or a queue, with the session summary as an internal note
  • Target capability: propose the transfer itself once approved, through the chat tool's transfer or assignment call
  • Target capability: propose a callback or an email follow-up when no agent is available inside the customer's wait
  • Target capability: propose closing a session the customer has left, with the reason and the summary recorded
  • Target capability: propose a tag on the conversation naming the loop cause, so bot gaps can be counted later

Proposed actions are target capabilities. Every action runs propose-first and needs a validated deployment and the appropriate permissions.

What you can build

  • Hand a looping Connect chat to a person

    The Lex bot has matched AMAZON.FallbackIntent again and an agent is available on the queue. The operator proposes transfer to that queue with a summary note; the lead approves and the transfer carries transcript and attributes.

    With Amazon Connect

  • Pick the least-loaded agent in LiveChat

    The operator reads list_agents_for_transfer, proposes the agent with the fewest active chats, and attaches the summary as an agents-only event before transfer_chat runs.

    With LiveChat

  • Assign a stalled Intercom conversation with context

    A customer asked the same question twice with no answer. The operator proposes assignment to a team through the manage conversation call, with a note summarizing the exchange, and links the Kustomer record.

    With Intercom, Kustomer

  • Offer a callback when nobody is free

    It is after the last rostered shift in Deputy. The operator proposes a Chatwoot message offering a callback the next morning rather than a transfer to an empty queue.

    With Deputy, Chatwoot

Requirements

  • A chat or contact center connector with sessions and transfer calls: Amazon Connect, LiveChat, Intercom, or Chatwoot
  • Agent availability from the same tool or from Genesys Cloud
  • A scheduling connector for shifts: Deputy or When I Work
  • A support connector so the summary can name the customer's case: Kustomer, Zendesk, or Gorgias
Authentication
Runs on the credentials of the chat, contact center, and scheduling connectors you attach. It holds no key of its own and transfers nothing unapproved.

Limits

  • It sees a stall only through the events the chat tool exposes. A bot that swallows fallbacks without recording them hides the loop
  • In Amazon Connect the transfer keeps the transcript and attributes; in other tools the summary note is what carries context
  • LiveChat transfer_chat needs the requester on the chat or ignore_requester_presence set, and enqueues only with ignore_agents_availability
  • It does not change the bot. Loop causes are recorded for the people who maintain it

Access and pricing

Reference listing. Fibric builds the operator under a managed deployment when you request it. Your quote covers the build, capabilities, usage, and support.

Request Bot Handoff ↗

Questions and answers

What does a lead approve?
Each handoff: the session, the reason it stalled, the summary the agent will see, and the proposed agent or queue. The lead can change the target or discard the proposal. Approval triggers one transfer. Before that the customer stays with the bot.
What does the receiving agent see?
The summary as an internal note: what the customer asked, what the bot answered, how many times the fallback fired, and the customer record if one matched. In Amazon Connect the chat transcript and contact attributes travel with the transfer as well.
Does it transfer a chat without asking?
No. Every transfer starts as a proposal that a person approves. A transfer is made once and the record keeps the session id, the target, who approved, and the loop cause. If the customer leaves before approval, the proposal is withdrawn and the session is marked abandoned.
Ask about Bot Handoff

Ask about the capabilities and requirements in this listing.

For project-specific requirements, contact Fibric.

This operator is developed, published, and supported by Fibric. Third-party names and logos identify the systems an integration connects to; they are the property of their respective owners, who are not affiliated with Fibric and do not sponsor or endorse this listing. Trademark policy