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

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

Определите, что считается обращением

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

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

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

Выберите границы проверки

Установите период, часовой пояс и момент отсечения. Например, каждый рабочий день координатор сверяет события с 00:00 до 24:00 предыдущих суток по московскому времени. Срочные обращения при этом обрабатываются оперативно; ежедневная сверка является дополнительным контролем.

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

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

Что сопоставлять

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

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

Результат сопоставления имеет одно из состояний:

Последние два состояния остаются открытыми до решения. Зелёная отметка «проверено» без результата не объясняет судьбу сообщения.

Заполненный пример одного дня

В источниках за контрольный период найдено 60 входящих событий. Координатор распределил их так:

Баланс: 10 + 15 + 5 + 30 = 60. Категории в этом примере не пересекаются. Для каждого повторного сообщения сохранена связь с исходным запросом.

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

Первоначальная полнота регистрации новых обращений составила 28 / 30 × 100 ≈ 93,3%. После исправления стало 30 / 30 = 100%. В отчёте сохраняются обе величины: исправленное состояние не отменяет факт двух пропусков.

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

Проверьте места, где обращения выпадают из очереди

В документации Zendesk об отложенных обращениях описано, что запрос может ожидать отдельной проверки и ещё не быть обычным тикетом. Это пример причины, по которой основной список не отражает весь входящий поток.

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

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

Отдельно проверяйте исключённые категории. Ошибочная пометка «спам» может сделать баланс идеально сходящимся и одновременно скрыть реального клиента.

Кто выполняет ежедневную сверку

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

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

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

Шаблон контрольного листа

Заполненная строка: «Форма сайта, событие F-081, поступило 14:32. Новая задача. В журнале отсутствует; ошибка передачи. Карточка З-508 создана в 09:20 следующего дня, исходное время сохранено. Ответственный за причину — администратор; повторная проверка канала после исправления».

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

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

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

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

Когда можно считать контроль завершённым

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

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

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

Источники

Все материалы →