[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"$f1272kpvyig4fi":3},{"slug":4,"title":5,"published":6,"publishedAt":7,"createdAt":8,"section":9,"preview":10,"heroImage":11,"previewImage":11,"headMarkup":12,"lifecycleId":13,"bodyMd":14,"bodyHtml":15},"integratsiya-sayta-na-1s-bitriks-upravlenie-saytom-s-crm-formy-zakazy-i-statusy","Интеграция интернет-магазина с CRM: формы, заказы и статусы",true,"2024-05-15T10:00:00+03:00","2026-09-06T16:09:08.575Z","Статьи","Статья о правилах обмена заявками, заказами и статусами между интернет-магазином и CRM. Рассмотрены источники данных, обработка ошибок и проверка сценариев.","\u002Fcontent-media\u002Farticles\u002Fintegratsiya-sayta-na-1s-bitriks-upravlenie-saytom-s-crm-formy-zakazy-i-statusy\u002Fassets\u002F97f66882affe.webp",[],"lc_3aa22aa1edca192e3b10a250278a24f6","Покупатель оставил заявку на сайте, менеджер увидел её позже, а затем вручную перенёс телефон, состав заказа и комментарий в CRM. За это время клиент может оформить покупку повторно, изменить данные или получить разные ответы от сотрудников. После оплаты возникает другая проблема: сайт показывает один статус, сотрудник ориентируется на другой, а покупателю приходится уточнять состояние заказа.\n\nИнтеграция интернет-магазина с CRM задаёт маршрут для заявки или заказа: от действия посетителя на сайте до обработки сотрудником и обратного сообщения покупателю. Для этого разделяют зоны ответственности сайта и CRM, фиксируют состав передаваемых данных, права на изменение и порядок действий при ошибке обмена.\n\n## Какие объекты связывает интеграция интернет-магазина с CRM\n\nСайт на 1С-Битрикс: Управление сайтом ведёт пользовательский сценарий: каталог, карточки товаров, корзину, оформление заказа, формы и страницы для посетителей. CRM используют для обработки обращений, уточнения заказа и ведения коммуникации.\n\nИнтеграция не требует делать из двух систем одинаковые базы. Для каждого объекта проект определяет источник данных. Сайт может передавать состав оформленного заказа и контакты покупателя, а CRM — возвращать статус, разрешённый для показа в личном кабинете или сообщении. Если поле редактируют в обеих системах, заранее утверждают приоритет при расхождении.\n\nОбычно в обмен включают:\n\n- заявки из форм;\n- заказы и позиции заказа;\n- данные покупателей;\n- товары, если они нужны сотрудникам для обработки заказа;\n- статусы и служебные отметки;\n- события оплаты или доставки, если они предусмотрены пользовательским сценарием.\n\nПеречень строят вокруг действий, а не названий разделов. Заявка на обратный звонок и заказ из корзины могут попадать к разным сотрудникам, иметь разные обязательные поля и обрабатываться по разным правилам.\n\n## Передача заявок с форм сайта в CRM\n\nФорма перестаёт быть простой, когда на сайте появляются запрос консультации, подбор товара, партнёрское обращение и вопрос по уже оформленному заказу. Если все они создают одинаковые записи, сотруднику приходится вручную определять тип обращения и искать контекст.\n\nВладелец процесса утверждает для каждой формы состав полей и назначение заявки в CRM. Для обращения по заказу это может быть номер заказа, для подбора товара — категория или параметры, для сервисного запроса — идентификатор клиента либо выбранная тема. Имя, способ связи, текст обращения и страница отправки также включаются в обмен, если они нужны сотруднику для работы.\n\nОтдельное правило требуется для повторной отправки. Оно относится к заявке и определяет, когда создаётся новая запись, а когда обращение связывается с существующей. Так предотвращают и лишние дубли после повторного нажатия кнопки, и ошибочное объединение обращений разных людей с одинаковыми данными.\n\n## Обмен заказами между сайтом и CRM\n\nЗаказ содержит не только сумму и список товаров. В сценарии проекта могут участвовать способ доставки, данные получателя, комментарий, способ оплаты, скидка, отмена или изменение состава после разговора с сотрудником. Если часть сведений остаётся только на сайте, сотрудник будет сверять заказ вручную.\n\nДо настройки обмена команда проходит путь от корзины до завершения обработки. На этом этапе фиксируют момент создания записи в CRM, порядок передачи неоплаченного заказа, допустимость изменения состава, место фиксации отмены и обработку неполных данных.\n\nПравило сопоставления покупателя утверждают отдельно. Оно определяет, как система ищет существующую запись, когда создаёт новую и как поступает при нескольких совпадениях. Поиск только по телефону не покрывает ситуации с разными номерами и адресами у одного человека или с корпоративным заказом, где контакт сотрудника и данные организации относятся к разным объектам. Такая схема снижает риск связать заказ не с той карточкой.\n\n## Синхронизация статусов заказа и статусов CRM\n\nСтатус на сайте сообщает покупателю, что происходит с заказом. Статус в CRM отражает рабочий этап сотрудника. Эти цепочки редко совпадают: внутренние отметки о проверке данных или ожидании ответа могут быть нужны команде, но не подходят для личного кабинета.\n\nСтатусы сопоставляют по смыслу, а не по названию. Для каждого статуса владелец процесса утверждает направление обмена и результат: изменение приходит с сайта в CRM, возвращается на сайт или остаётся внутренним. Для отмены отдельно фиксируют, что увидят сотрудник и покупатель и при каких условиях обработка может быть возобновлена.\n\nПорядок событий тоже входит в правила проекта. Если несколько действий произошли почти одновременно, устаревшее обновление не должно возвращать заказ на предыдущий этап. Для этого связывают события с идентификаторами обмена, задают порядок обработки и сохраняют сведения об ошибках.\n\n## Данные товаров, оплаты и доставки\n\nСвязь сайта с CRM нередко начинается с заявок и заказов, а затем в обмен добавляют справочные данные. Каталог, цены, остатки, оплата и доставка могут иметь разные источники и отдельные правила обновления, поэтому их не стоит объединять в один поток без описанного сценария.\n\nДанные товаров передают, когда сотруднику нужен точный состав заказа без ручной сверки. Проект должен определить, что считается товаром в обмене: артикул, вариант, комплект, услуга, подарок или скидка. Если у товара есть варианты, одного названия позиции недостаточно для сопоставления.\n\nДля оплаты и доставки описывают конкретные события: заказ создан, подтверждён, передан в доставку, частично отменён или возвращён. Каждому событию назначают действие в CRM и, при необходимости, сообщение для сайта. Это предотвращает ситуацию, когда внутренний этап случайно становится статусом для покупателя.\n\n## Ошибки обмена и контроль интеграции\n\nОбмен может остановиться из-за недоступности одной из систем, изменённого формата данных, отсутствия обязательного поля или ошибки доступа. Без порядка контроля заявка или заказ могут остаться между сайтом и CRM без заметного сигнала для сотрудников.\n\nВ проекте назначают, где фиксируются неотправленные объекты, кто разбирает ошибку и как выполняется повторная передача. Это правило относится к конкретному объекту обмена и защищает от повторного создания заявки или заказа при перезапуске.\n\nТехническая связь между объектами сайта и CRM помогает разбирать расхождения. В ней сохраняют идентификаторы, время и направление обмена, а также результат обработки. Отдельно проверяют неполные данные: пустой телефон, некорректный e-mail, товар без идентификатора, заказ без выбранного способа доставки.\n\n## Как выбрать схему интеграции сайта с CRM\n\nВыбор начинается с карты процессов, а не с набора модулей. Для передачи обращений из нескольких форм описывают типы заявок, поля, ответственных и обработку повторной отправки. Для интернет-заказов добавляют схему статусов, правила сопоставления покупателей, состав заказа и сценарии исключений.\n\nПеред началом работ полезно согласовать:\n\n- какие объекты и поля передаются в каждом направлении;\n- где создаётся объект и какая система хранит основную версию;\n- как обрабатываются дубли, пустые поля и изменения после передачи;\n- какие статусы видит покупатель, а какие остаются рабочими;\n- что происходит при недоступности одной из систем;\n- как проверяется обмен и где фиксируются ошибки.\n\nСхема подходит проекту, если по каждому объекту можно отследить, где появились данные, кто изменил их и каким оказался результат обмена в другой системе.\n\n## Часто задаваемые вопросы\n### Как понять, нужно ли передавать в CRM каждую форму сайта?\n\nОриентируются на дальнейшую обработку. Если обращение требует ответа, назначения ответственного или сохранения истории контакта, его включают в обмен. Для технических форм, у которых нет рабочего сценария в CRM, передачу обычно не настраивают.\n\n### Можно ли связать заказ с существующим покупателем?\n\nДа, если заранее утверждены признаки сопоставления и действия при спорных случаях. Телефон или e-mail не всегда дают однозначное совпадение: данные бывают общими, устаревшими или заполненными с ошибкой. Правило должно учитывать несколько найденных записей.\n\n### Почему не стоит передавать все статусы заказа?\n\nЧасть статусов предназначена для внутренней работы и не объясняет покупателю состояние заказа. Для сайта выделяют понятные статусы, а рабочие этапы CRM оставляют внутри процесса. Соответствие между ними фиксируют в правилах интеграции.\n\n### Что делать, если заказ изменили после передачи в CRM?\n\nДля состава заказа, контактов, доставки и отмены заранее определяют место внесения изменений и направление передачи. Без этого двусторонний обмен может перезаписать актуальные данные или оставить разные версии заказа на сайте и в CRM.\n\n### Как проверить интеграцию до запуска?\n\nПроверяют сценарии отправки каждой формы, нового и повторного заказа, изменения данных, отмены, ошибки обязательного поля и временной недоступности одной из систем. По каждому сценарию сверяют созданные записи, переданные поля, статусы и повторную обработку.","\u003Cp>Покупатель оставил заявку на сайте, менеджер увидел её позже, а затем вручную перенёс телефон, состав заказа и комментарий в CRM. За это время клиент может оформить покупку повторно, изменить данные или получить разные ответы от сотрудников. После оплаты возникает другая проблема: сайт показывает один статус, сотрудник ориентируется на другой, а покупателю приходится уточнять состояние заказа.\u003C\u002Fp>\n\u003Cp>Интеграция интернет-магазина с CRM задаёт маршрут для заявки или заказа: от действия посетителя на сайте до обработки сотрудником и обратного сообщения покупателю. Для этого разделяют зоны ответственности сайта и CRM, фиксируют состав передаваемых данных, права на изменение и порядок действий при ошибке обмена.\u003C\u002Fp>\n\u003Ch2>Какие объекты связывает интеграция интернет-магазина с CRM\u003C\u002Fh2>\n\u003Cp>Сайт на 1С-Битрикс: Управление сайтом ведёт пользовательский сценарий: каталог, карточки товаров, корзину, оформление заказа, формы и страницы для посетителей. CRM используют для обработки обращений, уточнения заказа и ведения коммуникации.\u003C\u002Fp>\n\u003Cp>Интеграция не требует делать из двух систем одинаковые базы. Для каждого объекта проект определяет источник данных. Сайт может передавать состав оформленного заказа и контакты покупателя, а CRM — возвращать статус, разрешённый для показа в личном кабинете или сообщении. Если поле редактируют в обеих системах, заранее утверждают приоритет при расхождении.\u003C\u002Fp>\n\u003Cp>Обычно в обмен включают:\u003C\u002Fp>\n\u003Cul>\n\u003Cli>заявки из форм;\u003C\u002Fli>\n\u003Cli>заказы и позиции заказа;\u003C\u002Fli>\n\u003Cli>данные покупателей;\u003C\u002Fli>\n\u003Cli>товары, если они нужны сотрудникам для обработки заказа;\u003C\u002Fli>\n\u003Cli>статусы и служебные отметки;\u003C\u002Fli>\n\u003Cli>события оплаты или доставки, если они предусмотрены пользовательским сценарием.\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Cp>Перечень строят вокруг действий, а не названий разделов. Заявка на обратный звонок и заказ из корзины могут попадать к разным сотрудникам, иметь разные обязательные поля и обрабатываться по разным правилам.\u003C\u002Fp>\n\u003Ch2>Передача заявок с форм сайта в CRM\u003C\u002Fh2>\n\u003Cp>Форма перестаёт быть простой, когда на сайте появляются запрос консультации, подбор товара, партнёрское обращение и вопрос по уже оформленному заказу. Если все они создают одинаковые записи, сотруднику приходится вручную определять тип обращения и искать контекст.\u003C\u002Fp>\n\u003Cp>Владелец процесса утверждает для каждой формы состав полей и назначение заявки в CRM. Для обращения по заказу это может быть номер заказа, для подбора товара — категория или параметры, для сервисного запроса — идентификатор клиента либо выбранная тема. Имя, способ связи, текст обращения и страница отправки также включаются в обмен, если они нужны сотруднику для работы.\u003C\u002Fp>\n\u003Cp>Отдельное правило требуется для повторной отправки. Оно относится к заявке и определяет, когда создаётся новая запись, а когда обращение связывается с существующей. Так предотвращают и лишние дубли после повторного нажатия кнопки, и ошибочное объединение обращений разных людей с одинаковыми данными.\u003C\u002Fp>\n\u003Ch2>Обмен заказами между сайтом и CRM\u003C\u002Fh2>\n\u003Cp>Заказ содержит не только сумму и список товаров. В сценарии проекта могут участвовать способ доставки, данные получателя, комментарий, способ оплаты, скидка, отмена или изменение состава после разговора с сотрудником. Если часть сведений остаётся только на сайте, сотрудник будет сверять заказ вручную.\u003C\u002Fp>\n\u003Cp>До настройки обмена команда проходит путь от корзины до завершения обработки. На этом этапе фиксируют момент создания записи в CRM, порядок передачи неоплаченного заказа, допустимость изменения состава, место фиксации отмены и обработку неполных данных.\u003C\u002Fp>\n\u003Cp>Правило сопоставления покупателя утверждают отдельно. Оно определяет, как система ищет существующую запись, когда создаёт новую и как поступает при нескольких совпадениях. Поиск только по телефону не покрывает ситуации с разными номерами и адресами у одного человека или с корпоративным заказом, где контакт сотрудника и данные организации относятся к разным объектам. Такая схема снижает риск связать заказ не с той карточкой.\u003C\u002Fp>\n\u003Ch2>Синхронизация статусов заказа и статусов CRM\u003C\u002Fh2>\n\u003Cp>Статус на сайте сообщает покупателю, что происходит с заказом. Статус в CRM отражает рабочий этап сотрудника. Эти цепочки редко совпадают: внутренние отметки о проверке данных или ожидании ответа могут быть нужны команде, но не подходят для личного кабинета.\u003C\u002Fp>\n\u003Cp>Статусы сопоставляют по смыслу, а не по названию. Для каждого статуса владелец процесса утверждает направление обмена и результат: изменение приходит с сайта в CRM, возвращается на сайт или остаётся внутренним. Для отмены отдельно фиксируют, что увидят сотрудник и покупатель и при каких условиях обработка может быть возобновлена.\u003C\u002Fp>\n\u003Cp>Порядок событий тоже входит в правила проекта. Если несколько действий произошли почти одновременно, устаревшее обновление не должно возвращать заказ на предыдущий этап. Для этого связывают события с идентификаторами обмена, задают порядок обработки и сохраняют сведения об ошибках.\u003C\u002Fp>\n\u003Ch2>Данные товаров, оплаты и доставки\u003C\u002Fh2>\n\u003Cp>Связь сайта с CRM нередко начинается с заявок и заказов, а затем в обмен добавляют справочные данные. Каталог, цены, остатки, оплата и доставка могут иметь разные источники и отдельные правила обновления, поэтому их не стоит объединять в один поток без описанного сценария.\u003C\u002Fp>\n\u003Cp>Данные товаров передают, когда сотруднику нужен точный состав заказа без ручной сверки. Проект должен определить, что считается товаром в обмене: артикул, вариант, комплект, услуга, подарок или скидка. Если у товара есть варианты, одного названия позиции недостаточно для сопоставления.\u003C\u002Fp>\n\u003Cp>Для оплаты и доставки описывают конкретные события: заказ создан, подтверждён, передан в доставку, частично отменён или возвращён. Каждому событию назначают действие в CRM и, при необходимости, сообщение для сайта. Это предотвращает ситуацию, когда внутренний этап случайно становится статусом для покупателя.\u003C\u002Fp>\n\u003Ch2>Ошибки обмена и контроль интеграции\u003C\u002Fh2>\n\u003Cp>Обмен может остановиться из-за недоступности одной из систем, изменённого формата данных, отсутствия обязательного поля или ошибки доступа. Без порядка контроля заявка или заказ могут остаться между сайтом и CRM без заметного сигнала для сотрудников.\u003C\u002Fp>\n\u003Cp>В проекте назначают, где фиксируются неотправленные объекты, кто разбирает ошибку и как выполняется повторная передача. Это правило относится к конкретному объекту обмена и защищает от повторного создания заявки или заказа при перезапуске.\u003C\u002Fp>\n\u003Cp>Техническая связь между объектами сайта и CRM помогает разбирать расхождения. В ней сохраняют идентификаторы, время и направление обмена, а также результат обработки. Отдельно проверяют неполные данные: пустой телефон, некорректный e-mail, товар без идентификатора, заказ без выбранного способа доставки.\u003C\u002Fp>\n\u003Ch2>Как выбрать схему интеграции сайта с CRM\u003C\u002Fh2>\n\u003Cp>Выбор начинается с карты процессов, а не с набора модулей. Для передачи обращений из нескольких форм описывают типы заявок, поля, ответственных и обработку повторной отправки. Для интернет-заказов добавляют схему статусов, правила сопоставления покупателей, состав заказа и сценарии исключений.\u003C\u002Fp>\n\u003Cp>Перед началом работ полезно согласовать:\u003C\u002Fp>\n\u003Cul>\n\u003Cli>какие объекты и поля передаются в каждом направлении;\u003C\u002Fli>\n\u003Cli>где создаётся объект и какая система хранит основную версию;\u003C\u002Fli>\n\u003Cli>как обрабатываются дубли, пустые поля и изменения после передачи;\u003C\u002Fli>\n\u003Cli>какие статусы видит покупатель, а какие остаются рабочими;\u003C\u002Fli>\n\u003Cli>что происходит при недоступности одной из систем;\u003C\u002Fli>\n\u003Cli>как проверяется обмен и где фиксируются ошибки.\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Cp>Схема подходит проекту, если по каждому объекту можно отследить, где появились данные, кто изменил их и каким оказался результат обмена в другой системе.\u003C\u002Fp>\n\u003Ch2>Часто задаваемые вопросы\u003C\u002Fh2>\n\u003Ch3>Как понять, нужно ли передавать в CRM каждую форму сайта?\u003C\u002Fh3>\n\u003Cp>Ориентируются на дальнейшую обработку. Если обращение требует ответа, назначения ответственного или сохранения истории контакта, его включают в обмен. Для технических форм, у которых нет рабочего сценария в CRM, передачу обычно не настраивают.\u003C\u002Fp>\n\u003Ch3>Можно ли связать заказ с существующим покупателем?\u003C\u002Fh3>\n\u003Cp>Да, если заранее утверждены признаки сопоставления и действия при спорных случаях. Телефон или e-mail не всегда дают однозначное совпадение: данные бывают общими, устаревшими или заполненными с ошибкой. Правило должно учитывать несколько найденных записей.\u003C\u002Fp>\n\u003Ch3>Почему не стоит передавать все статусы заказа?\u003C\u002Fh3>\n\u003Cp>Часть статусов предназначена для внутренней работы и не объясняет покупателю состояние заказа. Для сайта выделяют понятные статусы, а рабочие этапы CRM оставляют внутри процесса. Соответствие между ними фиксируют в правилах интеграции.\u003C\u002Fp>\n\u003Ch3>Что делать, если заказ изменили после передачи в CRM?\u003C\u002Fh3>\n\u003Cp>Для состава заказа, контактов, доставки и отмены заранее определяют место внесения изменений и направление передачи. Без этого двусторонний обмен может перезаписать актуальные данные или оставить разные версии заказа на сайте и в CRM.\u003C\u002Fp>\n\u003Ch3>Как проверить интеграцию до запуска?\u003C\u002Fh3>\n\u003Cp>Проверяют сценарии отправки каждой формы, нового и повторного заказа, изменения данных, отмены, ошибки обязательного поля и временной недоступности одной из систем. По каждому сценарию сверяют созданные записи, переданные поля, статусы и повторную обработку.\u003C\u002Fp>\n"]