Ни одно обращение не висит без ответа: SLA под контролем

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

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

Обращения приходят в пять мест сразу: общий ящик поддержки, личная почта менеджера, форма на сайте, чат руководителя. Каждый отвечает из своего окна, и никто не видит очередь целиком. Вопрос «сколько это письмо уже висит?» решается ручным подсчётом по датам в треде.

Просрочка обнаруживается в момент, когда клиент пишет второй раз — уже раздражённым тоном. Срочный сбой лежит рядом с запросом на доработку, потому что приоритет никто не проставил. А когда руководитель спрашивает, какая доля обращений укладывается в регламент, в ответ звучит «обычно успеваем, кроме понедельников».

Отдельная беда — недоверие к метрике. Если таймер крутится, пока команда ждёт от клиента скриншот, просрочки копятся за чужое молчание, и на цифру перестают смотреть вообще.

• Начните с двух типов обращений, а не с восьми. Классификацию легко расширить потом, а сложную схему команда саботирует на второй неделе.
• Держите график дежурств на той же доске — отдельной карточкой с чек-листом. Так новый дежурный видит, что очередь теперь его, без устных договорённостей.
• Норматив первой реакции ставьте заведомо достижимым и ужесточайте по факту. Регламент, который нарушается в половине случаев с первого дня, обесценивается мгновенно.
• В шаблоне ответа клиенту просите сразу всё, что нужно для решения. Два дня уточнений — частая причина просрочки по времени решения.
• Статус «Ждём клиента» должен иметь свой таймер напоминания: иначе заявка зависнет там навсегда и исчезнет из поля зрения.
• Раз в квартал пересматривайте нормативы по данным, а не по интуиции — особенно если выросли объёмы или изменился продукт.

Команда 3–10 человек. Хватит одного проекта, одной формы и двух типов обращений. Дежурство — по неделе, эскалация идёт на руководителя, потому что тимлидов ещё нет. Нормативы можно задать только для первой реакции: время решения на этом масштабе обычно регулируется разговором, а не регламентом.

Отдел 10–50 человек. Появляются линии: первая разбирает типовое, вторая — технику. Типов обращений становится 4–6, у каждого свой норматив. Полезно развести доски по линиям и добавить отчёт по доле в SLA для еженедельной встречи.

Корпорация. Нужны роли и ограниченные доступы к проекту, раздельные ящики под направления, формализованный разбор нарушений. Здесь же честная граница: если требуются сотни индивидуальных SLA по корпоративным договорам со штрафами или клиентский портал с публичным статусом тикета — это задача полноценного helpdesk, а Shtab закроет внутреннюю очередь и контроль сроков команды.