Проверить работающую интеграцию можно за час, и для этого не нужен ни программист, ни доступ к серверу. Нужны два человека, телефон, браузер и заранее подготовленный набор тестовых данных. Девять сценариев ниже расположены по возрастанию сложности: первый занимает пять минут и ловит полный отказ, последний занимает пятнадцать и ловит то, о чём почти никто не думает, — поведение связки, когда вторая система недоступна.
Проверять надо и тогда, когда жалоб нет. Интеграция ломается не с грохотом: чаще всего она продолжает работать, но перестаёт передавать часть записей — заявки с длинным комментарием, повторные обращения от существующих клиентов, всё, что пришло между 3:00 и 3:20 ночью во время планового обновления. Сквозной тест такую течь не видит: вы отправляете одну заявку, она доходит, вы успокаиваетесь. Увидеть её можно только сверкой количеств за период, и ей посвящён отдельный раздел.
Все расчёты ниже — на модельной компании: 500 заявок с сайта в месяц, конверсия заявки в сделку 20 %, средний чек 24 000 ₽, валовая маржа 35 %. Отсюда средняя ценность одной заявки — 1 680 ₽ маржи. Оговорка: интерфейсы CRM и интеграционных платформ меняются несколько раз в год, поэтому ниже описано, что проверять и зачем, а не куда нажимать. Названия разделов у вас будут другими.
Девять тестов за час: что каждый из них ловит
Тесты идут подряд, результат каждого записывается сразу — потом не вспомните. Первые три проверяют, что связка вообще жива; следующие три бьют по краям данных, где ломается большинство связок; последние три проверяют поведение в неудобных ситуациях.
| № | Тест | Что ловит | Минут |
|---|---|---|---|
| 1 | Контрольная заявка через реальную форму на сайте, как обычный посетитель | Полный отказ связки. Отправлять надо именно с сайта, а не из тестового режима формы — это разные маршруты | 5 |
| 2 | Проверка источника и меток кампании в созданной сделке | Потерю UTM-меток и адреса страницы: связка работает, а аналитика по каналам уже врёт | 5 |
| 3 | Уведомление ответственному по той же заявке | Разрыв на последнем звене: сделка есть, а человек о ней не знает | 3 |
| 4 | Заявка с минимумом полей — только телефон | Падение обработчика на пустых необязательных полях и появление новых обязательных полей в CRM | 5 |
| 5 | Заявка с длинным текстом и спецсимволами | Обрезку комментария, поломку на кавычках и переносах строк, потерю эмодзи | 5 |
| 6 | Тройное нажатие кнопки отправки подряд | Отсутствие дедупликации: три одинаковые сделки вместо одной | 5 |
| 7 | Заявка от номера, который уже есть в базе | Дубль контакта вместо привязки к существующему клиенту — самая дорогая тихая поломка | 7 |
| 8 | Заявка в нерабочее время | Ночной сценарий: попадает ли она в утреннюю очередь или тонет | 5 |
| 9 | Вторая система недоступна: отозвать ключ доступа на пять минут и отправить две заявки | Главное свойство связки — ждёт она отказа или теряет данные молча | 15 |
Для тестов 4–6 держите под рукой пять готовых образцов данных: пустые необязательные поля, текст на 2 000 знаков, строку с кавычками и переносами, имя из одной буквы и телефон в непривычном формате — с восьмёркой, пробелами и скобками. Один набор, один файл, повторное использование каждый месяц. Половина связок ломается именно на них, потому что при разработке проверяли только аккуратно заполненную форму.
Если после восстановления доступа обе заявки появились в CRM — связка построена правильно: она записывает данные у себя и повторяет отправку. Если не появились — вы знаете про свою интеграцию главное: любое плановое обновление CRM или обрыв связи у провайдера означает потерянные заявки, о которых вы не узнаете. Как устроен правильный маршрут заявки с собственным журналом, разобрано в статье про связку формы сайта с CRM и мессенджером.
Горизонтальная схема маршрута заявки из пяти блоков: «Форма на сайте» → «Приёмник и журнал» → «Очередь доставки» → «CRM: контакт и сделка» → «Уведомление ответственному». На маршруте девять пронумерованных кружков-точек проверки с короткими подписями: 1 контрольная заявка, 2 метки кампании, 3 уведомление, 4 минимум полей, 5 длинный текст и спецсимволы, 6 тройное нажатие, 7 существующий клиент, 8 нерабочее время, 9 вторая система недоступна. Точка 9 нарисована на стрелке между очередью и CRM с перечёркнутой стрелкой и подписью «ключ отозван на 5 минут». Внизу подпись «55 минут на все девять». Чертёжный стиль, подписи по-русски.
Сверка количеств: как увидеть частичную потерю
Девять тестов проверяют, что связка умеет работать. Сверка количеств проверяет, что она работала весь прошлый месяц. Это разные вопросы, и второй важнее: заявки теряются не в момент вашего теста, а в три часа ночи в среду. Делается сверка так: берёте число записей-источников за календарный месяц и число созданных из них записей-получателей за тот же период, затем разбираете разницу поштучно.
Разница между количеством записей в двух системах, которая объясняется правилами обработки, а не потерей. Законные причины: склеенные дубли, отфильтрованный спам, заявки, отменённые самим клиентом. Всё остальное — потеря. Норму нельзя взять из статьи: её определяют один раз, разобрав расхождение за первый месяц поштучно, и дальше сравнивают с ней.
Обратите внимание на порядок работы: сначала объясняются законные расхождения, и только необъяснимый остаток считается потерей. Компания, которая увидит «14 заявок пропало» и пойдёт скандалить с подрядчиком, потратит две недели и получит ответ «9 из них — ваши же дубли». Компания, которая разберёт расхождение сама, придёт с конкретным вопросом про пять записей и получит ответ за день. Отдельный частый случай — не потеря, а задвоение: механику разбирали в материале про задвоенные заказы при обмене.
Диаграмма из двух столбиков и одной разбивки. Левый столбик — «Журнал заявок: 500», правый — «CRM: 486». Между ними стрелка с подписью «расхождение 14, или 2,8 %». Справа от столбиков вертикальная разбивка этих 14 на два сегмента: «9 — склеенные дубли, норма» (серый) и «5 — потеряно» (акцентный). Под сегментом потерь подпись «5 × 1 680 ₽ = 8 400 ₽ за месяц». Ось Y — количество записей. Все числа подписаны, подписи по-русски.
Тест не прошёл: что смотреть и как описать подрядчику
Первое правило: не чинить самому и не менять настройки до того, как зафиксировали, что именно случилось. Изменённая настройка уничтожает воспроизводимость, и дальше вы будете доказывать подрядчику существование проблемы, которую больше не можете показать.
- 1Зафиксировать факт
Точное время отправки, что именно отправляли, что ожидали увидеть, что увидели вместо этого. Скриншот формы и скриншот того места в CRM, где записи нет. Две минуты работы, которые экономят неделю переписки.
- 2Посмотреть три журнала подряд
Журнал формы или собственный журнал заявок — дошло ли до вас. Журнал интеграционной платформы или модуля — была ли попытка отправки и что ответила CRM. Журнал самой CRM — не отклонила ли она запись по правилу. Обрыв виден на стыке: до какого-то журнала запись доходит, дальше нет.
- 3Проверить пять типовых причин
Истёкший ключ доступа, новое обязательное поле в CRM, изменённая структура формы, исчерпанный лимит на отправку у платформы, блокировка исходящих запросов на стороне хостинга. Четыре из пяти проверяются за десять минут и закрывают большую часть случаев.
- 4Описать одной формулой
«12 августа в 14:20 отправлена заявка с телефоном такого-то формата через форму на странице такой-то. В журнале платформы попытка есть, ответ CRM — ошибка такая-то. В CRM сделки нет. Воспроизводится: 3 попытки из 3». Такое описание принимается в работу сразу. Формулировка «у нас всё время что-то теряется» не принимается никогда.
Протокол на одну страницу и как часто повторять
Результат проверки складывается в одну таблицу и в одну папку. Это занимает пять минут и однажды окупается целиком: когда встанет вопрос «связка сломалась после вашего обновления или была такой всегда», решает не память, а запись от прошлого месяца.
- 1Шапка: дата, кто проверял, какие системы и какие их версии, кто отвечает за связку со стороны подрядчика.
- 2Девять строк по тестам: прошёл, не прошёл, не проверялся — и одна фраза наблюдения по каждому. Пустая клетка недопустима: «не проверялся» тоже результат.
- 3Строка сверки количеств: сколько записей в источнике, сколько в получателе, чем объяснено расхождение, сколько осталось необъяснённым.
- 4Список расхождений с приоритетом: что чинится в ближайшую неделю, что терпит, что решено оставить как есть и почему.
- 5Дата следующей проверки. Без неё протокол превращается в разовый героический поступок.
Периодичность: раз в месяц в спокойном режиме и обязательно внеочередно после трёх событий — обновления любой из связанных систем, смены тарифа или лимитов у интеграционной платформы, правки формы на сайте. Последнее недооценивают: добавленное маркетологом поле «удобное время звонка» способно уронить связку целиком, потому что обработчик о нём не знает. Проверка процесса целиком, а не одной связки, — это уже другой жанр, для него есть чек-лист приёмки этапа.
Час своими силами против автоматического контроля
Ручная проверка стоит один час сотрудника в месяц. При полной цене часа 1 200 ₽ это 14 400 ₽ в год — дешевле, чем один потерянный день заявок. Но у неё есть врождённый недостаток: она смотрит назад. Течь, начавшаяся третьего числа, будет найдена первого числа следующего месяца, и все потери за месяц уже случились.
Считать окупаемость такого контроля надо не от годовых потерь, а от цены суток молчания. В модельной компании 500 заявок в месяц — это около 23 заявок в рабочий день, то есть 38 640 ₽ маржи в сутки. Один пойманный вовремя простой на двое суток окупает всю настройку. Если же у вас 40 заявок в месяц, сутки стоят около 3 000 ₽ — и автоматика здесь избыточна, достаточно часа проверки в месяц. Порог примерно такой: автоматический контроль оправдан там, где сутки молчания связки стоят дороже 30 000 ₽. Общая методика сигналов и порогов разобрана в статье про мониторинг автоматизации.
Когда часовой проверки мало
Эта инструкция закрывает связки, у которых один источник и один получатель: форма и CRM, CRM и телефония, магазин и учётная система по одному направлению. Есть три ситуации, в которых час проверки не даёт ответа, и делать вид, что даёт, — хуже, чем не проверять вовсе.
- Двусторонний обмен. Когда обе системы пишут в одни и те же поля, главный риск не потеря, а затирание: правка менеджера в CRM исчезает после ночной выгрузки. Это ловится не тестом, а правилом старшинства, заданным до настройки, и сравнением значений полей, а не количеств записей.
- Цепочка из трёх и более систем. Сайт передаёт в платформу, платформа в CRM, CRM в учётную систему. Расхождение накапливается на каждом стыке, и сверка «первый против последнего» показывает сумму трёх проблем без указания, где именно течёт. Сверять надо каждый стык отдельно.
- Обмен с деньгами и остатками. Здесь недостаточно узнать, что запись дошла: важно, что дошло правильное число. Проверяются не количества, а суммы и остатки на контрольную дату, и сходиться они обязаны до копейки, а не с допустимым процентом.
И общее замечание, которое стоит всей инструкции. Ни один из девяти тестов не отвечает на вопрос, правильные ли данные попали в CRM, — они отвечают на вопрос, попали ли они туда вообще. Проверка содержания — отдельная работа, и начинается она с того же, с чего начинается любой порядок в системах: с решения, какая система по каждому полю считается источником истины.
Связка, которую ни разу не проверяли при отключённой второй системе, считается непроверенной.
