Заявки с сайта в CRM: зачем связывать

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

Список заявок - это ещё не учёт

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

• Статус. Новая, в работе, ждём клиента, закрыта, отказ. Пока статуса нет, «обработана» существует только в чьей-то голове, и проверить это невозможно.
• Ответственный. У заявки есть имя человека, который за неё отвечает. Заявка без ответственного - ничья, а ничью заявку берут в последнюю очередь.
• История касаний. Кто звонил, что ответили, какой счёт выставили, когда клиент попросил перезвонить. История лежит рядом с заявкой, а не в чужой переписке.
• Поиск. Человек звонит и называет телефон - видно, что он уже писал с сайта неделю назад и что ему обещали.
• Повторные обращения. Новая заявка цепляется к существующему контакту, а не создаёт вид, что клиент пришёл впервые.
• Причина отказа. Дорого, не тот район, передумал, не дозвонились. Без этого поля разговор о том, почему заявки не превращаются в заказы, остаётся разговором о догадках.
• Напоминания. «Перезвонить в четверг» живёт в системе, а не в стикере на мониторе.

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

Telegram и CRM решают разные задачи

В работе с автомойкой сайт и чат-бот-виджет делали одним заказом и собрали примерно за неделю. Заявки с формы и из бота идут в CRM и в Telegram одновременно. Это не перестраховка ради перестраховки, у каналов разные роли.

• Telegram - скорость. Телефон в кармане, заявка видна сразу, ответить можно в ту же минуту. Но у сообщения нет состояния: прочитано не значит обработано, а в длинной ленте старую заявку уже не найти. Отметить «взял в работу» тоже негде.
• CRM - память и порядок. Реагирует медленнее, зато отвечает на вопрос «что сейчас с этим клиентом» и «что с ним было раньше».
• Второй канал - страховка. Если система учёта недоступна или у неё сменился ключ доступа, владелец всё равно увидит заявку в Telegram и не потеряет клиента, пока связка чинится.

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

Какие поля передавать

Минимальный набор

• Имя и контакт в том виде, как их ввёл человек, без «улучшений» и автоисправлений. Нормализовать номер можно рядом, отдельным полем.
• Текст обращения целиком. Обрезка «для красоты» в карточке потом стоит звонка с уточнением.
• Время приёма по серверу. Время браузера зависит от настроек устройства и в спорной ситуации ничего не доказывает.
• Полный адрес страницы, с которой отправлено. Не «главная», а конкретный URL.
• Источник и канал: форма на странице услуги, виджет бота на сайте, Telegram-бот, обратный звонок.
• Собственный идентификатор заявки - тот же, что записан у нас на сайте. По нему потом сходятся логи, CRM и уведомление.
• Метки кампании, если реклама есть.
• Отметка согласия на обработку данных с временем.
• Служебное: признак прохождения антиспам-проверки, версия формы. Помогает разбирать странные заявки.

Правило одно: в CRM уезжает то, что уже сохранено на нашей стороне. Если поле не записано у себя, при сбое восстанавливать его будет неоткуда.

Зачем помечать источник

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

• Разные каналы требуют разного ответа. Из формы человек ждёт звонка. Из бота - продолжения переписки там же, где начал, и звонок его скорее собьёт.
• Спорная заявка. Видно, какую страницу человек читал и какое условие он там видел.
• Изменения на сайте. Переписали страницу услуги или отключили рекламу - по источнику видно, что именно изменилось в потоке, без гаданий.
• Дедупликация. Одно обращение, пришедшее из формы и из бота, и два разных обращения от одного человека - это разные ситуации, и различить их можно только по источнику и идентификатору.

Если CRM ещё нет

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

• Таблица. Столбцы: дата, источник, контакт, суть, статус, ответственный, следующий шаг и его дата. Форма пишет строку сама, руками остаётся только статус. Это уже учёт, и он честно показывает, готова ли команда вести статусы вообще.
• Своя админка. Когда процесс не влезает в чужие поля, разумнее хранить заявки у себя. В собственном проекте krug.by сайт, бот и мини-приложение сделаны нами целиком, и админка встроена в саму систему, а не приделана сбоку. Такой путь оправдан, если у заявки свой жизненный цикл, а не стандартная воронка.

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

