ТЗ на обработку заявок: владелец, дедупликация и контроль срока

Определите, что именно считается заявкой

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

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

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

Разделите идентификаторы события и обращения

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

Спецификация CloudEvents использует контекст события, включая источник и идентификатор, для его представления в обмене. Это полезная опора для контракта интеграции, но не готовое правило объединения клиентских потребностей. Два разных события могут относиться к одному обращению, а два обращения одного клиента — требовать независимой работы. Бизнес-правило остаётся частью вашего ТЗ.

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

Назначьте владельца до объявления обработки успешной

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

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

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

Согласуйте сроки с рабочим календарём

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

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

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

Определите повторы и реакцию на неопределённый результат

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

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

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

Дайте сотруднику управляемые исключения

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

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

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

Проверьте полноту процесса на контрольном наборе

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

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

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

Пример контрольной ведомости: событие FORM-001 создаёт обращение A, его повторная доставка связывается с тем же A, а событие FORM-002 с тем же телефоном и другой услугой создаёт обращение B. Уточняющее сообщение MAIL-003 связывается с A только после проверки согласованного признака. Эти учебные идентификаторы не обозначают реальные заявки. В протоколе заранее указаны ожидаемое количество обращений, связи и владельцы. Проверяющий сверяет входной журнал и рабочие карточки, затем убеждается, что повтор не отправил клиенту лишнее подтверждение и не изменил уже принятое ручное решение.

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

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

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

Передайте правила вместе с наблюдением

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

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

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