Начните с одного тестового сообщения боту и проследите его путь до карточки в CRM. Рабочая связка создаёт обращение, назначает ответственного и показывает переписку там, где менеджер ведёт клиента. Но одного удачного теста мало: повторное сообщение способно создать дубль, а ошибка передачи — оставить заявку только в боте. Ниже разберём, какие правила задать до подключения, как проверить связку на своих сценариях и что делать, если обращения теряются.
Что решить до подключения бота к CRM?
Сначала запишите, что человек делает в боте. Например, он выбирает услугу, задаёт вопрос и просит связаться с ним. Для каждого действия определите результат в CRM: создать новое обращение, добавить сообщение к существующему или передать диалог менеджеру. Без этого правила интеграция способна создавать отдельную сделку на каждую реплику.
Затем выберите место, где менеджер увидит заявку. Для сервисной компании это часто карточка клиента и сделка с понятным этапом: «Новое обращение», «Уточняем задачу», «Согласовали запись» или «Отказ». Названия этапов подберите по своей работе. Если в CRM уже есть воронка, сначала проверьте её: бот должен передавать обращение в нужный процесс, а не открывать параллельную очередь, которую никто не смотрит.
Отдельно назначьте ответственного за входящие обращения. Если менеджеров несколько, запишите правило распределения и замену на случай отсутствия сотрудника. У карточки должна появляться задача с понятным действием: ответить в чате, позвонить после согласия клиента или уточнить детали услуги. Тогда заявку видно и в переписке, и в списке работы на день.
Если компания принимает сообщения ещё и в других каналах, полезно заранее решить, как связать мессенджеры с CRM. Это поможет не заводить отдельный порядок работы для каждого чата.
Как передавать сообщения, чтобы не создавать дубли?
Задайте интеграции правило поиска существующего обращения. Первое сообщение из чата создаёт карточку. Следующие сообщения из того же чата добавляются к ней, пока обращение открыто. Когда менеджер закрыл вопрос, новое сообщение можно направить в новую сделку или вернуть в прежнюю — выбор зависит от того, как вы считаете повторные запросы. Главное, чтобы правило было записано и одинаково работало у всей команды.
Для технической проверки интеграции пригодятся идентификатор бота, идентификатор чата и идентификатор сообщения. По ним можно отличить новое событие от повторной передачи того же события. Имя пользователя для такой проверки ненадёжно: оно может измениться. Если человек обратится через другой канал, не объединяйте карточки автоматически только потому, что имена похожи. Пусть менеджер проверит, один ли это клиент.
В тексте карточки сохраняйте смысл обращения. Менеджеру нужна исходная формулировка вопроса, выбранная услуга и время поступления сообщения. Запись «Новый лид из Telegram» без вопроса заставит его снова расспрашивать клиента. Если бот предлагает кнопки, передавайте в CRM и выбор клиента: например, «Ремонт» или «Запись на консультацию».
| Ситуация | Что должно произойти в CRM | Что проверить |
|---|---|---|
| Первое сообщение в боте | Появляется одно обращение с текстом вопроса | Карточка видна ответственному |
| Следующее сообщение из того же чата | Переписка дополняет открытое обращение | Новая сделка не появляется |
| Повторная передача одного события | Система не добавляет копию сообщения | В истории нет одинаковых записей |
| Новое обращение после закрытия прежнего | Срабатывает выбранное вами правило повторных запросов | Менеджер видит прошлую историю |
Такую схему можно настроить через штатное подключение CRM или через промежуточный сервис. Выбирайте способ после проверки нужных действий: передаёт ли он текст и выбор кнопок, обновляет ли существующую карточку, показывает ли ошибку передачи. Красивый список доступных интеграций здесь менее полезен, чем один полный тестовый диалог.
Как проверить, что обращения не теряются?
Проведите тест с отдельного аккаунта Telegram, которым не пользуется менеджер. Отправьте вопрос боту и откройте CRM. Проверьте карточку, текст сообщения, ответственного и задачу. Затем напишите ещё раз из того же чата: новая реплика должна попасть в историю обращения по вашему правилу. Ответьте клиенту из рабочего интерфейса, если связка это предусматривает, и убедитесь, что ответ появился в чате.
Следующий тест — сообщение в нерабочее время. Оно должно остаться в очереди до начала работы, а задача — попасть назначенному сотруднику. Затем проверьте вариант, когда клиент нажал кнопку бота, но не дописал вопрос. В CRM должно быть понятно, что именно он выбрал и нужно ли менеджеру уточнение.
Успешное появление карточки ещё не означает, что менеджер заметит обращение. Откройте CRM под его учётной записью и посмотрите, видит ли он задачу в обычном рабочем списке. Если уведомление есть только у владельца CRM, измените назначение ответственного и повторите тест.
Проверку на потери удобно проводить сверкой: откройте историю сообщений бота за выбранный рабочий день и сравните входящие диалоги с обращениями в CRM. Для каждого расхождения запишите время сообщения и его путь. Если диалог есть в боте, но отсутствует в CRM, проверяйте передачу события. Если карточка есть, но никто не ответил, смотрите назначение задачи и порядок работы менеджера. Это две разные неисправности, и исправлять их нужно в разных местах.
Какие ошибки чаще мешают работе связки?
Бот создаёт сделку на каждое сообщение. Задайте поиск открытого обращения по чату и проверьте повторную отправку одной реплики.
В CRM попадает только отметка «новый клиент». Добавьте передачу текста вопроса и выбора кнопок, затем повторите тест от лица клиента.
Обращение приходит без ответственного. Настройте правило назначения и проверьте карточку под учётной записью менеджера.
После ошибки передачи никто не узнаёт о пропавшей заявке. Определите, где видны ошибки интеграции и кто сверяет их с входящими сообщениями.
Начните проверку прямо сейчас: отправьте боту одно сообщение с вопросом об услуге и найдите его текст в CRM. Если карточки нет или в ней не хватает вопроса, у вас уже есть конкретное место, с которого начать настройку.
