Вернуться к статьям Покупатель оставил заявку на сайте, менеджер увидел её позже, а затем вручную перенёс телефон, состав заказа и комментарий в CRM. За это время клиент может оформить покупку повторно, изменить данные или получить разные ответы от сотрудников. После оплаты возникает другая проблема: сайт показывает один статус, сотрудник ориентируется на другой, а покупателю приходится уточнять состояние заказа.
Интеграция интернет-магазина с CRM задаёт маршрут для заявки или заказа: от действия посетителя на сайте до обработки сотрудником и обратного сообщения покупателю. Для этого разделяют зоны ответственности сайта и CRM, фиксируют состав передаваемых данных, права на изменение и порядок действий при ошибке обмена.
Какие объекты связывает интеграция интернет-магазина с CRM
Сайт на 1С-Битрикс: Управление сайтом ведёт пользовательский сценарий: каталог, карточки товаров, корзину, оформление заказа, формы и страницы для посетителей. CRM используют для обработки обращений, уточнения заказа и ведения коммуникации.
Интеграция не требует делать из двух систем одинаковые базы. Для каждого объекта проект определяет источник данных. Сайт может передавать состав оформленного заказа и контакты покупателя, а CRM — возвращать статус, разрешённый для показа в личном кабинете или сообщении. Если поле редактируют в обеих системах, заранее утверждают приоритет при расхождении.
Обычно в обмен включают:
- заявки из форм;
- заказы и позиции заказа;
- данные покупателей;
- товары, если они нужны сотрудникам для обработки заказа;
- статусы и служебные отметки;
- события оплаты или доставки, если они предусмотрены пользовательским сценарием.
Перечень строят вокруг действий, а не названий разделов. Заявка на обратный звонок и заказ из корзины могут попадать к разным сотрудникам, иметь разные обязательные поля и обрабатываться по разным правилам.
Передача заявок с форм сайта в CRM
Форма перестаёт быть простой, когда на сайте появляются запрос консультации, подбор товара, партнёрское обращение и вопрос по уже оформленному заказу. Если все они создают одинаковые записи, сотруднику приходится вручную определять тип обращения и искать контекст.
Владелец процесса утверждает для каждой формы состав полей и назначение заявки в CRM. Для обращения по заказу это может быть номер заказа, для подбора товара — категория или параметры, для сервисного запроса — идентификатор клиента либо выбранная тема. Имя, способ связи, текст обращения и страница отправки также включаются в обмен, если они нужны сотруднику для работы.
Отдельное правило требуется для повторной отправки. Оно относится к заявке и определяет, когда создаётся новая запись, а когда обращение связывается с существующей. Так предотвращают и лишние дубли после повторного нажатия кнопки, и ошибочное объединение обращений разных людей с одинаковыми данными.
Обмен заказами между сайтом и CRM
Заказ содержит не только сумму и список товаров. В сценарии проекта могут участвовать способ доставки, данные получателя, комментарий, способ оплаты, скидка, отмена или изменение состава после разговора с сотрудником. Если часть сведений остаётся только на сайте, сотрудник будет сверять заказ вручную.
До настройки обмена команда проходит путь от корзины до завершения обработки. На этом этапе фиксируют момент создания записи в CRM, порядок передачи неоплаченного заказа, допустимость изменения состава, место фиксации отмены и обработку неполных данных.
Правило сопоставления покупателя утверждают отдельно. Оно определяет, как система ищет существующую запись, когда создаёт новую и как поступает при нескольких совпадениях. Поиск только по телефону не покрывает ситуации с разными номерами и адресами у одного человека или с корпоративным заказом, где контакт сотрудника и данные организации относятся к разным объектам. Такая схема снижает риск связать заказ не с той карточкой.
Синхронизация статусов заказа и статусов CRM
Статус на сайте сообщает покупателю, что происходит с заказом. Статус в CRM отражает рабочий этап сотрудника. Эти цепочки редко совпадают: внутренние отметки о проверке данных или ожидании ответа могут быть нужны команде, но не подходят для личного кабинета.
Статусы сопоставляют по смыслу, а не по названию. Для каждого статуса владелец процесса утверждает направление обмена и результат: изменение приходит с сайта в CRM, возвращается на сайт или остаётся внутренним. Для отмены отдельно фиксируют, что увидят сотрудник и покупатель и при каких условиях обработка может быть возобновлена.
Порядок событий тоже входит в правила проекта. Если несколько действий произошли почти одновременно, устаревшее обновление не должно возвращать заказ на предыдущий этап. Для этого связывают события с идентификаторами обмена, задают порядок обработки и сохраняют сведения об ошибках.
Данные товаров, оплаты и доставки
Связь сайта с CRM нередко начинается с заявок и заказов, а затем в обмен добавляют справочные данные. Каталог, цены, остатки, оплата и доставка могут иметь разные источники и отдельные правила обновления, поэтому их не стоит объединять в один поток без описанного сценария.
Данные товаров передают, когда сотруднику нужен точный состав заказа без ручной сверки. Проект должен определить, что считается товаром в обмене: артикул, вариант, комплект, услуга, подарок или скидка. Если у товара есть варианты, одного названия позиции недостаточно для сопоставления.
Для оплаты и доставки описывают конкретные события: заказ создан, подтверждён, передан в доставку, частично отменён или возвращён. Каждому событию назначают действие в CRM и, при необходимости, сообщение для сайта. Это предотвращает ситуацию, когда внутренний этап случайно становится статусом для покупателя.
Ошибки обмена и контроль интеграции
Обмен может остановиться из-за недоступности одной из систем, изменённого формата данных, отсутствия обязательного поля или ошибки доступа. Без порядка контроля заявка или заказ могут остаться между сайтом и CRM без заметного сигнала для сотрудников.
В проекте назначают, где фиксируются неотправленные объекты, кто разбирает ошибку и как выполняется повторная передача. Это правило относится к конкретному объекту обмена и защищает от повторного создания заявки или заказа при перезапуске.
Техническая связь между объектами сайта и CRM помогает разбирать расхождения. В ней сохраняют идентификаторы, время и направление обмена, а также результат обработки. Отдельно проверяют неполные данные: пустой телефон, некорректный e-mail, товар без идентификатора, заказ без выбранного способа доставки.
Как выбрать схему интеграции сайта с CRM
Выбор начинается с карты процессов, а не с набора модулей. Для передачи обращений из нескольких форм описывают типы заявок, поля, ответственных и обработку повторной отправки. Для интернет-заказов добавляют схему статусов, правила сопоставления покупателей, состав заказа и сценарии исключений.
Перед началом работ полезно согласовать:
- какие объекты и поля передаются в каждом направлении;
- где создаётся объект и какая система хранит основную версию;
- как обрабатываются дубли, пустые поля и изменения после передачи;
- какие статусы видит покупатель, а какие остаются рабочими;
- что происходит при недоступности одной из систем;
- как проверяется обмен и где фиксируются ошибки.
Схема подходит проекту, если по каждому объекту можно отследить, где появились данные, кто изменил их и каким оказался результат обмена в другой системе.
Часто задаваемые вопросы
- Как понять, нужно ли передавать в CRM каждую форму сайта?
Ориентируются на дальнейшую обработку. Если обращение требует ответа, назначения ответственного или сохранения истории контакта, его включают в обмен. Для технических форм, у которых нет рабочего сценария в CRM, передачу обычно не настраивают.
- Можно ли связать заказ с существующим покупателем?
Да, если заранее утверждены признаки сопоставления и действия при спорных случаях. Телефон или e-mail не всегда дают однозначное совпадение: данные бывают общими, устаревшими или заполненными с ошибкой. Правило должно учитывать несколько найденных записей.
- Почему не стоит передавать все статусы заказа?
Часть статусов предназначена для внутренней работы и не объясняет покупателю состояние заказа. Для сайта выделяют понятные статусы, а рабочие этапы CRM оставляют внутри процесса. Соответствие между ними фиксируют в правилах интеграции.
- Что делать, если заказ изменили после передачи в CRM?
Для состава заказа, контактов, доставки и отмены заранее определяют место внесения изменений и направление передачи. Без этого двусторонний обмен может перезаписать актуальные данные или оставить разные версии заказа на сайте и в CRM.
- Как проверить интеграцию до запуска?
Проверяют сценарии отправки каждой формы, нового и повторного заказа, изменения данных, отмены, ошибки обязательного поля и временной недоступности одной из систем. По каждому сценарию сверяют созданные записи, переданные поля, статусы и повторную обработку.