Заявка с сайта уходит в почту, оттуда её вручную переносят в CRM, из CRM данные попадают в 1С, а статус заказа возвращается на сайт. Четыре звена, три разные системы и один менеджер, который в понедельник утром обнаруживает, что заказов за выходные было двенадцать, а дошло девять. Где потерялись три — непонятно. Каждое звено показывает «всё отправлено», а цепочка при этом рвётся.
Обмен данными на сайте почти всегда выглядит именно так: не одна интеграция, а цепочка. И ломается она обычно не там, где её настраивали, а на стыке. Разберём эту цепочку по трём слоям: поля, статусы и ошибки.
Маршрут одной заявки
Чтобы увидеть слабое место, полезно пройти путь заявки целиком, как будто вы её отправили сами.
- Человек заполняет форму на сайте и нажимает «Отправить».
- Данные уходят на сервер и проверяются на обязательные поля.
- Формируется письмо или запрос к CRM, 1С или мессенджеру.
- Заявка появляется в системе учёта и получает номер.
- Менеджер меняет статус, и он возвращается на сайт или в личный кабинет.
Пять шагов — пять мест, где что-то может потеряться. И чаще всего теряется не заявка целиком, а часть информации о ней.
Поля: что именно вы передаёте
Поле — это не просто ячейка в форме. Это единица данных, которая должна дойти до конца цепочки в неизменном виде. И тут начинается путаница.
Телефон, введённый как «8 (912) 345-67-89», в одной системе останется строкой, а в другой не пройдёт проверку формата. Имя, написанное латиницей, в CRM может превратиться в «????». Комментарий с переносом строки разорвёт CSV-выгрузку. Адрес доставки, разбитый на «город» и «улица» в 1С, на сайте окажется одним длинным полем.
Проверять нужно не «передаётся ли поле», а «передаётся ли оно в том виде, в котором его ждут на другом конце». Для каждого поля стоит ответить на три вопроса: обязательное ли оно, в каком формате ожидается и что произойдёт, если его не будет.
Отдельная история — скрытые поля. UTM-метки, номер страницы, источник перехода, идентификатор товара. Они не видны человеку, но именно по ним вы потом понимаете, откуда пришёл клиент. Если они не доходят до CRM, аналитика покажет «прямые заходы» вместо реальных каналов.
Статусы: кто на самом деле управляет заказом
Статус — это самая недооценённая часть обмена. Кажется, что это просто надпись в админке. На деле от статуса зависит, что видит клиент, что делает менеджер и что происходит со складом.
Главная проблема — рассинхрон справочников. В 1С статусов пять: «новый», «в работе», «собран», «отгружен», «отменён». В WooCommerce или CRM их семь, и называются они иначе. При обмене часть статусов не находит пару и молча сбрасывается в «новый» — или не передаётся вовсе. Клиент видит «в обработке», хотя заказ уже уехал.
Поэтому до настройки обмена составьте соответствие: какой статус в одной системе соответствует какому в другой. И решите, кто главный. Если статус меняют и в 1С, и в CRM, при следующем обмене они будут перезаписывать друг друга по кругу, и никто не поймёт, какой из них настоящий.
Ещё один нюанс — статусы оплаты и доставки. Это часто отдельные поля, и они тоже должны синхронизироваться. Заказ может быть «оплачен» в одной системе и «ожидает оплаты» в другой, если обмен настроен только на основной статус.
Ошибки: где рвётся цепочка
Ошибка — это не только «красный экран». Чаще всего обмен ломается тихо: запрос уходит, ответ приходит, а данные не сохраняются. Или сохраняются частично. Или сохраняются дважды.
Самый частый сценарий — таймаут. Обмен идёт по расписанию, сервер 1С не успевает ответить за отведённое время, и запрос просто обрывается. Заявка при этом может остаться в очереди, а может исчезнуть. Без логов вы об этом не узнаете, пока клиент не позвонит и не спросит, почему его заказ не подтвердили.
Второй сценарий — дубли. Если обмен запустился дважды или клиент дважды нажал кнопку, одна и та же заявка создаётся в CRM два раза. Менеджер звонит клиенту дважды, клиент раздражается, а в отчётах задваиваются продажи.
Третий — молчаливый пропуск. Обязательное поле пришло пустым, система не сохранила запись, но и ошибку не показала. Снаружи всё выглядит нормально, а заказа нет.
Что должно быть в логах
Логи — единственный способ понять, что произошло, когда цепочка уже порвалась. И требования к ним простые: по каждой заявке должно быть видно, когда она ушла, куда, что ответила принимающая система и с какой попытки прошла.
- Дата и время каждой попытки обмена.
- Идентификатор заявки, чтобы найти её в любой системе.
- Ответ принимающей стороны — успех или текст ошибки.
- Количество попыток и результат последней.
- Возможность повторно отправить заявку, которая не прошла.
Если логов нет, диагностика превращается в гадание. Хорошая практика — раз в неделю просматривать, были ли неудачные обмены. Пять минут в неделю экономят часы разбирательств.
Проверка перед запуском
Прогоните цепочку на реальных данных, а не на одной тестовой заявке. Отправьте несколько форм с разными наборами полей, включая неудобные: без отчества, с латиницей, с длинным комментарием. Проверьте, что каждая дошла и все поля сохранились.
Затем измените статус в системе учёта и посмотрите, вернулся ли он на сайт. И наоборот: смените статус на сайте и проверьте, что он обновился в CRM. Если в какую-то сторону обмен не идёт — вы нашли проблему до того, как её нашёл клиент.
И проверьте поведение при сбое: отключите принимающую систему на минуту и отправьте заявку. Она должна сохраниться и уйти позже, а не пропасть. Это один из самых важных тестов, и его почти всегда пропускают.
Что в итоге
Обмен данными — это не одна настройка, а маршрут из нескольких звеньев. Поля должны доходить в нужном формате, статусы — соответствовать друг другу и иметь одного хозяина, а ошибки — фиксироваться и быть видными. Если хотя бы одно звено настроено вслепую, цепочка рвётся в самом неудобном месте.
Мы обычно начинаем с того, что проходим этот маршрут вместе с клиентом: смотрим, что куда уходит, сверяем справочники статусов и проверяем, что происходит при сбое. Иногда достаточно поправить формат полей и добавить логи, а иногда — перестроить схему обмена. Напишите или оставьте заявку — разберём вашу цепочку и скажем, где она может рваться, чтобы заказы не терялись между сайтом и учётом.