Где связка ломается

Дубли

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

Потеря, когда CRM недоступна

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

Нет очереди повторов

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

Молчаливый отказ

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

Мусор вместо заявок

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

Как сделать передачу устойчивой

Схема, которую мы применяем, простая и повторяется от проекта к проекту.

• Приём. Заявка сохраняется на нашей стороне первым действием, до всякой отправки наружу.
• Ответ человеку. Подтверждение показывается сразу и не зависит от того, ответила CRM или нет.
• Очередь. Отправка во внешние системы идёт отдельным шагом, а не в момент нажатия кнопки.
• Идемпотентность. У каждой заявки свой идентификатор, повтор с тем же идентификатором не плодит карточки.
• Повторы. Неудачная попытка возвращается в очередь с нарастающей паузой.
• Тупик обрабатывается явно. Попытки исчерпаны - заявка помечается как непереданная, ответственному приходит уведомление, в админке есть кнопка «отправить снова».
• Лог. Каждая попытка записывается: время, код ответа, тело ответа. Без этого разбор инцидента превращается в гадание.
• Дублирующий канал. Уведомление в Telegram уходит независимо от CRM.

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

Что проверить

Проверять нужно не то, что заявка «дошла один раз», а поведение связки в плохие моменты. Список действий, который стоит пройти перед запуском и повторить через неделю после.

• Отправить тестовую заявку с телефона и с компьютера. Найти её в CRM поиском по имени и по номеру, а не глазами в общем списке.
• Проверить, что источник, страница и время заполнены, а не пустые. Пустое поле источника после запуска уже не восстановить.
• Нажать кнопку отправки дважды подряд. В системе учёта должна остаться одна карточка.
• Намеренно сломать доступ к CRM тестовым ключом и отправить заявку. Она обязана сохраниться на сайте и уйти в Telegram.
• Вернуть рабочий ключ и убедиться, что отложенная заявка доехала сама, без ручного вмешательства.
• Открыть лог и убедиться, что видны попытки и коды ответов, а не одна строка «ошибка».
• Проверить, что при исчерпании попыток приходит уведомление человеку, а не только запись в лог.
• Отправить заявку из виджета бота и с формы. В CRM они должны отличаться источником.
• Проверить содержимое: кириллица, длинный текст, эмодзи, номер в формате +375, вставка из буфера, пробелы по краям.
• Проверить спам-защиту: отправить форму быстро несколько раз подряд и посмотреть, что произойдёт.
• Убедиться, что у новой карточки есть ответственный по умолчанию и понятный статус.
• Посмотреть на заявку глазами того, кто её обрабатывает, и с того устройства, с которого он работает.
• Через неделю сверить два счётчика: сколько уведомлений пришло в Telegram и сколько карточек появилось в CRM. Расхождение - повод открыть лог.

Когда связывать сайт с CRM не нужно

Честный ответ: не всем. Есть ситуации, где интеграция добавляет работы и не снимает ни одной.

• Обращений столько, что владелец видит каждое и отвечает сам, а повторных нет. Тогда достаточно уведомления и таблицы, куда строка попадает автоматически.
• Нет процесса. Если не решено, кто ставит статусы и что означает «в работе», CRM превратится в свалку карточек, и пользоваться ей перестанут. Сначала договорённость, потом интеграция.
• Разовая история: лендинг под одно событие, набор на поток, акция с конечной датой. Учёт после закрытия никому не понадобится.
• Сделка закрывается в одном разговоре, повторных обращений не бывает, история не нужна.
• CRM выбрана «потому что у всех», а работа фактически идёт в мессенджере. Честнее довести до ума приём заявок и уведомления, а систему учёта подключить, когда появится второй человек в команде.

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

С чего начать

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

Мы делаем такие связки вместе с сайтом и ботом, чтобы приём заявок был единым, а не собранным из трёх разных кусков. Условия обычные: разбор задачи бесплатный, предоплата 50%, три правки в рамках технического задания без доплаты. Если непонятно, нужна ли вообще система учёта в вашем случае, приходите обсудить задачу - иногда правильный ответ звучит как «пока хватит таблицы и нормальных уведомлений», и это тоже результат разбора.