Скорость автоматизации и рабочие часы: не писать клиенту в три ночи

Четверг, 03:07. Интеграция со службой доставки отправляет ночную пакетную выгрузку, рабочий процесс в CRM срабатывает — и телефоны 214 клиентов вибрируют одновременно. В 08:40 команда поддержки открывает почту и находит 31 жалобу, девять отписок и одно сообщение: «больше мне не пишите». Процесс отработал ровно так, как его собрали: триггер сработал, сообщение ушло, все записи зелёные. Сломалась не логика цепочки. Сломался час, в который она запустилась.

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

Во сколько обходится сообщение, отправленное в три ночи?

Ночное уведомление не просто будит человека. Оно сообщает ему, какой вы отправитель. Разбуженный клиент не читает сообщение — он отключает уведомления. И отключает не одну рассылку, а весь канал целиком. Счёт за уведомление о доставке, ушедшее в 03:00, оплатит через три недели то самое сообщение о списании, которое было по-настоящему важным.

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

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

Что не ждёт, а что спокойно доживёт до утра?

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

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

Тип сообщения	Терпит ли задержку	Какое ограничение применить
Платёж не прошёл, услуга отключается	Нет	Вне окна, без дневного лимита
Заказ передан в доставку	Да, можно утром	Окно с 08:00 до 21:00
Напоминание о завтрашней записи	Привязано ко времени	Сдвигается раньше, если выходит за окно
Второй шаг цепочки касаний	Да	Окно и дневной лимит на контакт
Анонс акции	Да	Окно и часовой потолок запусков
Внутреннее уведомление команде	Не требуется	Ограничения не нужны

Заполнить эту таблицу один раз по своему списку активных процессов — значит закрыть все будущие споры на эту тему. Без такой классификации каждый в команде расставляет ограничения по своему чутью, и один и тот же клиент получает сообщение из одного процесса в 07:00, а из другого — в 23:40.

По чьим часам строится рабочее окно?

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

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

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

Что делать с шагом, упёршимся в закрытое окно?

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

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

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

На каком уровне задаётся потолок скорости?

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

Поэтому потолок задаётся и на процесс, и на контакт. Потолок на процесс защищает систему от аварии. Потолок на контакт защищает клиента от вас. Это ответы на разные вопросы, и один не заменяет другой.

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

Сколько сообщений в день для одного человека уже много?

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

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

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

Что происходит с отложенными шагами, когда клиент отвечает?

Худший момент любой цепочки — автоматическое «мы так и не получили ответа», ушедшее через два дня после того, как клиент написал «да, мне интересно». Это сообщение говорит ему, что его никто не читает, и разом тратит всё доверие, накопленное предыдущими шагами.

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

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

Как проверить ограничения до публикации?

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

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

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

Где убедиться, что ограничение всё ещё работает?

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

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

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

Значит ли это, что вне рабочих часов лучше молчать?

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

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

Практическая проверка короткая. Разговор начали мы или клиент? Если клиент — ограничения по часам нет, вы отвечаете. Если мы — окно действует.

Заключение

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

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

Частые вопросы

Заблокирует ли рабочее окно срочные сообщения?

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

Потеряется ли процесс, сработавший в нерабочие часы?

Это зависит от сборки. Сообщение, поставленное за шагом ожидания, уйдёт при открытии окна; напоминание, чей момент прошёл, лучше отменить. Решение по каждому шагу даёт лучший результат, чем одно поведение, навязанное всей цепочке.

Считает ли лимит на контакт разные процессы вместе?

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

Упадёт ли конверсия после введения ограничений?

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