Как считать срок в рабочих часах, а не в астрономических
Кратко
Срок в астрономических часах превращает каждое вечернее и пятничное обращение в просрочку, которой не было: команда в это время не работала. Правильный счёт идёт по рабочему календарю службы, с вычетом пауз ожидания клиента и с пересчётом при смене приоритета.
Что ломается при счёте в астрономическом времени
Обращение пришло в пятницу в 17:50, срок решения — 4 часа, служба работает до 18:00 по будням. В астрономическом счёте срок вышел в пятницу в 21:50, и к утру понедельника обращение просрочено на двое суток. Никто ничего не нарушал: команды не было на месте.
Последствие не в кривом числе, а в том, что происходит дальше. Отчёт с постоянной просрочкой перестают читать; операторы перестают верить сроку; приближение срока перестаёт быть сигналом, потому что половина обращений красная всегда. Показатель, нарушаемый по независящим причинам, не управляет ничем.
Три вещи, которые надо описать
1. Рабочий календарь
| Что задать | Пример | Зачем |
|---|---|---|
| Часы обслуживания | Пн–Пт, 09:00–18:00 | Интервал, внутри которого течёт срок |
| Часовой пояс | Пояс службы, а не клиента | Иначе один и тот же срок считается по-разному для разных заявок |
| Выходные | Сб, Вс | Полностью исключаются из счёта |
| Праздники и переносы | Государственный календарь на год | Без них январь и май дают ложные просрочки пачками |
| Обеденный перерыв | 13:00–14:00, если служба реально не работает | Ставить только если перерыв настоящий, иначе это подкрутка |
Календарей может быть несколько: круглосуточный для аварийного приоритета и рабочий для остальных. Это нормально и честно, пока обещание клиенту совпадает с календарём в системе.
2. Паузы ожидания клиента
Оператор спросил уточнение, клиент отвечает через три дня. Эти три дня не должны наказывать службу: она сделала свой ход. Механика:
- Оператор переводит обращение в состояние ожидания ответа — явным действием, а не мысленно.
- Счётчик срока останавливается.
- Ответ клиента снимает паузу автоматически и счётчик возобновляется.
- Если ответа нет, работает напоминание: через день, через три, затем закрытие с уведомлением — но не молча.
Пауза — самый удобный инструмент подкрутки во всей системе сроков, поэтому за ней нужен один встречный замер: доля обращений, проведших в ожидании клиента больше половины своей жизни. Если она растёт, ожидание используют как паркинг.
3. Пересчёт при смене приоритета
Обращение завели обычным, через два часа выяснилось, что оно аварийное. Вопросов два: от какого момента считать новый срок и что делать, если новый срок уже вышел.
Каноничное решение: срок пересчитывается от исходного создания обращения по новому приоритету. Если он при этом уже вышел — обращение немедленно становится просроченным и попадает в эскалацию. Это неприятно и правильно: проблема была аварийной с самого начала, просто её не распознали, и человек всё это время ждал.
Противоположный вариант — считать новый срок от момента смены приоритета — делает повышение приоритета бесплатным и заодно даёт способ обнулять просрочку переключением туда-обратно.
Порядок внедрения
- Опишите рабочий календарь службы и внесите праздники на год вперёд.
- Сообщите часы клиентам — на сайте, в подписи писем, в автоответе вне часов.
- Задайте сроки по приоритетам в рабочих часах: например, 4 рабочих часа, 8 рабочих часов, 3 рабочих дня.
- Включите состояние ожидания клиента и правило автоснятия паузы по входящему сообщению.
- Включите напоминание до выхода срока: на 75 % от срока, а не по факту нарушения.
- Отдельно опишите поведение обращений, пришедших вне часов: отсчёт с начала ближайшего рабочего интервала, автоответ с названными часами.
Где это задаётся в системе — Настройка SLA, приоритетов и крайнего срока.
Как проверить, что заработало
Проверка занимает полчаса и делается на живых данных.
- Пятничный тест. Найдите обращение, созданное в пятницу после обеда и решённое в понедельник утром. Посмотрите его срок. Если оно просрочено — календарь не применяется, сколько бы его ни настраивали.
- Праздничный тест. То же самое на обращении вокруг ближайшего прошедшего праздника. Праздники пропускают чаще, чем выходные: выходные заданы правилом, праздники — списком, который забывают обновить.
- Тест паузы. Возьмите обращение, где клиент молчал больше суток. Убедитесь, что эти сутки вычтены. Затем посмотрите долю обращений, где пауза заняла больше половины срока жизни.
- Тест приоритета. Повысьте приоритет у тестового обращения и убедитесь, что срок пересчитался от создания, а не от момента правки.
- Сверка с обещанием. Прочитайте, что написано клиенту о часах работы, и сравните с календарём в системе. Расхождение здесь — это не техническая ошибка, а невыполнимое обещание, и находят его обычно в момент конфликта.
Признак, что всё сделано верно: доля просроченных перестаёт скакать по дням недели. Пока понедельник систематически хуже вторника, считается астрономическое время, а не рабочее.
Связанные статьи
- Как настроить приоритеты заявок, чтобы ими пользовались
- Как считать время первого ответа и не обманывать себя
- Настройка SLA, приоритетов и крайнего срока
Нужна поддержка, которая так и работает?
TehProf Support собирает обращения из WhatsApp, Telegram, почты и виджета в одну очередь, считает сроки по SLA и показывает, где служба проседает.