Как проверить, что интеграция с CRM не теряет заявки и изменения

Почему одинаковое количество заявок ещё ничего не доказывает

В почтовом сервисе за день видно двадцать обращений, и система работы с клиентами (CRM) тоже показывает двадцать новых карточек. Кажется, что обмен работает. Но среди карточек может быть повтор одной заявки, а другая не поступила вовсе. Ещё часть записей может содержать старый телефон или неправильную услугу. Проверка общего количества полезна для первого сигнала, но не подтверждает полноту и правильность обмена.

Сверка данных CRM — это сопоставление конкретных записей между источником и системой продаж. Источником может быть сайт, телефония, почта, учётная программа или сервис заказов. Для каждой записи проверяют, появилась ли она в нужном месте, соответствует ли содержание и дошли ли последующие изменения. Так можно обнаружить проблему до того, как на неё пожалуется клиент.

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

Эта проверка нужна и после запуска интеграции. Настройки меняются, сотрудник удаляет поле, сервис временно недоступен, срок доступа приложения заканчивается. Зелёный значок подключения не показывает судьбу отдельной заявки. Регулярная сверка дополняет уведомления об ошибках и помогает находить тихие сбои, при которых явного сообщения об отказе нет.

Запишите, что именно должно передаваться

Составьте список каналов и событий. Для сайта событием будет принятая заявка, для учётной системы — изменение заказа, для CRM — новый статус, который должен уйти во внешнюю систему. Не смешивайте их в одной строке: создание записи и её обновление могут обрабатываться разными способами.

По каждому маршруту укажите исходную и конечную систему, объект, обязательные поля, направление передачи, допустимую задержку и владельца проверки. «Обновить клиента» — слишком общее условие. «Передать новый номер телефона из учётной системы в связанный контакт CRM» уже позволяет сравнить результат.

Отдельно зафиксируйте правила, по которым запись создаётся, обновляется или объединяется с существующей. Повторное обращение может создавать новую сделку у прежнего контакта. Тогда один контакт на несколько заявок — правильное поведение, а не потеря. Правило нужно знать до подсчёта расхождений.

В документации Битрикс24 о распределении обращений настройки рассматриваются отдельно для разных каналов. Поэтому при сверке проверяйте не только наличие карточки, но и назначение ответственного согласно правилам вашего канала. Конкретные настройки и возможности уточняет специалист на вашем портале.

Выберите период и подготовьте контрольную таблицу

Укажите точные начало и конец периода, часовой пояс и момент выгрузки. Формулировка «за вчера» неудобна, если одна система хранит московское время, а другая показывает время пользователя. Для регулярной проверки удобно брать завершённый интервал и оставлять согласованный запас на задержку передачи. Размер этого запаса определяется интеграцией, а не универсальным правилом.

Запросите список исходных записей и соответствующую выгрузку CRM. В инструкции Битрикс24 по экспорту описан экспорт элементов CRM. Доступность данных зависит в том числе от прав сотрудника и выбранных полей. Перед сравнением убедитесь, что фильтр и права не скрыли нужные записи.

В контрольной таблице оставьте идентификатор источника, дату события, идентификатор CRM, обязательные проверяемые поля, время появления и результат сверки. Для рабочей проверки не обязательно выгружать всю историю переписки. Чем меньше лишних персональных данных в копии, тем проще контролировать доступ и хранение.

Сначала сверяйте всё множество записей по идентификаторам, если выгрузки это позволяют. Подробную проверку содержимого можно дополнить выборкой: новые клиенты, повторные обращения, записи с нестандартными символами, большие заказы и события после перерыва связи. Выборка помогает найти типовые ошибки, но не доказывает отсутствие единичной потери в остальных записях.

Сопоставляйте записи по устойчивым идентификаторам

Идентификатор — постоянный номер записи внутри системы. Если номер заказа источника сохраняется в поле CRM, можно установить точную связь между двумя сторонами. Это надёжнее поиска только по имени: у клиентов бывают одинаковые имена, а написание компании меняется. Номер телефона тоже не всегда уникален — один номер может использовать отдел или семья.

