Как не потерять заявку, когда клиент написал вне рабочего времени

Короткий ответ: как не потерять заявку вне рабочего времени

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

Этот процесс начинается на надёжном входе, описанном в статье про единую очередь заявок. Он не заменяет AI-квалификацию и не является follow-up: ночью система фиксирует обращение и готовит первую передачу, а повторные касания после молчания клиента относятся к отдельному сценарию.

Процесс от ночного сообщения до владельца заявки

Обработчик принимает событие и определяет не просто «час на сервере», а бизнес-календарь нужного подразделения. Одна компания может обслуживать регионы в разных часовых поясах, иметь дежурную линию для аварий и обычный отдел продаж с графиком 9:00–18:00. После выбора календаря процесс принимает решение: передать дежурному сейчас, отправить первичный ответ и ждать уточнение либо поставить готовую заявку в очередь начала смены.

Девять этапов без разрывов

1. Принять событие канала и проверить идемпотентный ключ.
2. Связать сообщение с контактом или создать временное обращение.
3. Определить команду, календарь, часовой пояс и тип исключения.
4. Проверить, допустим ли автоматический первичный ответ в этом канале.
5. Отправить подтверждение с реалистичным временем реакции.
6. Задать один-два разрешённых вопроса, если без них нельзя маршрутизировать.
7. Рассчитать приоритет детерминированными правилами и зафиксировать основание.
8. Назначить очередь, владельца смены и срок человеческой реакции.
9. Подтвердить передачу и контролировать заявку до принятия менеджером.

Первичный ответ: подтвердить получение и настроить ожидания

Хороший первичный ответ содержит четыре элемента: подтверждение получения, честное описание текущего режима, время следующего действия и способ сообщить о критичности. Например: «Получили сообщение. Отдел продаж начнёт работу в 09:00 по Москве; менеджер ответит до 10:00. Если вопрос связан с остановкой действующего сервиса, выберите “авария” и укажите номер договора».

Чего нельзя обещать

Не пишите «менеджер уже подключается», если заявка лежит в очереди до утра. Не называйте точное время ответа без календаря и контроля очереди. Не используйте фразу «мы работаем 24/7», если ночью доступен только бот. Ложное ожидание увеличивает раздражение сильнее, чем честный срок.

Один ответ на одно событие

Провайдеры могут повторно доставлять webhook, поэтому первичный ответ должен иметь отдельный идемпотентный ключ. Повтор сообщения не создаёт второе приветствие и вторую заявку. Telegram повторяет неуспешные webhook-запросы, Gmail использует Pub/Sub и историю изменений, Microsoft Graph также применяет повторную доставку при ошибках. Сначала сохраняйте событие, затем отправляйте ответ.

Уточнение задачи: только то, что влияет на передачу

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

Граница с AI-квалификацией

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

Регистрация: карточка должна появиться до утра

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

Если CRM недоступна, заявка получает статус pending_crm_sync и остаётся в retry-очереди. Клиентский ответ можно отправить только после устойчивого сохранения события. После восстановления CRM используется тот же ключ операции, чтобы не создать дубль.

Приоритет: правила важнее эмоциональности текста

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

Передача менеджеру: уведомление ещё не означает принятие

В начале смены система создаёт задачу конкретной очереди или сотруднику по расписанию. Пакет передачи включает исходное обращение, ответы на уточнения, карточку клиента, причину приоритета, обещанный срок и все автоматические сообщения. Менеджер должен подтвердить принятие. До подтверждения владельцем остаётся очередь, а не абстрактный «отдел продаж».

Что происходит при непринятии

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

Контроль SLA с рабочим календарём

Срок реакции рассчитывают не простым добавлением часов. Нужны календарь команды, выходные, праздники, часовой пояс клиента и правила паузы. Заявка в 23:00 может иметь обещание «до 10:00 следующего рабочего дня», а договорный аварийный канал — 15 минут независимо от календаря. Храните как абсолютное время дедлайна, так и правило, по которому оно получено.

Разделяйте три таймера

• Time to acknowledge — от получения до автоматического подтверждения.
• Time to human acceptance — до подтверждения менеджером или дежурным.
• Time to first meaningful response — до содержательного ответа человеку.

Быстрый бот не улучшает последний показатель автоматически. Отчёт должен показывать все три времени отдельно.

Архитектура решения и движение данных

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

Надёжность подписок и webhook

