Связка сайт — CRM — мессенджер: как выглядит рабочая схема

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

Что ломается в схеме «форма шлёт всё сразу»

Самый частый вариант интеграции: форма на сайте по нажатию кнопки дёргает CRM, а параллельно шлёт сообщение в чат. Работает, пока всё работает.

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

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

Третий эффект вылезает позже. Когда данные живут только в CRM, сайт перестаёт что-либо знать о клиенте: не показать статус, не подставить прошлый адрес, не отличить нового от повторного.

Кто здесь источник истины

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

Для заявок и заказов мы делаем источником истины базу на стороне сайта. Причина простая: сайт — единственное звено, которое вы контролируете целиком, и единственное, куда данные попадают первыми.

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

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

Как выглядит путь одной заявки

Опишу маршрут по шагам, как он реально устроен в коде.

1. Посетитель отправляет форму. Сервер проверяет поля, отсекает ботов, создаёт запись в базе со статусом «новая» и своим номером.
2. Пользователю сразу отдаётся ответ: заявка принята, номер такой-то. Ничего внешнего к этому моменту ещё не вызывалось.
3. В очередь ставятся две задачи: отправить заявку в CRM и отправить уведомление в мессенджер.
4. Фоновый обработчик берёт задачу на CRM. Успех — в базе появляется идентификатор сделки. Ошибка — задача возвращается в очередь с задержкой.
5. Вторая задача шлёт в рабочий чат три строки: имя, телефон, что человек хотел, и ссылку на карточку заявки.
6. Менеджер открывает ссылку и работает в системе, а не в переписке.

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

Почему уведомление не должно быть каналом данных

Соблазн понятный: раз сообщение всё равно летит в телеграм, давайте положим в него всё — состав заказа, комментарий, адрес, сумму. Менеджер прочитает и сделает.

Так возникает работа из чата. Сообщение прокручивается вверх, теряется среди других, копируется в личку, отвечает на него тот, кто первым увидел. Через месяц никто не может сказать, сколько заявок было на прошлой неделе.

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

Обратный случай тоже бывает полезен: кнопки прямо в сообщении. «Взял в работу», «Перезвонить завтра». Нажатие меняет статус в базе, а не отправляет ещё одно сообщение. Это уже не переписка, а интерфейс.

Где связка нужна не вся

Не каждому бизнесу нужны все три звена. Если заявок несколько в день и обрабатывает их один человек, CRM добавит работы, а не уберёт: карточки, воронки, поля, которые кто-то должен заполнять.

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

CRM оправдана, когда появляется второй и третий менеджер, длинный цикл сделки с несколькими касаниями, или когда нужно понимать, на каком шаге отваливаются клиенты. До этого момента расходы на подписку и на дисциплину заполнения выше отдачи.

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

Что спросить у разработчика до старта

Три вопроса, ответы на которые определяют, будет схема живой или нет.

Что происходит с заявкой, если CRM не ответила. Ответ «повторим из очереди» — рабочий, ответ «такого не бывает» — нет.

Где хранится история и кому она принадлежит. Данные должны лежать на вашем хостинге, а доступы — быть оформлены на вас.

Как обмен ведёт себя при дубле. Клиент нажал кнопку дважды, менеджер создал сделку руками — система должна опознать повтор по номеру заявки, а не создать вторую.

Что держать у себя, даже если CRM умеет всё

Есть данные, которые должны лежать в вашей базе независимо от того, насколько хороша выбранная CRM.

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

Идентификатор клиента и связь заявок между собой. Без этого повторное обращение выглядит как новый человек, и вы не увидите, что половина продаж — это возвраты старых клиентов.

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

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

Коротко

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