Попросите интегратора объяснить, где хранится связь идентификаторов. Она может находиться в карточке или отдельном журнале интеграции. Маркетологу не нужно разбираться в устройстве базы данных; достаточно получить возможность проследить путь нескольких событий по постоянному номеру и понять правила связи.

Если идентификаторов нет, временно сопоставьте записи по сочетанию признаков: времени, контакту, сумме и услуге. Неоднозначные пары оставляйте на ручной разбор. Не поручайте программе автоматически объединять всё с одинаковым телефоном, пока не определены последствия. Для постоянного контроля лучше добавить устойчивую связь между системами.

Разделите расхождения по причине и риску

Для каждой спорной записи определите, какой шаг не подтверждён. Источник не сохранил обращение; событие не отправилось; отправилось с ошибкой; принято, но не обработано; карточка создана с неверным содержимым; позднее значение перезаписано. Эти ситуации требуют разных исполнителей и исправлений.

Сохраняйте доказательства: номер исходной записи, ожидаемый результат, фактическую карточку, время проверки и краткое описание. Сообщение «интеграция опять не работает» не помогает воспроизвести проблему. Запись «заказ 1842 принят в 10:17, к 10:40 не найден по внешнему номеру, хотя другие заказы того же канала появились» уже пригодна для расследования.

Назначьте приоритет по последствиям. Потерянное обращение с обещанным обратным звонком требует немедленной передачи в работу, даже если причина ещё исследуется. Ошибка в дополнительном поле может подождать планового исправления, если не мешает обслуживанию. Временный обходной способ отмечайте, чтобы после восстановления обмена не появился второй заказ.

Не исправляйте массово данные только на конечной стороне. Если неправильное значение продолжает поступать из источника, следующая синхронизация отменит ручную правку. Сначала выясните, какая система отвечает за конкретное поле и где должно храниться правильное значение. Для двустороннего обмена особенно важно правило разрешения одновременных изменений.

Проверьте задержки, повторные события и восстановление

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

В документации Битрикс24 о входящей очереди приведены рекомендации для приложения, которое принимает события из CRM: сохранять их перед подтверждением, безопасно обрабатывать повторы и отделять сообщения с постоянной ошибкой. Для заказчика практический вопрос звучит так: как система узнаёт уже обработанное событие и как сотрудник увидит то, что автоматически обработать не удалось?

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

Обсудите поздние события. Если сначала дошёл новый статус заказа, а потом запоздал старый, конечная система не должна безоговорочно откатить состояние. Как именно это обеспечивается, зависит от реализации. В критериях приёмки достаточно описать ожидаемый итог и попросить продемонстрировать его на согласованной последовательности событий.

Как организовать регулярный контроль без ежедневного расследования

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

Периодичность выбирайте по объёму и риску. При ежедневном потоке заявок может понадобиться ежедневное сопоставление количества и отсутствующих номеров, а подробная проверка полей — после изменений и по плану. Редкий обмен справочниками проверяют иначе. Нет смысла собирать отчёт чаще, чем кто-то способен его просмотреть и отреагировать.

В коротком отчёте показывайте объём исходных событий, подтверждённые записи, ожидание в допустимом интервале и неразобранные отклонения. Дубли и ошибки содержимого учитывайте отдельно. Не объединяйте их в одно число «ошибок», иначе две проблемы в одной записи будут выглядеть как две потерянные заявки.

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

Что должно подтвердить исправление

Закрывать задачу стоит после повторной сверки того же набора событий и отдельной проверки новых записей. Исчезновение сообщения об ошибке ещё не говорит о восстановлении данных за период сбоя. Попросите исполнителя перечислить, какие записи восстановлены, какие остались спорными и какие защитные меры изменились.

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

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

Чтобы поставить такую задачу, подготовьте один показательный пример и описание ожидаемого пути данных. Со ШТАБ ИТ можно обсудить доработку интеграций Битрикс24. Начинать удобнее с конкретного расхождения: где запись есть, где должна появиться и какой результат уже удалось проверить.