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