Как считать срок в рабочих часах, а не в астрономических

Кратко

Срок в астрономических часах превращает каждое вечернее и пятничное обращение в просрочку, которой не было: команда в это время не работала. Правильный счёт идёт по рабочему календарю службы, с вычетом пауз ожидания клиента и с пересчётом при смене приоритета.

Что ломается при счёте в астрономическом времени

Обращение пришло в пятницу в 17:50, срок решения — 4 часа, служба работает до 18:00 по будням. В астрономическом счёте срок вышел в пятницу в 21:50, и к утру понедельника обращение просрочено на двое суток. Никто ничего не нарушал: команды не было на месте.

Последствие не в кривом числе, а в том, что происходит дальше. Отчёт с постоянной просрочкой перестают читать; операторы перестают верить сроку; приближение срока перестаёт быть сигналом, потому что половина обращений красная всегда. Показатель, нарушаемый по независящим причинам, не управляет ничем.

Три вещи, которые надо описать

1. Рабочий календарь

Что задатьПримерЗачем
Часы обслуживанияПн–Пт, 09:00–18:00Интервал, внутри которого течёт срок
Часовой поясПояс службы, а не клиентаИначе один и тот же срок считается по-разному для разных заявок
ВыходныеСб, ВсПолностью исключаются из счёта
Праздники и переносыГосударственный календарь на годБез них январь и май дают ложные просрочки пачками
Обеденный перерыв13:00–14:00, если служба реально не работаетСтавить только если перерыв настоящий, иначе это подкрутка

Календарей может быть несколько: круглосуточный для аварийного приоритета и рабочий для остальных. Это нормально и честно, пока обещание клиенту совпадает с календарём в системе.

2. Паузы ожидания клиента

Оператор спросил уточнение, клиент отвечает через три дня. Эти три дня не должны наказывать службу: она сделала свой ход. Механика:

  • Оператор переводит обращение в состояние ожидания ответа — явным действием, а не мысленно.
  • Счётчик срока останавливается.
  • Ответ клиента снимает паузу автоматически и счётчик возобновляется.
  • Если ответа нет, работает напоминание: через день, через три, затем закрытие с уведомлением — но не молча.

Пауза — самый удобный инструмент подкрутки во всей системе сроков, поэтому за ней нужен один встречный замер: доля обращений, проведших в ожидании клиента больше половины своей жизни. Если она растёт, ожидание используют как паркинг.

3. Пересчёт при смене приоритета

Обращение завели обычным, через два часа выяснилось, что оно аварийное. Вопросов два: от какого момента считать новый срок и что делать, если новый срок уже вышел.

Каноничное решение: срок пересчитывается от исходного создания обращения по новому приоритету. Если он при этом уже вышел — обращение немедленно становится просроченным и попадает в эскалацию. Это неприятно и правильно: проблема была аварийной с самого начала, просто её не распознали, и человек всё это время ждал.

Противоположный вариант — считать новый срок от момента смены приоритета — делает повышение приоритета бесплатным и заодно даёт способ обнулять просрочку переключением туда-обратно.

Порядок внедрения

  • Опишите рабочий календарь службы и внесите праздники на год вперёд.
  • Сообщите часы клиентам — на сайте, в подписи писем, в автоответе вне часов.
  • Задайте сроки по приоритетам в рабочих часах: например, 4 рабочих часа, 8 рабочих часов, 3 рабочих дня.
  • Включите состояние ожидания клиента и правило автоснятия паузы по входящему сообщению.
  • Включите напоминание до выхода срока: на 75 % от срока, а не по факту нарушения.
  • Отдельно опишите поведение обращений, пришедших вне часов: отсчёт с начала ближайшего рабочего интервала, автоответ с названными часами.

Где это задаётся в системе — Настройка SLA, приоритетов и крайнего срока.

Как проверить, что заработало

Проверка занимает полчаса и делается на живых данных.

  • Пятничный тест. Найдите обращение, созданное в пятницу после обеда и решённое в понедельник утром. Посмотрите его срок. Если оно просрочено — календарь не применяется, сколько бы его ни настраивали.
  • Праздничный тест. То же самое на обращении вокруг ближайшего прошедшего праздника. Праздники пропускают чаще, чем выходные: выходные заданы правилом, праздники — списком, который забывают обновить.
  • Тест паузы. Возьмите обращение, где клиент молчал больше суток. Убедитесь, что эти сутки вычтены. Затем посмотрите долю обращений, где пауза заняла больше половины срока жизни.
  • Тест приоритета. Повысьте приоритет у тестового обращения и убедитесь, что срок пересчитался от создания, а не от момента правки.
  • Сверка с обещанием. Прочитайте, что написано клиенту о часах работы, и сравните с календарём в системе. Расхождение здесь — это не техническая ошибка, а невыполнимое обещание, и находят его обычно в момент конфликта.

Признак, что всё сделано верно: доля просроченных перестаёт скакать по дням недели. Пока понедельник систематически хуже вторника, считается астрономическое время, а не рабочее.

Связанные статьи

Нужна поддержка, которая так и работает?

TehProf Support собирает обращения из WhatsApp, Telegram, почты и виджета в одну очередь, считает сроки по SLA и показывает, где служба проседает.