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