10 ошибок интеграций с CRM, 1С и API, из-за которых теряются заявки

В статье узнаете:

• почему интеграции ломаются не только "технически";
• какие ошибки чаще всего теряют заявки;
• где возникают дубли, неверные остатки и плохая аналитика;
• как проверять CRM, 1С и API перед запуском;
• какие вопросы задать подрядчику;
• что делать, если интеграция уже работает нестабильно.

Короткий ответ

Самая опасная ошибка интеграции – считать ее готовой после одной успешной отправки формы. Бизнесу нужно проверить не только идеальный сценарий, но и повторы, ошибки, недоступность сервиса, обязательные поля, UTM-метки, файлы, статусы и права доступа.

Интеграция должна отвечать на вопросы:

• дошла ли заявка;
• кто ее получил;
• сохранился ли контекст;
• что произошло при ошибке;
• можно ли повторить отправку;
• видно ли это в отчете.

Если ответов нет, бизнес может терять деньги, даже когда "все подключено".

Ошибка 1. Проверять только одну тестовую заявку

Обычно тест выглядит так: разработчик заполнил форму, в CRM появился лид, все выдохнули. Этого мало.

Нужно проверить разные сценарии:

• заявка с телефона;
• заявка с UTM-метками;
• заявка с файлом;
• повторная заявка тем же номером;
• заявка по разным услугам;
• заявка при недоступной CRM;
• заявка с ошибкой в обязательном поле.

Клиенты не отправляют формы так аккуратно, как тестировщик.

Ошибка 2. Не передавать контекст

Имя и телефон – это контакт, а не заявка. Менеджеру нужно понимать, что хотел человек.

Контекст может включать:

• страницу отправки;
• услугу;
• город;
• филиал;
• комментарий;
• UTM-метки;
• выбранный тариф;
• файл;
• источник;
• форму, через которую пришел человек.

Для клиники это направление и филиал. Для производства – материал, тираж и чертеж. Для учебного центра – курс и дата старта. Без контекста менеджер начинает разговор вслепую.

Ошибка 3. Не назначать ответственного

Заявка в CRM еще не значит, что ее обработали. Если нет ответственного, уведомления и срока реакции, лид может лежать в системе незамеченным.

Назначение можно делать:

• по услуге;
• по региону;
• по филиалу;
• по источнику;
• по очереди;
• по графику;
• вручную через администратора.

Главное – правило должно быть понятным до запуска.

Ошибка 4. Не обрабатывать дубли

Один клиент может оставить несколько заявок. Он мог сначала скачать прайс, потом запросить расчет, потом написать в форму обратного звонка.

Если каждое действие создает новую карточку, CRM быстро загрязняется. Менеджеры не видят историю, руководитель получает раздутые цифры, маркетолог неверно считает эффективность рекламы.

Перед запуском нужно решить:

• по чему искать дубль;
• обновлять старую карточку или создавать новую;
• что делать с повторной заявкой;
• как не потерять комментарий;
• как связать клиента и компанию.

Ошибка 5. Забыть про UTM-метки

Форма может исправно создавать лиды, но если UTM-метки не передаются, маркетинг слепнет. В CRM есть заявки, но не видно, какая реклама привела продажу.

Проверять нужно не только наличие UTM в браузере, но и то, как они попали в CRM: в какие поля, в каком виде, не перезаписываются ли они при повторной заявке.

Ошибка 6. Не логировать ошибки

CRM, 1С или внешний API могут быть временно недоступны. Токен может истечь. Поле может измениться. Файл может не загрузиться.

Если ошибка не записывается, заявка исчезает. Разработчик потом не видит, что произошло, а бизнес слышит от клиента: "Я оставлял заявку, мне никто не ответил".

Минимум нужен журнал:

• дата и время;
• форма;
• данные без лишней персональной информации в открытом виде;
• ответ внешней системы;
• статус отправки;
• возможность повторить отправку.

Ошибка 7. Хранить ключи доступа как попало

Вебхуки, токены и API-ключи дают доступ к данным. Их нельзя вставлять в публичный JavaScript, отправлять в чаты без контроля или хранить в файлах, доступных из браузера.

