Интеграция сайта с KeyCRM

Почта не показывает, что произошло с заявкой дальше. В карточке видно, кто взял обращение, когда ответил и чем оно закончилось; в письме этого нет и не будет. Вторая причина — источник: в письме нет ни страницы, ни кампании, а в карточке они лежат, и через месяц вы видите, откуда пришли купившие. Третья — тишина: не дошедшее письмо никого не беспокоит, пока клиент не напомнит о себе сам. Мы не обещаем, что после интеграции обращений станет больше. Обещаем, что они будут видны.

Заявка не должна исчезнуть — это главное требование интеграции, и именно поэтому передача устроена в два шага. Сначала обращение записывается в базу самого сайта и человеку показывается благодарность. Далее фоновая задачка отдает его в CRM и, если система молчит, повторяет пробы с нарастающей паузой. Каждая передача несет идемпотентный ключ, поэтому повтор не создает вторую карту. Параллельно менеджеру идет уведомление в Telegram: в открывшемся окне между попытками он уже знает об обращении, хотя в системе его еще нет.

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

Можно и это заметно разгружает поддержку: большинство обращений «где мой заказ» закрываются до того, как их поставят. Технически это приемник вебхуков с проверкой источника и идемпотентностью — повторная доставка того же сообщения не должна менять заказ дважды. Сложность здесь не в коде, а в договоренности: внутренние статусы воронки покупателю показывать не стоит, поэтому сперва согласовываем краткий перечень того, что он увидит, и только потом включаем поток.

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

4–14 рабочих дней после разбора потока; сам разбор занимает 2-3 дня, он бесплатный и в этот срок не входит. Нижняя граница – одна-две формы сайта, маппинг полей и проверка на живой заявке. Верхняя – когда добавляются заказы магазина, возведение дублей и обратный поток статусов. Этапы частично идут параллельно, поэтому 14 дней – это календарный срок, а не сумма максимумов по каждому пункту.

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

Нет. Сначала решение, затем передача данных: переносить настроенные воронки и маппинг между системами дороже, чем сделать один раз. Что следует сделать уже сейчас — добавить на сайт передачу метки источника в заявку и начать ее хранить. Это поле дешевое на этапе разработки и невосстановимое задним числом: через полгода вы не узнаете, с какой страницы пришли купившие. Разбор потока тоже не пропадет – схема нужна вам независимо от того, какую систему вы выберете.