В SLA по CRM нужно согласовать не одно «время ответа», а несколько проверяемых событий: регистрацию, содержательную реакцию, восстановление рабочего сценария и окончательное устранение причины. Для каждого события нужны часы обслуживания, начало отсчёта, ответственный и доказательство выполнения. Универсального срока для любой CRM нет: он зависит от последствий простоя, обходного процесса и возможностей исполнителя.
Ниже — рабочий шаблон для обсуждения с поддержкой. Это методика организации обслуживания, а не опубликованные условия CHECK CRM и не готовый договор. Общий состав работ разобран отдельно в статье о границах сопровождения CRM.
Реакция, восстановление и решение: что считать результатом
- Регистрация: обращение получило номер и время поступления. Автоматическое письмо подтверждает доставку, но не начало диагностики.
- Содержательная реакция: назван исполнитель, подтверждён масштаб проблемы, указан следующий шаг и время следующего сообщения. Именно такое событие рекомендуем использовать для показателя реакции.
- Восстановление: согласованный рабочий сценарий снова выполняется. Это может быть временный обход, если он безопасен, проверен и принят владельцем процесса.
- Устранение причины: постоянное исправление проверено, временный обход снят либо отдельно согласован, оставшиеся ограничения зафиксированы.
Учебный пример. Форма сайта принимает заявки, но интеграция не создаёт сделки. Сотрудник поддержки ответил — это реакция. Команда начала переносить сохранённые обращения вручную по согласованному списку — возможное временное восстановление, если соблюдены сроки обработки и контроль полноты. Исправленная интеграция прошла тест, накопленная очередь разобрана — можно проверять окончательный результат. Эти события не следует отмечать одной датой «закрыто».
Как выбрать время реакции
- Назовите критичные сценарии: приём заявки, звонок, назначение менеджера, выставление документов. Доступность страницы входа ещё не подтверждает работоспособность продаж.
- Определите допустимую задержку для каждого сценария. Учитывайте обещания клиентам и возможность сохранить обращения до восстановления.
- Проверьте, как обнаруживается сбой. Реакция за короткий срок после обращения не помогает, если проблему замечают только на следующий день.
- Согласуйте реалистичный срок с учётом дежурства, доступов и внешних зависимостей. Отдельно определите, когда поддержка обязана дать прогноз восстановления после диагностики.
- Прогоните условное обращение через весь маршрут и проверьте, совпадает ли фактическая работа с регламентом.
Если время восстановления заранее неизвестно, не заменяйте его пустым обещанием «как можно скорее». Зафиксируйте срок первичной оценки, частоту обновления прогноза и действия при его ухудшении. Там, где исполнитель может принять обязательство по восстановлению, укажите его отдельно от срока реакции.
Шаблон приоритетов обращений
Оценивайте влияние на бизнес, срочность и наличие обходного пути. Подход к классификации по последствиям описан в официальном руководстве Atlassian. Таблица ниже — наша заготовка для CRM, а не шкала или нормативы этого поставщика.
| Уровень | Признак и учебный пример | Что согласовать |
|---|---|---|
| P1 — критичный | Остановлен критичный поток, приемлемого обхода нет. Например, обращения не сохраняются ни в CRM, ни в источнике | Канал вызова дежурного; календарь; предел реакции; цель восстановления; интервал статусов; координатор |
| P2 — значимый | Важный сценарий нарушен, но есть ограниченный обход. Заявки сохранены, однако ручной перенос создаёт очередь | Допустимый размер и возраст очереди; сроки реакции и оценки; условие повышения до P1 |
| P3 — локальный | Ограниченная проблема без остановки критичного процесса. Например, ошибка представления отчёта при доступных исходных данных | Рабочие часы; срок реакции; план исправления; проверка с пользователем |
| Запрос на изменение | Нужен новый отчёт или новая логика распределения | Срок оценки, согласование объёма и дата выполнения; отдельная очередь от инцидентов |
Заполните сроки и имена перед использованием таблицы. Один заблокированный сотрудник может оказаться единственным диспетчером заявок — тогда число затронутых пользователей не отражает критичность. И наоборот, неудобство у всей команды не всегда означает остановку продаж.
Приоритет меняется по новым фактам. Если обход перестал справляться, повышайте уровень с указанием времени и причины. Правило пересчёта срока нужно определить заранее: изменение приоритета не должно незаметно стирать уже накопленное ожидание.
Как считать рабочие часы и паузы
Укажите часовой пояс, рабочие дни, перерывы и праздники. Разница между «два часа» и «два рабочих часа» особенно заметна вечером и перед выходными. В системах сервисной поддержки календарь — самостоятельная часть настройки SLA; например, Jira Service Management учитывает расписание и часовой пояс. Это пример реализации, а не требование использовать Jira.
Учебный расчёт, не условия CHECK CRM. Календарь — понедельник–пятница, 09:00–18:00, без перерыва, Europe/Moscow; праздников в рассматриваемом промежутке нет. Обращение зарегистрировано в пятницу в 17:30. При цели реакции два рабочих часа срок наступит в понедельник в 10:30: 30 минут пятницы и 90 минут понедельника. В режиме 24/7 те же два часа истекут в пятницу в 19:30.
Отдельно опишите события старта, паузы и остановки каждого показателя. Такая модель есть в документации об условиях SLA. Для вашего регламента важно определить, какая именно метрика приостанавливается и каким событием возобновляется.
Если требуется информация заказчика, фиксируйте конкретный вопрос, время запроса и получателя. Статус «ждём клиента» без вопроса не объясняет паузу. Внутреннюю нехватку исполнителей не стоит маскировать ожиданием заказчика. Показывайте в отчёте и время по согласованному календарю, и полное время нарушения процесса: второе не исчезает из-за паузы SLA.
Кому писать, если поддержка не отвечает
До первого инцидента заполните цепочку: основной канал регистрации → координатор поддержки → руководитель обслуживания или дежурный → владелец процесса у заказчика. Для каждой роли нужны контакт, заместитель и условие подключения. Канал экстренной связи должен работать при недоступной CRM.
Эскалацию запускают по понятному событию: нет содержательной реакции к согласованному сроку, пропущено обновление статуса, ухудшилось влияние на бизнес или нужен доступ, которым исполнитель не располагает. В руководстве Atlassian по реагированию отдельно подчёркиваются координация и информирование команды. Конкретную цепочку для вашей CRM должны подтвердить её участники.
Передайте номер обращения, время начала, нарушенный сценарий, масштаб, наличие обхода и требуемое действие. Сохраняйте один основной журнал инцидента, даже если срочно позвонили: несколько независимых чатов затрудняют восстановление последовательности событий.
При сбое внешнего сервиса координатор собирает диагностику, регистрирует обращение у поставщика, сообщает его номер и следующий срок проверки. Интегратор не может управлять исправлением чужой платформы, но может отвечать за свои действия и коммуникацию. Не считайте передачу поставщику восстановлением процесса.
Нужна ли отделу продаж поддержка 24/7
Проверьте, что происходит вне рабочего дня. Если ночью идут обращения, которые нигде не сохраняются при сбое, ожидание утра может быть неприемлемым. Если данные надёжно накапливаются, а обработка начинается утром, иногда достаточно мониторинга с дежурством только по критичным событиям. Это решение нужно подтвердить тестом восстановления и возможностями команды.
Разделяйте круглосуточный приём сообщений, обнаружение сбоя, реакцию специалиста и выполнение исправлений. Бот, принимающий заявки ночью, не означает круглосуточной работы инженеров. Для дежурства нужны доступы, полномочия на действия, резервный сотрудник и согласованный порядок привлечения внешних поставщиков.
Сравнивайте стоимость покрытия с последствиями ожидания на данных своего бизнеса. Не распространяйте 24/7 автоматически на консультации и плановые доработки. Рабочие окна для разных уровней можно согласовать отдельно.
Как проверить, что регламент работает
Проведите учебный вызов без отключения рабочей CRM: обычное обращение, критичное сообщение вне основного графика и ситуация ожидания доступа. Предупредите участников о проверке, чтобы она не привела к ненужным изменениям системы.
- Обращение получило номер и сохранило исходное время.
- Приоритет назначен по последствиям; понятен сотрудник, который может его изменить.
- Реакция содержит исполнителя и следующий шаг, а не только автоматическое подтверждение.
- Срок правильно считается на границе рабочего дня; пауза и возобновление видны в истории.
- Запасной контакт получает эскалацию; очередное сообщение приходит даже без готового исправления.
- Восстановление подтверждается контрольным сценарием и принимающим сотрудником; работа над причиной остаётся отдельной задачей, если ещё не завершена.
Для обсуждения сопровождения CRM подготовьте заполненную таблицу приоритетов, календарь и два-три характерных сбоя. Конкретные сроки и границы обслуживания согласуются для выбранного формата. Результат обсуждения — понятный порядок действий, который можно проверить на одном обращении от регистрации до восстановления.