Gmail требует продлевать watch и допускает задержанные или пропущенные уведомления, поэтому нужен периодический history.list. Microsoft Graph имеет жизненный цикл подписок и специальные уведомления о пропущенных событиях. Для Telegram проверяйте секрет webhook и подтверждайте событие только после устойчивого сохранения. Эти различия скрываются за общим контрактом заявки, но не игнорируются.

Ошибки, ограничения и безопасный fallback

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

Правила безопасной деградации

• при недоступности AI использовать короткий статический ответ и обычные правила маршрутизации;
• при недоступности CRM сохранять обращение в локальной очереди и повторять синхронизацию;
• при неизвестном календаре не обещать точное время, а направить событие дежурному администратору;
• при неоднозначной критичности повышать приоритет на ручную проверку, но не сообщать клиенту о подтверждённой аварии;
• при сбое уведомления контролировать очередь по дедлайну, а не надеяться на один push.

Персональные данные и ночные уведомления

Ночная заявка может содержать телефон, email, договорные сведения и описание инцидента. Применяйте минимизацию, разграничение доступа и сроки хранения с учётом применимого законодательства, включая 152-ФЗ для российского контура. Не пересылайте полный текст обращения в общий чат, если сотрудникам достаточно ссылки на защищённую карточку и краткого сигнала.

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

Что журналировать для разбора инцидентов

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

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

Как измерить качество ночной обработки

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

Расчётный сценарий без выдуманного кейса

Предположим, компания получает 300 ночных обращений в месяц. До автоматизации 8% не попадают в CRM или обнаруживаются с опозданием — 24 заявки. После запуска измеряется не «ответил бот», а подтверждённая регистрация и принятие менеджером. Если необъяснимо потерянных обращений становится 1%, процесс сохраняет контроль над 21 заявкой. Денежный эффект зависит от конверсии и маржи, поэтому его считают на собственных данных, а не умножают все сохранённые обращения на средний чек.

В затраты входят интеграции, дежурные правила, поддержка календарей, обработка конфликтов и мониторинг. Полную модель полезно сверить с подходом к ROI AI-автоматизации.

Пошаговый план внедрения

1. Собрать baseline. Выгрузить ночные обращения за 4–8 недель и сверить каналы с CRM.
2. Описать календари. Зафиксировать команды, часовые пояса, праздники, дежурства и исключения.
3. Утвердить ответы. Подготовить короткие тексты без ложных обещаний для каждого типа обращения.
4. Настроить регистрацию. Сохранять событие до ответа, применять идемпотентность и retry.
5. Добавить правила приоритета. Начать с договорных и проверяемых сигналов, AI использовать только для извлечения признаков.
6. Запустить теневой режим. Не отправлять ответы клиенту, а сравнить решения системы с работой утренней смены.
7. Включить один канал. Проверить принятие, эскалацию, календарь и отчётность до расширения.
8. Контролировать обещания. Еженедельно разбирать нарушения SLA и ошибки приоритета.

Как провести теневой запуск

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

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

Роли и ответственность

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

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

Критерий готовности

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

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

Нужен ли AI для первого ночного ответа?

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

Можно ли обещать ответ утром?

Да, если система знает календарь команды и контролирует передачу. Лучше указать конкретный рабочий интервал, который реально измеряется.

Что делать, если клиент пишет несколько раз?

Связать сообщения с одним обращением, обновить контекст и не отправлять повторное приветствие. Новая критичная информация может изменить приоритет.

Нужно ли создавать сделку в CRM ночью?

Не обязательно. Можно создать обращение или лид, а решение о сделке оставить правилам воронки и менеджеру.

Как учитывать разные часовые пояса?

Хранить календарь команды и часовой пояс клиента отдельно. Обещание формулировать однозначно, при необходимости указывая часовой пояс.

Что считать потерянной заявкой?

Подтверждённое событие, для которого нет объяснимого результата: регистрации, дубля, retry, карантина или принятия менеджером.

Стоит ли ночью задавать вопросы о бюджете?

Только если это действительно влияет на срочную маршрутизацию. Полную квалификацию лучше не смешивать с сохранением обращения.

Чем этот сценарий отличается от follow-up?

Ночной контур обрабатывает первое входящее сообщение и передаёт его человеку. Follow-up запускается позже, когда требуется повторное касание по уже существующей сделке.

Обсудить сценарий