Если доступ утек, посторонний человек может читать или менять данные в CRM, создавать сделки, получать клиентскую информацию или ломать процесс.

Ошибка 8. Не учитывать изменения в CRM и 1С

Интеграция может работать месяцами, а потом сломаться после изменения поля, воронки, прав, пользователя, склада или статуса.

Например:

• в CRM удалили обязательное поле;
• изменили название стадии;
• в 1С поменяли справочник;
• добавили новый склад;
• истек токен;
• отключили пользователя, от имени которого работает обмен.

Интеграция – не одноразовая настройка. Ее нужно поддерживать.

Ошибка 9. Не согласовать владельца данных

Если сайт и 1С оба могут менять цену, рано или поздно одна система перетрет другую. Если CRM и сайт по-разному хранят телефон, появятся дубли.

Для каждого типа данных нужен главный источник:

Без этого команда спорит уже после запуска.

Ошибка 10. Не делать приемку по бизнес-сценариям

Интеграцию нельзя принимать словами "данные передаются". Нужно пройти сценарии.

Пример для производства:

1. Клиент отправляет заявку с файлом чертежа.
2. В CRM создается сделка.
3. Менеджер получает уведомление.
4. Файл доступен в карточке.
5. UTM-метки сохранены.
6. После расчета заказ уходит в 1С.
7. Статус меняется и виден ответственному.

Для клиники сценарий будет другим. Для учебного центра – третьим. Приемка должна идти от бизнеса, а не от абстрактной "интеграции".

Что проверить, если интеграция уже работает плохо

Начните с простого:

1. Сравните заявки на сайте, в почте, в CRM и в аналитике.
2. Проверьте последние ошибки отправки.
3. Отправьте тесты с разных форм.
4. Проверьте UTM-метки.
5. Посмотрите дубли по телефону.
6. Проверьте ответственных.
7. Проверьте права пользователя или вебхука.
8. Проверьте изменения полей в CRM.
9. Проверьте обмен с 1С на тестовом заказе.
10. Запишите, где именно теряется контекст.

Часто проблема находится не в одном месте, а в цепочке.

Когда стоит делать аудит интеграций

Аудит нужен, если:

• заявки "иногда" не доходят;
• менеджеры ведут часть данных вручную;
• CRM и сайт показывают разные цифры;
• 1С и сайт расходятся по остаткам;
• дубли мешают продажам;
• реклама есть, но источник продаж непонятен;
• перед редизайном нельзя потерять старые процессы.

Часто задаваемые вопросы

Почему заявки есть на сайте, но их нет в CRM

Причина может быть в ошибке формы, вебхука, токена, обязательного поля, прав доступа или недоступности CRM. Нужны логи отправки, иначе придется угадывать.

Можно ли обойтись без логов

Можно, пока все работает. Но при первой проблеме без логов сложно понять, была ли заявка, что отправилось и какой ответ вернула внешняя система.

Что важнее: CRM или 1С

Это разные задачи. CRM отвечает за продажи и коммуникацию, 1С чаще отвечает за учет, товары, остатки, документы и заказы. Сайт может быть связан с обеими системами.

Почему появляются дубли в CRM

Чаще всего из-за отсутствия правил поиска клиента. Нужно заранее решить, сравнивать телефон, email, компанию или другой идентификатор.

Нужно ли проверять интеграции после запуска

Да. Особенно после изменений на сайте, в CRM, 1С, формах, правах доступа, полях, воронках и рекламных посадочных страницах.

Вывод

Интеграции ломаются не только из-за кода. Они ломаются из-за неописанных правил бизнеса: кто отвечает за заявку, какие данные обязательны, что делать с дублем, где хранить ошибку и как принять результат.

Если сайт связан с CRM, 1С и внешними API, проверять нужно всю цепочку. Идеальная тестовая заявка не доказывает, что бизнес защищен от потерь.

Источники

1. Bitrix24 REST API: Overview of REST API 3.0.
2. amoCRM Developers: WebHooks.
3. 1С:Предприятие: HTTP-сервисы.
4. MDN Web Docs: HTTP response status codes.