Как передать диалог живому менеджеру из AI-бота без потери контекста

Классическая проблема чат-ботов — не в том, что они не понимают клиента, а в том, что происходит в момент, когда понимание заканчивается и нужен живой человек. Плохой сценарий известен всем: бот зацикливается на одном и том же ответе, клиент в раздражении пишет «дайте человека», а когда менеджер наконец подключается — просит клиента рассказать всё с начала, потому что не видел переписку. После такого клиент либо уходит, либо остаётся с испорченным впечатлением ещё до первого разговора с продавцом. Разберём, как эта передача устроена в AI-боте Cheat Code, чтобы этого не происходило.

Два способа понять, что клиенту нужен человек

Первый и самый очевидный триггер — прямой запрос. Если клиент пишет «менеджер», «оператор», «человек», «позови», «переключи» или похожие формулировки на русском или английском, бот распознаёт это как явный сигнал и запускает передачу немедленно, без попытки ещё раз ответить самостоятельно или уточнить вопрос.

Второй способ менее очевиден, но на практике встречается чаще прямого запроса: сам ИИ в процессе диалога может определить, что разговор дошёл до точки, где решение принимает не бот, а человек — например, клиент готов обсуждать конкретные условия и сроки и явно двигается к сделке. В этот момент бот не тянет диалог дальше искусственно, изображая, что может закрыть сделку сам, а сам инициирует передачу менеджеру, обозначив это отдельной пометкой в своём ответе, которую система распознаёт и обрабатывает как команду на переключение.

Это принципиальное отличие от ботов, которые передают диалог только по стоп-словам: система не ждёт, пока клиент догадается попросить человека, а сама следит за готовностью диалога к продаже.

Что происходит технически в момент переключения

Как только сработал любой из двух триггеров, происходит две вещи одновременно. Во-первых, статус диалога в системе меняется — он помечается как переданный менеджеру, чтобы в дашборде такие обращения было видно отдельно от тех, где бот всё ещё ведёт клиента по воронке самостоятельно. Во-вторых, менеджеру уходит уведомление с именем клиента и кратким описанием, на каком этапе находится разговор — не для того, чтобы менеджер потом сам разбирался в переписке с нуля, а чтобы он сразу понимал, кому и зачем звонить или писать.

Бот не замолкает — и это осознанное решение

Здесь легко ошибиться в дизайне такой системы: кажется логичным, что раз диалог передан человеку, бот должен остановиться и не мешать. На практике это создаёт худший из возможных сценариев — клиент попросил менеджера, но менеджер физически не может ответить мгновенно (не у монитора, занят другим клиентом, вне рабочего времени), и в итоге клиент упирается в тишину именно в тот момент, когда был максимально заинтересован.

Поэтому в архитектуре бота передача диалога менеджеру не отключает бота — он продолжает отвечать на вопросы клиента в обычном режиме, пока менеджер не подключится сам. Клиент не чувствует разницы в скорости ответа из-за того, что где-то в фоне уже запущено уведомление живому человеку — он просто получает ответы без пауз, а параллельно менеджер получает сигнал, что пора вмешаться.

Когда бот всё-таки замолкает

Бот перестаёт отвечать только в одном случае — когда менеджер сам написал клиенту в этот диалог хотя бы одно сообщение вручную, например, через дашборд. Это логичная точка передачи: раз человек уже включился в разговор напрямую, дальнейшие автоматические ответы от бота поверх живого менеджера создали бы путаницу — два разных голоса от имени одного бизнеса в одном чате. С этого момента диалог полностью в руках менеджера, и он может вести его как обычную переписку.

Как менеджер узнаёт о передаче, если он не смотрит в дашборд постоянно

Полагаться на то, что менеджер всё время держит открытым дашборд, нереалистично — поэтому уведомление о передаче диалога дублируется по двум независимым каналам: в WhatsApp менеджера и, если этот канал по какой-то причине недоступен, резервно в Telegram. Смысл в отказоустойчивости: единственная точка отказа (например, у менеджера временно не открывается WhatsApp Web) не должна означать, что клиент, готовый к разговору с человеком, просто повиснет без реакции на другой стороне.

Почему это важно не только для клиента, но и для бизнеса

С точки зрения клиента результат простой: он ни разу не должен пересказывать историю обращения заново — вся переписка с самого первого сообщения видна менеджеру в дашборде, включая то, что клиент писал боту до момента передачи. Не нужно переспрашивать «а что у вас за запрос», что само по себе резко улучшает впечатление от первого контакта с бизнесом.

С точки зрения бизнеса это означает, что автоматизация первой линии не создаёт разрыва в клиентском опыте в момент, когда сделка становится реальной, — а именно этот разрыв чаще всего убивает доверие к чат-ботам как классу инструментов. Бот берёт на себя объём и скорость первичной обработки обращений, но не пытается изображать способность закрыть сделку там, где нужен живой человек, и не создаёт для этого человека дополнительной работы по восстановлению контекста.

Ограничения подхода

Стоит быть честным: сама по себе технология передачи диалога не решает организационную часть — если у бизнеса физически нет человека, готового оперативно подключиться к переданным диалогам, даже мгновенное и точное уведомление не ускорит реакцию. Это инструмент маршрутизации и сохранения контекста, а не замена процесса продаж и не гарантия того, что менеджер ответит быстро. Чтобы передача диалога реально ускоряла закрытие сделок, а не просто аккуратно складывала их в очередь, на стороне бизнеса должен быть налажен процесс: кто отвечает за такие уведомления и в какие сроки на них принято реагировать.