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