Service Desk для логистики: техническое задание на пилот
Клиент спрашивает о задержке отгрузки. Менеджер ищет переписку, уточняет статус у логиста и передаёт вопрос дальше. Для пилота Service Desk нужно описать весь этот путь: как обращение связывается с отгрузкой, кто отвечает клиенту и когда вопрос считается решённым.
· BIOCARD Tech
В BIOCARD Tech мы используем Service Desk, где обращение ведётся как дело: клиент, отгрузка, срок, ответственный и доказательства. Система пересчитывает сроки и поднимает эскалацию, ИИ готовит черновик ответа, а сотрудник проверяет его и отправляет клиенту. Клиенты и сделки остаются в CRM. Ниже — рабочая заготовка задания на пилот такого процесса.
Начните с одного типа обращений
Выберите повторяющийся сценарий: например, запрос статуса задержанной доставки или поиск документов по отгрузке. Зафиксируйте, откуда приходит вопрос, что нужно узнать для ответа и кто вправе закрыть дело. Отдельно опишите ситуации, которые требуют решения руководителя.
Для первого разбора достаточно обезличенных примеров обращений, образца карточки отгрузки и текущего порядка работы. По ним проще увидеть границы задачи и недостающие данные.
Опишите пять переходов от вопроса к решению
- Поступление. В каком канале появился вопрос и какое событие запускает отсчёт срока? Если одна переписка содержит несколько отгрузок, опишите, как сотрудник разделяет вопросы.
- Привязка. По какому номеру или набору признаков находится отгрузка? Если найдено несколько вариантов, привязку должен проверить сотрудник.
- Назначение. Кто владеет делом и кто его подменяет? Кому передать вопрос, если для ответа требуется другой отдел?
- Ответ. Какие статусы, документы и подтверждения нужны? ИИ может подготовить черновик по доступной истории; сотрудник проверяет факты и отправляет ответ.
- Закрытие. Что подтверждает решение: отправленный документ, объяснение задержки, согласованное действие? Укажите, кто принимает результат и как обработать повторное обращение.
Эта схема становится основой для настройки. Конкретные каналы, поля и варианты интеграции нужно проверить на техническом разборе.
Согласуйте источники данных и обмены
Для каждого поля запишите источник: номер отгрузки приходит из TMS, клиент — из CRM, подтверждающий документ — из согласованного хранилища. Назначьте владельца справочников и опишите, как обнаружить устаревший статус. Если системы используют разные номера, понадобится правило сопоставления.
Начальный пакет может содержать образцы выгрузок и описание доступных интерфейсов. Постоянный обмен, права записи и обработку сбоев согласуйте отдельно. Наличие готового Service Desk не означает, что любая интеграция уже настроена для вашей системы.
Определите состав доказательств
Укажите, что должно остаться в деле после ответа: исходный вопрос, связь с отгрузкой, использованный статус, документ и решение сотрудника. Отделите исходные сведения от предположений ИИ: неизвестную причину задержки нельзя превращать в установленный факт.
Включите в приёмку разбор одного закрытого дела другим сотрудником. Он должен понять, на основании чего был дан ответ и какое действие согласовано. Состав досье и права доступа входят в обсуждение настройки.
Разведите срок реакции и срок решения
Первый содержательный ответ и окончательное решение — разные события. Автоматическое уведомление «обращение принято» полезно, но само по себе не означает, что сотрудник разобрал вопрос.
В задании укажите событие старта, рабочие часы, ответственного за контроль и условия эскалации. Если срок зависит от ожидания документов или ответа другого отдела, опишите это отдельно. Поддержку нужных календарей и правил согласуйте до пилота. Значения сроков берите из своих обязательств и процесса, а не из универсального шаблона.
Договоритесь, как примете результат
До запуска зафиксируйте исходное состояние выбранного процесса. Для пилота можно согласовать такие проверки:
- обращения связаны с правильной отгрузкой; неоднозначные случаи видны сотруднику;
- у каждого дела есть ответственный и понятный следующий шаг;
- срок реакции измеряется до первого содержательного ответа сотрудника;
- просроченные дела считаются на согласованный момент вместе с общим числом дел;
- по закрытому делу можно восстановить вопрос, действия, ответ и подтверждения;
- черновики ИИ проверяет человек; ошибочные предложения учитываются при разборе.
Сравнивайте одинаковый тип обращений и одинаковые правила измерения до и во время пилота. Целевые значения согласуйте заранее. Если история неполная, первым результатом может стать надёжный учёт; обещать ускорение до измерений было бы преждевременно.
Чек-лист задания на проект
Для предметного обсуждения подготовьте:
- Процесс: какой тип обращений запускаем первым и что входит в его границы.
- Объём: обращения за обычный и пиковый день, число пользователей и подразделений.
- Каналы и системы: почта, чат, CRM, 1С/TMS; где находятся клиент и статус отгрузки.
- Данные: обезличенные примеры обращений, поля карточки отгрузки, образцы документов.
- Роли: владелец процесса, ответственные, замещение и маршрут эскалации.
- Сроки: отдельно реакция и решение, рабочие часы и события начала отсчёта.
- Приёмка: исходная ситуация, метрика, целевое значение и человек, который подтвердит результат.
- Условия внедрения: требования к размещению, доступам и обменам; ограничения по времени и бюджету, если они уже определены.
Отметьте неизвестные пункты — они станут вопросами первого разбора. По этому пакету команда сможет обсудить объём настройки и интеграций. Оценка проекта требует согласованного состава работ.
Обсудить пилот Service Desk
В форме выберите Service Desk и укажите процесс, объём обращений, текущие системы и критерий результата. Если часть данных ещё не собрана, начните с того, что известно.
Отправить задачу на пилот