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