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