Почему бот в Битрикс24 отвечает мимо сделки — и как это чинится

Как выглядит ответ мимо сделки

Узнаётся он по трём симптомам: агент здоровается с человеком, который переписывается с вами третью неделю, спрашивает то, что уже спрашивали, и предлагает то, что клиент только что купил. Каждый симптом сам по себе выглядит мелкой неловкостью, а вместе они читаются однозначно: с той стороны никто не помнит разговора.

Формально бот отработал правильно: на вход ему пришла фраза «по моему заказу что-то слышно», ни номера, ни имени в ней нет, и по этой фразе он честно попросил уточнений. Ошибка не в ответе, а в том, что он видел. Клиент в этот момент — человек с оплаченным заказом и открытой сделкой на портале, и оба факта лежали в двух шагах от диалога. Дальше — три причины, по которым они туда не доехали, в порядке от самой частой.

Причина 1: что значит «агент не видит историю диалога»

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

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

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

Причина 2: почему агент не знает, что клиент уже в сделке

Потому что переписка и CRM — два разных источника, и второй нужно собирать отдельно: в тексте чата нигде не написано, что у этого человека есть открытая сделка и на какой она стадии. Полная история диалога от этого не спасает — в ней есть всё, что клиент сказал, и ничего из того, что о нём знает портал.

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

Важная оговорка: сборка данных из CRM работает в режиме AI-оператора. Чат-бот портала получает от линии только идентификаторы сущностей — по ним заявку записывают обратно в CRM, но ни стадии сделки, ни суммы, ни имени клиента в его ответ не попадает. Отсюда вывод раздела: у бота эта причина лечится не формулировками, а переходом в режим оператора — чем режимы отличаются.

Отдельный случай — диалог, не привязанный ни к какой сущности CRM: человек пишет впервые, сделки и лида ещё нет. Такой случай обрабатывается явно, а не считается ошибкой: собирать нечего, агент ведёт разговор как новое обращение и складывает названные клиентом параметры в карточку заявки. Плохо не отсутствие сделки, а притворство: агент не должен ссылаться на историю покупок, которой у него нет.

Причина 3: почему один сценарий не годится и новым, и текущим клиентам

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

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

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

Как проверить, что контекст доехал

Проверяется это одним пробным диалогом с тестового аккаунта — не глазами по настройкам, а перепиской, в которой вы заранее знаете правильный ответ. Заведите на портале контакт с открытой сделкой, напишите от его имени в подключённую линию и пройдите шесть пунктов подряд.

• Память на параметр. Назовите что-то конкретное в первом сообщении — город, услугу, дату, — а во втором спросите о другом. Агент, который переспросил названное, историю не получил.
• Одно приветствие. Здоровается ли агент повторно посреди разговора. Второе «здравствуйте» в том же диалоге — тот же симптом, что и первый пункт.
• Узнавание клиента. Спросите о статусе заказа, не называя номер. Ответ должен опираться на найденную сделку; предложение познакомиться и рассказать о компании означает, что данные из CRM в разговор не попали.
• Обратный случай. Тот же вопрос от нового контакта без сделок. Правильный ответ — уточняющий вопрос; ссылка на несуществующий заказ хуже, чем «уточните номер».
• Факты из базы знаний. Спросите про условие, которое в базе описано, и сверьте ответ дословно. Потом спросите про то, чего в ней нет: агент должен сказать, что уточнит, а не сочинить ответ.
• Границы памяти. Напишите тем же клиентом в другой канал. История туда не переедет — убедитесь, что вас это устраивает, и решите, что агент говорит в такой ситуации.

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

И один вопрос, который лучше закрыть до запуска, а не после: что из карточки клиента вообще уходит во внешнюю модель и на каком основании. Разбор — в статье персональные данные и языковые модели.