Рабочее время SLA в CRM: почему два часа не всегда до полудня

Клиент пишет в пятницу в 17:30, а обязательство звучит как «ответим в течение двух рабочих часов». Если календарь обслуживания — понедельник–пятница, 09:00–18:00, и никаких исключений не объявлено, то дедлайн приходится на понедельник, 10:30.

Рабочее время SLA в CRM — это накопленное время внутри окон календаря обслуживания, а не астрономические часы. Дедлайн зависит от календаря, момента старта, разрешённых пауз и владельца обязательства. При календаре Пн–Пт 09:00–18:00 и старте в пятницу 17:30 два рабочих часа истекают в понедельник 10:30, если нет исключений.

Клиент пишет в пятницу в 17:30, а обязательство звучит как «ответим в течение двух рабочих часов». Если календарь обслуживания — понедельник–пятница, 09:00–18:00, и никаких исключений не объявлено, то дедлайн приходится на понедельник, 10:30. Это условный расчёт для иллюстрации, а не правовой срок и не обещание конкретного продукта. Вся дальнейшая статья — про то, как сделать такой расчёт проверяемым, а не про то, как «ускорить продажи».

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

Календарь обслуживания как отдельный объект, а не подпись в договоре

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

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

Календарь не должен молча меняться. Любая правка — новая версия с датой начала действия, а не перезапись старой записи. Иначе получится классическая история: обязательство закрыли вовремя по графику, который ввели уже после факта.

Описанные здесь требования — это проект процесса, а не список готовых функций. Конкретные возможности и интеграции проверяются отдельно по опубликованным материалам и документации; на странице агентской CRM «Цифра» можно посмотреть, что заявлено, и обсудить формат задачи «проверить календарь обязательств». Наличие тех или иных связей с учётом, заказами и согласованиями стоит уточнять до запуска, а не после первого спора о дедлайне.

Начало отсчёта: событие, а не первое впечатление

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

Проблема в том, что «увидел» плохо проверяется. Поэтому в рабочем объекте хранят и время поступления, и время назначения, и время первого действия, а стартовой точкой объявляют ровно одну из этих меток. Остальные остаются для разбора. Когда сотрудник говорит «я не видел», это не отменяет старт, но объясняет, почему задача провисела: значит, сломалась маршрутизация, а не календарь.

Второй нюанс — старт вне графика. Сообщение в 23:40 при календаре 09:00–18:00 не запускает два часа ночью. Счётчик стартует, но рабочее время начинает набегать только со следующего открытия окна. Это надо показать в карточке явно: «поступило 23:40, отсчёт рабочего времени начат 09:00». Иначе менеджер утром увидит уже «просрочено» и решит, что система врёт.

Два часа — это сколько в календаре и сколько в настенных часах

Полезно развести две величины, которые постоянно смешивают. Астрономическое время идёт непрерывно. Рабочее время накапливается только внутри окон календаря. Обязательство «два рабочих часа» измеряется во втором, а человек интуитивно считает в первом. Отсюда половина конфликтов.

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

Праздник в понедельник ломает красивый расчёт

Вернёмся к стартовому примеру и добавим исключение. Пятница 17:30, два рабочих часа, календарь Пн–Пт 09:00–18:00. Без исключений дедлайн — понедельник 10:30. Но если понедельник объявлен нерабочим, окно сдвигается: счётчик продолжит набирать время во вторник с 09:00, и дедлайн станет вторник 10:30. Это снова условный расчёт.

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

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

Пауза счётчика: только с основанием и только явная

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

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

Таблица подсказывает, где чаще всего возникает соблазн: пауза без причины. Если интерфейс позволяет поставить её одним кликом и без объяснения, рано или поздно кто-то «приостановит» всё, что горит. Ограничение здесь — не недоверие к людям, а защита от случайного самообмана.

Смена ответственного не обнуляет обязательство

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

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

Отдельно стоит назвать владельца обязательства — роль, которая отвечает за исход, даже если исполнителей несколько. Без владельца задача с несколькими участниками превращается в «все смотрят, никто не двигает». Владелец видит дедлайн, состояние паузы и историю; остальные видят свою часть.

Техническое уведомление, которое приходит после дедлайна

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

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

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

Заказ и обязательство: где они соприкасаются

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

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

Такое разделение помогает и в разборе: когда что-то пошло не так, сразу видно, в каком слое искать причину.

Интерфейс для сотрудника: остаток, причина, следующий шаг

Экран, на котором менеджер работает с обязательством, должен отвечать на три вопроса без перехода по ссылкам. Сколько рабочего времени осталось с учётом календаря. Почему счётчик стоит или идёт. Что сделать дальше, чтобы закрыть обязательство. Всё остальное — вторично.

Полезно показывать не только остаток, но и «сырой» дедлайн в понятном виде: «понедельник, 10:30, календарь Пн–Пт 09:00–18:00, исключений нет». Тогда сотрудник видит логику, а не магическое число. Если действует исключение, оно подписано рядом. Если стоит пауза, видна причина и автор.

Отдельная забота — задачи, стартовавшие вне графика. Им нужна понятная подпись: «отсчёт начнётся в ближайшее рабочее окно». Без неё человек либо паникует, либо игнорирует счётчик. И то и другое плохо.

Трудные исключения: когда правило честнее подкрутить

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

Разумный подход — не менять задним числом календарь и не переписывать историю, а фиксировать отдельную запись об исключении: причина, кто подтвердил, на какое обязательство распространяется. Тогда исходная логика сохраняется, а отклонение объяснено. Это честнее и для клиента, и для внутреннего разбора.

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

Как проверить календарь до запуска

Проверка не требует больших усилий, если делать её на конкретных сценариях. Ниже — практикум с другим примером, не тем, что в начале статьи.

Условный календарь: вторник–суббота, 10:00–19:00, часовой пояс компании. Обязательство — четыре рабочих часа. Проверяем несколько стартов и смотрим, совпадает ли расчёт с ожиданием.

Здесь важно не то, что таблица «правильная», а то, что каждый сценарий можно воспроизвести и сверить. Если расчёт расходится с ожиданием, проблема в календаре, старте или паузе — и её видно до того, как клиент начнёт считать.

Где заканчивается расчёт и начинается решение человека

Календарь и счётчик отвечают на вопрос «когда». Они не решают, что делать с просрочкой, кому звонить и как объясняться с клиентом. Это остаётся за людьми, и подменять это автоматикой опасно: система может аккуратно посчитать дедлайн и так же аккуратно промолчать о том, что клиент ждёт ответа.

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

Один шаг проверки, с которого стоит начать

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

Соседний вопрос разобран отдельно: Время ответа на заявку: почему скорость первого контакта решает продажу. Здесь основной предмет — календарь обязательства, начало и пауза счётчика, исключения и владелец; не часовой пояс обзвона.