Автор: команда Baliyants. В статье собран практический подход, который мы используем при настройке операционных процессов, сервисных контуров, клиентских заявок и межотдельских задач.

Чаты удобны для быстрой коммуникации, но плохо подходят для управления обязательствами. В чате легко задать вопрос, но сложно удержать срок, владельца, статус, историю решения и причину задержки. Поэтому в растущей компании рано или поздно появляется ощущение, что все работают много, а результат все равно приходится “проталкивать” вручную.

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

Что такое SLA в операционном менеджменте

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

Хороший SLA не должен быть наказанием. Это способ согласовать ожидания между отделами. Если срок нереалистичен, он будет постоянно нарушаться. Если срок не зафиксирован, каждый отдел будет считать свою норму правильной. Поэтому SLA лучше вводить через наблюдение: сначала посмотреть фактическое время, затем договориться о целевом уровне и только потом включать контроль.

Роли: кто владеет результатом

В любой задаче полезно разделять исполнителя, владельца результата, согласующего и наблюдателя. Исполнитель делает конкретное действие. Владелец отвечает, чтобы результат был получен. Согласующий принимает решение, если есть условия, бюджет, скидка или нестандартный случай. Наблюдатель получает информацию, но не должен тормозить процесс.

Когда эти роли смешаны, появляются типовые сбои. Задача “висит”, потому что исполнитель ждет решения. Руководитель думает, что менеджер контролирует клиента, а менеджер считает, что задача на складе. Бухгалтерия ждет документы, но никто не отвечает за то, чтобы их собрать. Четкое разделение ролей уменьшает такие провалы.

Как перевести задачи из чатов в систему

Начинать нужно не с запрета чатов. Чат остается каналом обсуждения, но итоговое обязательство должно жить в системе: CRM, таск-трекере, Business OS или другой рабочей среде. Ключевое правило: если у задачи есть срок, ответственный и влияние на клиента или деньги, она не должна существовать только в переписке.

Для переноса нужны минимальные поля: название задачи, связанный объект, ответственный, срок, статус, приоритет и причина блокировки. Связанный объект особенно важен. Задача должна быть привязана к клиенту, сделке, заказу, объекту, заявке или документу. Тогда история не распадается на отдельные сообщения.

Рабочая схема статусов

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

Отдельно стоит фиксировать блокировки. “Ждем клиента”, “ждем документы”, “нет товара”, “нужно решение руководителя”, “ожидаем оплату” — это не просто комментарии. Это причины, по которым процесс теряет время. Когда причины блокировок видны в отчете, руководитель может улучшать систему, а не разбирать каждую задержку вручную.

Эскалация без драматизации

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

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

Пример внедрения

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

После настройки процесса каждая заявка стала карточкой с объектом, типом работ, SLA, ответственным инженером и статусом. Аварийные обращения получили отдельный срок реакции. Если инженер не принимал задачу вовремя, диспетчер видел сигнал. Если требовались материалы, задача переходила в блокировку с причиной. Через несколько недель стало понятно, какие клиенты и типы работ чаще всего создают просрочки.

Метрики, которые стоит смотреть

Доля задач, закрытых в срок.
Среднее время первого ответа.
Количество задач без ответственного.
Количество задач без следующего шага.
Причины блокировок и просрочек.
Нагрузка по ответственным и отделам.
Повторяющиеся задачи, которые стоит автоматизировать.

Не нужно превращать метрики в панель из пятидесяти графиков. Для старта достаточно 5-7 показателей, которые показывают управляемость процесса. Главное — смотреть их регулярно и принимать решения: менять правила, перераспределять нагрузку, уточнять SLA, автоматизировать повторяющиеся действия.

Что может пойти не так

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

Еще один риск — назначать слишком много ответственных. У задачи может быть несколько участников, но владелец результата должен быть один. Именно он следит, чтобы процесс не остановился между отделами.

Чек-лист запуска

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

Вывод

SLA и роли нужны не для жесткости, а для ясности. Когда у задачи есть владелец, срок, статус и понятная причина блокировки, компания быстрее решает вопросы и меньше зависит от ручного контроля. Чаты остаются для обсуждения, но управлять результатом должна система.