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