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