Сбой интеграции CRM: какую информацию собрать, чтобы подрядчик быстрее нашёл причину

Путь заявки между сайтом и CRM

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

Начните с одного отправления. Сообщение «заявки пропадают» описывает тревогу отдела, но не даёт исполнителю обращения, путь которого можно восстановить.

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

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

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

Кому передать описание: интегратору или автору приложения?

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

Ответственный за разбор — один. Он собирает ответы остальных участников, чтобы руководителю не пришлось повторять описание одного сбоя в нескольких чатах.

Справка Битрикс24 о поддержке приложений относит консультации по стороннему приложению к его разработчику. Для поиска контактов открывают «Приложения > Маркет». Далее нужен пункт «Ещё > Установленные приложения». Эти названия помогают найти именно тот сервис, который сейчас подключён к порталу. В описание инцидента попадает его точное название, а не общее слово «интеграция».

На странице приложения контакты находятся в разделе «Техническая поддержка». Производитель отдельно указывает, что собственная поддержка консультирует по приложениям разработчиков 1С-Битрикс и Битрикс24 Интеграции. Это позволяет направить вопрос по адресу ещё до получения технических журналов.

Граница ответственности в первом сообщении

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

Время и номера связывают события разных систем

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

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

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

Одна попытка и её продолжение

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

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

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

Что ожидали в карточке и что получили на самом деле

Фраза «данные передались неправильно» полезна после того, как названо поле и объяснено его назначение. Для формы обращения это может быть контакт для ответа, выбранная услуга или комментарий посетителя. Руководитель берёт состав передачи из задания на интеграцию. Если такого описания нет, сначала восстанавливают правило вместе с исполнителем. Иначе неизвестно, отсутствует ли обязательный результат или сотрудник ждёт сведения, которые никто не включал в обмен.

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

Заказчик описывает передачу контакта через задачу менеджера: значение из формы доступно для ответа в карточке обращения, найденного по номеру и времени отправки. В описание входят подписи полей на сайте и в карточке. Технические обозначения выяснит разработчик. При отличии форматов он объясняет преобразование. Маркетолог решает, сохраняет ли оно нужный смысл.

Минимальный состав записи об инциденте

• Начало. Адрес формы и действие, после которого сайт принял обращение.
• Связь. Номер исходной записи, дата, время и найденная карточка CRM.
• Ожидание. Где менеджер ищет результат и какое значение ему нужно для работы.
• Факт. Что отсутствует, отличается или появилось повторно.
• Повторение. Условия, при которых сбой воспроизвёлся, и отдельная запись удачной попытки.
• Изменения. Что меняли в форме, CRM или приложении перед появлением проблемы.

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

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

Что запросить у исполнителя вместо полного журнала

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

Код ответа сервиса и результат действия различаются. Именно поэтому ответ исполнителя полезно завершать ссылкой на созданную запись или объяснением её отсутствия.

Справка Битрикс24 о программном обмене описывает поле error с кодом ошибки в ответе на одиночный запрос. Поле error_description содержит пояснение для разработчика. Если исполнитель упоминает эти названия, заказчик понимает, какие сведения он изучает. Копировать ответ целиком и разбирать его самостоятельно необязательно. Для руководителя достаточно кода, объяснения его смысла и связи с конкретным обращением.

Принят запрос или выполнено нужное действие?

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

Техническую запись готовит исполнитель: он сохраняет код ошибки, пояснение, HTTP-статус и название вызванного метода, а затем выбирает фрагмент, по которому можно восстановить передачу обращения, не раскрывая доступы к CRM и не отправляя посторонние клиентские сведения. Метод здесь — конкретное действие, которое интеграция запросила у Битрикс24. Его название связывает ошибку с этим действием. Заказчик не выбирает исправление по коду. Он спрашивает, что остановилось и как это будет восстановлено.

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

На каком участке прекратилась передача обращения?

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

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

Для исправления полезно получить причину, изменяемый участок и способ вернуть потерянные обращения. Восстановление новых отправлений и восстановление прежних заявок — отдельные работы. Отделу нужны оба результата, если данные действительно пропали. Иначе новые карточки появятся, а старые клиенты останутся без ответа. У ответственного сохраняется список обращений, судьба которых пока не установлена.

Какой ответ завершает задачу

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

Итоговое сообщение исполнителя должно быть понятно человеку, который работает с заявками: что изменено, какое обращение использовали для сравнения и кто возобновляет обычную работу отдела, а при повторном сбое — какие сведения снова сохранить и кому передать их для разбора. Сценарии приёмки и признаки успеха собраны в статье «Тестирование CRM». Наблюдение за повторными сбоями — отдельная задача. Её можно описать по правилам мониторинга обмена. Для диагностики интеграции в ШТАБ ИТ отправляют исходное описание обращения и известный состав связи, чтобы начать разговор с участка, где действительно потерялся результат.

Какие сведения по этому обращению подтверждают причину и как вы проверите восстановление передачи? Этот вопрос связывает ответ подрядчика с заявкой, которую отделу предстоит обработать.