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