Интеграция снова передаёт формы с сайта в CRM, мониторинг показывает нормальную работу, а технический чат закрывает инцидент. Через день руководитель находит обращения, которые пришли во время сбоя и так и не получили владельца. Ошибка исчезла, но клиенты не вернулись в очередь автоматически.
У инцидента две линии завершения. Техническая команда устраняет причину и подтверждает стабильную передачу новых данных. Владелец процесса определяет затронутые случаи, возвращает их сотрудникам и проверяет продолжение. Если закрыть только первую линию, зелёный статус системы создаёт ложное ощущение законченной работы.
Граница инцидента начинается с периода и канала
Сначала нужно определить, когда нарушилась передача, какие входы она затронула и какие записи могли остаться только в исходной системе.
Точное время первой ошибки редко известно сразу. Возьмите интервал от последнего подтверждённого успешного события до первого устойчивого результата после исправления. Включите небольшой запас по краям, чтобы не потерять случаи, которые обрабатывались с задержкой или повторной попыткой.
Перечислите каналы и типы данных отдельно. Форма тест-драйва могла перестать создавать сделку, а звонки продолжали поступать. Чат мог сохранить сообщение, но не назначить филиал. Формулировка «не работала интеграция» слишком широкая для восстановления и слишком узкая для поиска реальных последствий.
Исходная система должна стать временным реестром поиска. Сопоставьте её события с CRM по устойчивым признакам и отметьте отсутствующие либо неполные записи. Не запускайте безусловный повторный импорт всего периода: он способен создать дубли и скрыть исходный масштаб проблемы.
Техническое исправление подтверждают новыми событиями
Причина считается устранённой после контролируемой проверки полного маршрута и наблюдения за следующими реальными передачами.
Тестовый запрос проходит те же шаги, что обычное обращение: появляется в источнике, передаётся, получает нужные поля и попадает правильному владельцу. Проверка одного ответа сервера недостаточна. Она показывает доступность точки, но не подтверждает преобразование данных и правила маршрутизации.
После теста наблюдайте за ограниченной серией новых событий. Сверяйте количество и содержание на обеих сторонах, учитывая допустимые повторы. Если система использует очередь, проверьте её остаток и ошибки повторной обработки. Только после этого можно говорить, что новые обращения идут устойчиво.
Зафиксируйте причину и изменение простыми словами. Эта запись нужна не только разработчику. Руководитель процесса должен понять, может ли похожая ошибка затронуть другой канал и по какому признаку её заметить раньше. Технический отчёт становится частью профилактики, а не архивом непонятных кодов.
- полный тестовый маршрут
- сверка обязательных полей
- правильный владелец
- наблюдение за новыми событиями
- пустая либо объяснённая очередь ошибок
Затронутые обращения возвращает владелец процесса
Один ответственный собирает список, выбирает безопасный способ восстановления и следит, чтобы каждая карточка получила рабочее продолжение.
Технический специалист знает, какие записи не прошли, но не всегда понимает приоритет клиента и правила филиала. Руководитель продаж или цифрового процесса связывает найденные события с реальной очередью. Он решает, что импортировать повторно, что создать вручную и где требуется проверка дубля.
Карточка после восстановления должна сохранять исходное время и источник. Иначе отчёт покажет обращение как новое, а задержка исчезнет. Добавьте пометку об инциденте и фактический момент возврата в работу. Эти две даты позволяют честно оценить последствия и не обвинять менеджера в задержке до назначения.
Клиенту не нужно рассказывать техническую историю целиком. Менеджер признаёт паузу, отвечает на исходный вопрос и предлагает актуальный шаг. Если ситуация уже изменилась, это сообщают прямо. Попытка сделать вид, что обращение пришло только что, разрушает доверие сильнее, чем спокойное объяснение задержки.
Закрытие подтверждает восстановленный маршрут
Инцидент закрывают после сверки полного списка: новые события проходят, старые возвращены, владельцы назначены, а незавершённые исключения объяснены.
Сводка должна отвечать на четыре вопроса. Сколько событий попало в границу, сколько уже было в CRM, сколько восстановили и что осталось разобрать вручную. Разница не может исчезать под формулировкой «прочее». Для каждого остатка нужен владелец и причина.
Проверьте не только наличие карточки, но и первый рабочий шаг. Импортированная заявка без назначенного сотрудника всё ещё потеряна для клиента. Случай завершается, когда команда приняла его, выполнила уместный контакт или зафиксировала понятную причину завершения.
После закрытия добавьте ранний признак для следующего раза. Это может быть расхождение между числом событий и созданных карточек, рост очереди или отсутствие обязательного поля. Мониторинг не заменяет владельца восстановления, но сокращает период неизвестности и размер будущего списка.
Можно ли просто повторно отправить все события за период?
Только после проверки идемпотентности и правил дублей. Без неё массовый повтор может создать новые карточки и затруднить сверку. Безопаснее сначала построить точный список отсутствующих или неполных случаев.
Кто должен закрывать инцидент интеграции?
Техническую часть подтверждает специалист по системе, а итоговое закрытие принимает владелец бизнес-процесса. Он проверяет, что затронутые обращения получили владельцев и реальное продолжение.
