Пропущенные звонки: авто-SMS с реальным сроком отгрузки вместо шаблона
Вебхук облачной телефонии → поиск клиента и его заказов в двух магазинах Shopify → SMS с настоящим статусом отгрузки. Плюс страница «Пропущенные» в CRM: кто звонил, что у него в заказах и готовый текст ответа.
Покупатель звонит в свой рабочий день — а это ночь у поддержки
US-бренд товаров для активного отдыха, два магазина на Shopify, команда поддержки в другом часовом поясе. Покупатель набирает номер в середине своего рабочего дня — в этот момент у команды вечер или ночь. Около 70% входящих оставались без ответа.
Пропущенные нигде не собирались. Утро начиналось не со списка, а с «простыни» уведомлений в приложении телефонии: медиана 5 за ночь, в пиковые дни доходило до 25. Разобрать эту ленту руками — отдельная работа, которую никто не делал системно.
Самая частая тема звонка — «где мой заказ». То есть люди звонили именно потому, что не видели статуса: дорогой товар, длинный срок производства, а в письмах и в личном кабинете — тишина.
Встроенный автоответ телефонии добивал: ночным звонящим уходило дневное «мы скоро перезвоним», а на одной из линий тумблер рабочих часов был вовсе выключен — то есть шаблон уходил всегда и всем.
Вебхук → заказ в Shopify → SMS с настоящим сроком
Приёмник вебхуков call.completed
на стороне CRM: проверка подписи, отсечение лишних типов событий, защита от повторной
обработки одного и того же звонка (иначе клиент получает два перезвона), запись в журнал.
Дальше по номеру звонящего поднимается клиент и его заказы в обоих магазинах — и собирается ответ.
call.completed от облачной телефонии: HMAC-подпись, фильтр типов события, дедуп по id звонка
Номер звонящего → покупатель и его заказы в двух магазинах Shopify
От «реальный срок отгрузки» вниз до нейтрального запасного варианта
Тихие часы, кулдаун по номеру, ограничение частоты, режим черновика
Страница «Пропущенные»: кто звонил, его заказы, готовый текст, отметка «разобрала»
Главная находка: даты отгрузки в заказе нет
Ключевой вопрос всего контура — откуда взять срок, который не стыдно отправить покупателю. Оказалось, что календарной даты отгрузки в заказе Shopify нет нигде. Проверены и отброшены четыре других источника — ни один не даёт обещанный клиенту срок.
Единственный носитель обещания — название тарифа доставки, выбранного на чекауте: именно там покупатель видел срок и согласился на него. Из этой строки и считается дата. Это тот случай, когда две недели работы упираются в одно проектное решение, и его нужно найти до того, как писать код.
Лестница ответа: от полезного к запасному
Ответ формируется ступенями — от максимально конкретного к нейтральному, и ни одна ступень не имеет права соврать:
- клиент и заказ найдены, обещанная дата в будущем → называем дату
- обещанная дата уже прошла → дату НЕ повторяем, честно пишем, что уточняем со складом
- заказ есть, срока определить нельзя → пишем про заказ без выдуманных обещаний
- клиент по номеру не найден → нейтральный ответ, звонок уходит в очередь на человека
Правило «просроченную дату не повторяем» проверено на исторической выгрузке (более 11 тыс. заказов): ни один старый застрявший заказ не получает будущей даты.
Предохранители на отправке
Авто-SMS — это то, что уходит от имени бизнеса без человека в контуре. Значит, ограничители важнее самой генерации:
- тихие часы: отправка только в окне 11:00–21:00 по Нью-Йорку — безопасно для всех континентальных поясов США; Аляска и Гавайи считаются отдельно
- кулдаун по номеру — повторный звонок не превращается в поток сообщений
- ограничение частоты на контур в целом
- режим черновика: всё считается и логируется, но наружу не уходит — и отдельный явный флаг боевой отправки
Страница «Пропущенные» в CRM
Автоответ снимает первое касание, но разбирать звонки всё равно человеку. Вместо ленты
уведомлений — одна страница: кто звонил и когда, номер ссылкой
tel:,
найденный клиент, его заказы с состоянием («не отгружен · 82 дня»),
готовый текст ответа и отметка «разобрала».
Отдельно заложена деградация вместо падения: битая строка очереди не роняет страницу, а сбой чтения пишет «очередь не прочиталась», а не «звонков нет». Разница принципиальная: во втором случае операционист спокойно закрывает вкладку и уходит.
Ничего лишнего — контур должен пережить ночь без дежурного
Приёмник вебхуков и HMAC-проверка подписи без веб-фреймворка
Вебхуки звонков, SMS API, транскрипты голосовой почты
Поиск покупателя по номеру и его заказов в двух магазинах
Текст ответа под конкретный заказ, а не подстановка в шаблон
Сервис приёмника, автоперезапуск, журнал
Свыше 100 тестов на контур: ступени ответа, тихие часы, дедуп, парсинг события
Сначала разбор данных, потом код
пропущенных в месяц — задача оказалась в 1,6 раза больше исходной оценки
пропущенных уже имеют текстовую расшифровку голосовой почты — готовый ответ на «чего хотел человек»
сообщений стали односегментными после правки на один символ
Работа началась не с кода, а с выгрузки телефонии. Разбор показал, что задача в 1,6 раза больше исходной оценки, что 29% пропущенных уже имеют расшифровку голосовой почты — и этот канал не использовался вообще, — и что 36% клиентских SMS оставались без человеческого ответа. Три факта, которых не было ни в одном отчёте.
Попутно починены три поломки, без которых контур был мёртв
- поиск клиента падал на несовпадении сигнатур — каждый звонок считался «клиент не найден»
- разбор события брал не тот уровень вложенности и молча выбрасывал любой пропущенный
- номер звонящего искался в поле, которого в вебхуке нет
Ни одна из трёх не была видна снаружи: сервис работал, логи писались, SMS не уходили.
Отдельная находка — деталь на один символ с прямым влиянием на счёт за SMS: длинное тире в шаблонах выводило сообщение за пределы базового алфавита и переводило его в двухбайтную кодировку, из-за чего 100% сообщений уходили минимум в два сегмента. Замена длинного тире на дефис делает односегментными 62%.
Владелец бизнеса включил боевую отправку, первые SMS доставлены. Каждый пропущенный звонок теперь попадает в очередь в CRM и получает ответ с настоящим статусом — а не дневное «мы скоро перезвоним» в три часа ночи.
Где ещё ложится та же методология
Это не «автоответчик». Это типовая задача «событие в канале связи → подтягиваем контекст клиента из учётной системы → отвечаем фактом, а не шаблоном». Та же архитектура применима везде, где обращения приходят вне рабочих часов:
- → Интернет-магазин с длинным сроком доставки — «где мой заказ» закрывается статусом из учётки, а не звонком менеджера
- → Сервис и ремонт — пропущенный звонок → SMS со стадией заказ-наряда и реальной готовностью
- → Клиники и салоны — звонок вне часов приёма → подтверждение записи или ближайшее окно из расписания
- → Бизнес с покупателями в другом часовом поясе — ночная смена заменяется контуром, который знает факты о заказе
- → Любой входящий канал — почта, мессенджер, форма: меняется только источник события, лестница ответа и предохранители остаются
- Приёмник вебхуков с проверкой подписи, фильтром типов событий и защитой от повторной обработки
- Лестница ответа с явным запретом называть просроченную дату — обкатывается на исторической выгрузке до запуска
- Набор предохранителей отправки: тихие часы по поясу клиента, кулдаун по номеру, режим черновика, явный флаг боевого режима
- Страница-очередь с готовым текстом ответа и деградацией вместо падения: «не прочиталось» никогда не показывается как «пусто»
Если у вас копятся пропущенные — сначала замер, потом автоматизация
Начинаю с выгрузки из вашей телефонии: сколько пропущено на самом деле, о чём звонят, что уже лежит в неиспользованных каналах. Дальше — контур авто-ответа с фактами из вашей учётной системы. Срок в этом кейсе — около двух недель от разбора данных до первых доставленных SMS.
Аудит за 5 000 ₽ — с конкретным отчётом и сметой
Расскажу что внедрить в вашем бизнесе в первую очередь, какая будет окупаемость, и нужен ли вообще AI для вашей задачи (иногда — нет).
Или просто напишите свой вопрос — отвечу в течение 2 часов