Клиент ждёт ответа: контроль сроков обработки заявок через n8n

MAATRIX · 17 октября 2026 · 8 мин чтения

Заявку приняли в 17:54. Менеджер собирался ответить после короткого звонка, потом пришло срочное письмо, а утром обращение оказалось ниже новых. Никто сознательно не игнорировал клиента. Просто у намерения «не забыть» не было ни срока, ни ответственного за проверку.

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

Сначала договоримся, что значит «ответили»

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

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

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

Два часа — не всегда сто двадцать минут

Допустим, отдел работает с девяти до восемнадцати по будням и обещает ответить за два рабочих часа. Обращение в пятницу в 17:30 должно получить срок в понедельник в 10:30, если понедельник рабочий. Прибавление двух часов к времени создания даст пятницу 19:30 и обеспечит тревожное уведомление пустому офису.

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

Время событий сохраняйте в однозначном формате с часовым поясом, а для расчётов удобно использовать UTC. Показывайте срок сотруднику в часовом поясе его команды. Строка «до 10:30» без указания зоны прекрасно выглядит, пока отдел продаж не появляется в другом городе.

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

Почему здесь удобнее периодическая проверка

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

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

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

Собираем проверку в интерфейсе

Сначала создайте Manual Trigger и подключите чтение тестовых заявок через штатный узел CRM либо HTTP Request. В Edit Fields сопоставьте поля выбранной системы с вашей схемой. Если нужное событие ответа не доступно напрямую, уточните API истории действий. Не подменяйте его случайным полем «дата изменения»: карточку мог обновить другой робот.

В PostgreSQL сохраните рассчитанные сроки и версии ожидания. Для параметров запросов используйте механизм Query Parameters узла Postgres, а не склеивание SQL с именами клиентов. Обновляйте существующую запись по устойчивому ключу и не сбрасывайте отметки уже отправленных уведомлений без причины.

Во втором workflow поставьте Schedule Trigger. Для пилота можно проверять очередь раз в несколько минут; это означает такую же возможную задержку обнаружения просрочки. Установите часовой пояс workflow и после проверки опубликуйте его. Расписание без публикации не превращается в работающего дежурного.

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

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

Напоминание должно помогать действовать

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

Не пишите «менеджер нарушил срок», если система пока видит только отсутствие зарегистрированного действия. Возможно, звонок состоялся, а интеграция телефонии задержалась. Формулировка «в CRM не зафиксирован ответ» точнее и не превращает технический сигнал в обвинение.

Кнопка «взял в работу» полезна как подтверждение внимания, но не должна автоматически означать «клиенту ответили». Можно временно отложить следующее напоминание с комментарием и новым сроком. Сохраняйте автора изменения: иначе кнопка станет универсальным способом убрать уведомление до следующей недели.

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

Что происходит при сбое

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

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

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

Приёмка по календарю и по людям

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

Проверяйте право ставить паузу и требуйте пояснение для длительных остановок. Иначе любой неудобный дедлайн можно бессрочно отправить в «ожидание клиента». В отчёте полезно показывать рабочее время ожидания и полное календарное время отдельно: формально соблюдённый норматив не делает недельную переписку приятной для человека.

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

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

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

Для n8n, небольшой PostgreSQL и внешней CRM стартовым ориентиром может быть VPS MAATRIX Uab Start с 4 GB RAM. Если на сервере уже работают другие процессы, измерьте память и длительность проверки; Heka Standard с 8 GB даст больше запаса для пилота. Используйте поддерживаемую Ubuntu или Debian, резервируйте таблицу сроков и ключи доступа отдельно от публичных файлов.

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