Перейти к содержимому
VC
Кейс 4 из 28 · Интернет-торговля · поддержка

Пропущенные звонки: авто-SMS с реальным сроком отгрузки вместо шаблона

Телефония сообщает о пропущенном звонке → система находит клиента и его заказы в двух магазинах Shopify → уходит SMS с настоящим статусом отгрузки. Плюс страница «Пропущенные» в CRM: кто звонил, что у него в заказах и готовый текст ответа.

Отрасль
Интернет-торговля, покупатели в США
Стек
Python · вебхуки телефонии · Shopify API
Сроки
≈ 2 недели
Итог
≈200 пропусков/мес → авто-ответ
01 · Боль

Покупатель звонит в свой рабочий день — а это ночь у поддержки

Бренд товаров для активного отдыха из США, два магазина на Shopify, команда поддержки в другом часовом поясе. Покупатель набирает номер в середине своего рабочего дня — в этот момент у команды вечер или ночь. Около 70% входящих оставались без ответа.

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

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

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

02 · Решение

Вебхук → заказ в Shopify → SMS с настоящим сроком

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

01
Сигнал о звонке

Событие call.completed от облачной телефонии: проверка подписи, фильтр типов события, защита от повторной обработки по номеру звонка

02
Поиск клиента

Номер звонящего → покупатель и его заказы в двух магазинах Shopify

03
Лестница ответа

От «реальный срок отгрузки» вниз до нейтрального запасного варианта

04
Отправка SMS

Тихие часы, пауза между сообщениями на один номер, ограничение частоты, режим черновика

05
Очередь в CRM

Страница «Пропущенные»: кто звонил, его заказы, готовый текст, отметка «разобрала»

Главная находка: даты отгрузки в заказе нет

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

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

Лестница ответа: от полезного к запасному

Ответ формируется ступенями — от максимально конкретного к нейтральному, и ни одна ступень не имеет права соврать:

  • клиент и заказ найдены, обещанная дата в будущем → называем дату
  • обещанная дата уже прошла → дату НЕ повторяем, честно пишем, что уточняем со складом
  • заказ есть, срока определить нельзя → пишем про заказ без выдуманных обещаний
  • клиент по номеру не найден → нейтральный ответ, звонок уходит в очередь на человека

Правило «просроченную дату не повторяем» проверено на исторической выгрузке (более 11 тыс. заказов): ни один старый застрявший заказ не получает будущей даты.

Предохранители на отправке

Авто-SMS — это то, что уходит от имени бизнеса без человека в контуре. Значит, ограничители важнее самой генерации:

  • тихие часы: отправка только в окне 11:00–21:00 по Нью-Йорку — безопасно для всех континентальных поясов США; Аляска и Гавайи считаются отдельно
  • кулдаун по номеру — повторный звонок не превращается в поток сообщений
  • ограничение частоты на контур в целом
  • режим черновика: всё считается и логируется, но наружу не уходит — и отдельный явный флаг боевой отправки

Страница «Пропущенные» в CRM

Автоответ снимает первое касание, но разбирать звонки всё равно человеку. Вместо ленты уведомлений — одна страница: кто звонил и когда, номер ссылкой tel:, найденный клиент, его заказы с состоянием («не отгружен · 82 дня»), готовый текст ответа и отметка «разобрала».

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

03 · Стек

Ничего лишнего — контур должен пережить ночь без дежурного

Python stdlib

Приёмник вебхуков и HMAC-проверка подписи без веб-фреймворка

Облачная телефония

Сигналы о звонках, отправка SMS, расшифровки голосовой почты

Shopify Admin API

Поиск покупателя по номеру и его заказов в двух магазинах

Языковая модель

Пишет текст ответа под конкретный заказ, а не подставляет его в шаблон

systemd

Сервис приёмника, автоперезапуск, журнал

pytest

Свыше 100 тестов: ступени ответа, тихие часы, защита от повторов, разбор события

PythonWebhooksHMACSMS APIShopify Admin APILLMsystemdpytest
04 · Результат

Сначала разбор данных, потом код

Реальный масштаб
108 ~200

пропущенных в месяц — задача оказалась в 1,6 раза больше исходной оценки

Неиспользованный канал
29%

пропущенных уже имеют текстовую расшифровку голосовой почты — готовый ответ на «чего хотел человек»

Стоимость отправки
62%

сообщений стали односегментными после правки на один символ

Работа началась не с кода, а с выгрузки телефонии. Разбор показал, что задача в 1,6 раза больше исходной оценки, что 29% пропущенных уже имеют расшифровку голосовой почты — и этот канал не использовался вообще, — и что 36% клиентских SMS оставались без человеческого ответа. Три факта, которых не было ни в одном отчёте.

Попутно починены три поломки, без которых контур был мёртв

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

Ни одна из трёх не была видна снаружи: сервис работал, логи писались, SMS не уходили.

Отдельная находка — деталь на один символ с прямым влиянием на счёт за SMS: длинное тире в шаблонах выводило сообщение за пределы базового алфавита и переводило его в двухбайтную кодировку, из-за чего 100% сообщений уходили минимум в два сегмента. Замена длинного тире на дефис делает односегментными 62%.

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

05 · Применимость

Где ещё ложится та же методология

Это не «автоответчик». Это типовая задача «событие в канале связи → подтягиваем контекст клиента из учётной системы → отвечаем фактом, а не шаблоном». Та же архитектура применима везде, где обращения приходят вне рабочих часов:

  • Интернет-магазин с длинным сроком доставки — «где мой заказ» закрывается статусом из учётки, а не звонком менеджера
  • Сервис и ремонт — пропущенный звонок → SMS со стадией заказ-наряда и реальной готовностью
  • Клиники и салоны — звонок вне часов приёма → подтверждение записи или ближайшее окно из расписания
  • Бизнес с покупателями в другом часовом поясе — ночная смена заменяется контуром, который знает факты о заказе
  • Любой входящий канал — почта, мессенджер, форма: меняется только источник события, лестница ответа и предохранители остаются
Что переиспользуется на следующих проектах
  • Приёмник вебхуков с проверкой подписи, фильтром типов событий и защитой от повторной обработки
  • Лестница ответа с явным запретом называть просроченную дату — обкатывается на исторической выгрузке до запуска
  • Набор предохранителей отправки: тихие часы по часовому поясу клиента, пауза между сообщениями на один номер, режим черновика и отдельный переключатель боевого режима
  • Страница-очередь с готовым текстом ответа и деградацией вместо падения: «не прочиталось» никогда не показывается как «пусто»
Похожая задача?

Если у вас копятся пропущенные — сначала замер, потом автоматизация

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

Готовы начать?

Аудит за 5 000 ₽ — с конкретным отчётом и сметой

Расскажу что внедрить в вашем бизнесе в первую очередь, какая будет окупаемость, и нужен ли вообще AI для вашей задачи (иногда — нет).

Или просто напишите свой вопрос — отвечу в течение 2 часов