Как провести интеграцию CRM с сайтом и телефонией: схема и таблица полей

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

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

Разбирать такие случаи мне приходится регулярно, и почти всегда одна причина: поля согласовали на словах.

Я за 17 лет в корпоративном ИТ привыкла смотреть на любую интеграцию со стороны данных, потому что именно данные ломаются первыми, код при этом исправно работает и рапортует об успехе.

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

Что значит "провести интеграцию" на самом деле

Под интеграцией обычно понимают техническое подключение: сайт дёргает API CRM, телефония шлёт события о звонках, вроде бы всё.

На практике интеграция это договорённость трёх систем о том, как выглядит один и тот же клиент, и только потом обмен сообщениями, который эту договорённость исполняет.

Если договорённости нет, обмен честно переносит мусор, и CRM становится местом, где лежат обрывки клиентов.

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

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

Порядок работы: от полей к коду

Правильный порядок простой: сначала таблица полей, потом формат обмена, потом код, потом каналы.

Формат обмена выбирают из трёх вариантов, и выбор зависит от скорости передачи данных: вебхук, когда сайт или телефония сами сообщают о событии в момент его появления; запрос по API по расписанию, когда достаточно догонять данные раз в несколько минут; двусторонняя синхронизация, когда CRM и канал пишут друг в друга, и это самый дорогой и самый опасный вариант, потому что писателей у поля становится двое.

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

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

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

Где теряются данные при интеграции

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

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

Четвёртый стык: клиент заводится второй раз, потому что его ищут по телефону.

Отдельно про источник заявки. Поле "откуда пришёл клиент" теряется первым, потому что оно нужно маркетингу, которому всё равно, а продаёт менеджер, которому некогда.

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

Кто владеет полем: правило одного источника

У каждого поля должен быть один владелец, то есть одна система, которая имеет право его писать, а остальные только читают.

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

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

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

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

Таблица полей для проверки обмена

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

Проверка запущенной интеграции по ней занимает один вечер: берёте живую заявку, живой звонок и идёте по строкам.

1. Поле: название поля так, как оно зовётся в CRM, например "Телефон мобильный".
2. Источник: какая система рождает значение, сайт, телефония, менеджер, справочник.
3. Получатель: кому поле передаётся, и в каком виде оно там называется.
4. Формат: тип и маска значения, например телефон в десятизначном виде без восьмёрки.
5. Обязательность: что делает система, если поле пустое, отказ, пропуск, подстановка значения по умолчанию.
6. Ключ сопоставления: участвует ли поле в поиске существующего клиента, да или нет.
7. Владелец: единственная система, которая пишет поле, все остальные читают.
8. Когда передаётся: сразу по событию, по расписанию, вручную при создании.
9. Куда пишется при ошибке: журнал, письмо ответственному, молча в никуда.

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

Заполненная таблица сама превращается в техзадание, и именно с неё мы начинаем проекты по связке CRM с каналами, потому что без неё проект разваливается на этапе приёмки, когда выясняется, что каждый понимал "интеграцию" по-своему.

Если хотите, чтобы такую таблицу и обмен по ней собрали под вас, посмотрите, как это устроено у нас: интеграция CRM.

Частые вопросы по интеграции CRM

Можно ли подключить телефонию раньше сайта?

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

Что делать с пропущенными звонками?

Клиент, которому не перезвонили в течение получаса, чаще всего уже разговаривает с конкурентом, поэтому статус "пропущенный" из телефонии должен долетать в CRM мгновенно.

Как передавать записи разговоров?

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

Нужна ли двусторонняя синхронизация?

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

Что проверить сегодня же

Оставьте тестовую заявку с сайта с пометкой в имени и позвоните на второй рабочий номер: у вас в карточке должен собраться один клиент с заявкой, звонком и записью. Откройте журнал обмена за последнюю неделю и посмотрите, были ли ошибки передачи, о которых никто не узнал. Спросите у маркетинга, видят ли они источник по каждой заявке за месяц. Три проверки, вечер времени, и вы знаете, собрана ли у вас интеграция или данные по-прежнему падают между стыками. Что показала проверка у вас: где потерялись данные? " name="body" не задавайте. Напишите в комментариях, какой стык подвёл первым.

Новые разборы выходят в моём канале: t.me/promaren.