На пропущенный звонок покупатель получает SMS с настоящим сроком отгрузки

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

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

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

Ответ строится ступенями

Ответ выбирается по ступеням, от самого конкретного к нейтральному. Ни на одной ступени система не имеет права обмануть:

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

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

Защита при отправке

Автоматическое SMS уходит от имени компании, и никто не видит его перед отправкой. Поэтому ограничения здесь важнее самого текста:

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

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

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

Страница выдерживает частичный сбой: одна испорченная строка очереди её не ломает. Если очередь не читается, на странице так и написано: «очередь не прочиталась». Если бы там стояло «звонков нет», сотрудник спокойно закрыл бы вкладку.

Попутно исправлены пять ошибок, и из-за трёх из них система вообще не работала

• поиск клиента падал из-за несовпадения параметров функций, и каждый звонок считался «клиент не найден»
• разбор события искал данные не на том уровне вложенности и молча отбрасывал все пропущенные
• номер звонящего искался в поле, которого в уведомлении нет
• карточка автоответов сломала всю страницу звонков, с которой два сотрудника начинают утро. Код писали по угаданным именам полей, тестовые данные придумали так же, и тест лишь подтверждал догадку автора
• подсчёт недозвонов был написан и покрыт тестами, но его никто не вызывал. Руководитель спрашивал, сколько теряется на недозвонах, и не получал ответа, хотя код для него уже был готов

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

Как проверяется, что уведомления доходят

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

• Приёмник 18 суток работал на коде почти трёхнедельной давности. Счётчик перезапусков показывал ноль, контрольная сумма файла на диске совпадала с репозиторием, но это ничего не доказывало: сверять нужно время запуска процесса со временем изменения файлов. Последствие — именно то, о чём весь этот кейс. Поиск клиента по номеру уходил запросом на другой сервер, при пустом ответе функция молча возвращала пустой результат, и звонок превращался в «клиент не найден». Перед перезапуском код сверен с репозиторием до байта и прогнаны 732 теста этой части системы; все прошли
• Проверка «а были ли звонки» опиралась на служебный метод API телефонии. Этот метод отвечает ошибкой HTTP 400 без данных, простой разбор выводит «0 звонков», и ошибку не отличить от доказательства, что звонков не было. Это выяснилось на контрольном отрезке времени, где звонки точно были, а метод всё равно показал «0». Теперь для проверки используется другой метод, а доставка уведомлений проверяется четырьмя независимыми способами, и ни один из них не зависит от очереди
• Контрольное правило записано заранее: «если к 18:00 понедельника не придёт ни одного события, проверяем настройки уведомлений». Проверять не пришлось: тишина объяснилась выходными. В пятницу пришло 4 события, в субботу 0, в воскресенье 3, в понедельник 6, и 41 час тишины пришёлся на выходные
• Сторожевой скрипт, который ждал письма от поставщика телефонии, прочитал нужное письмо, записал его к себе и никого не предупредил. Фильтр отписок искал фразу во всём тексте письма, а система обращений поставщика добавляет ниже всю прежнюю переписку. Теперь разбирается только новая часть письма. Там же нашлась вторая проблема: в журнале скрипта было 50 строк, и все до одной — ошибки. Успешный запуск ничего не записывал, поэтому «сработал без происшествий» и «не работает вовсе» выглядели одинаково

Здесь действует то же правило, что на странице очереди: «не прочиталось» не показывается как «пусто».

Когда клиенты звонят на самом деле

Система проработала достаточно долго, чтобы журнал уведомлений ответил на вопрос «в какие часы держать линию». Замер сделан по журналу на диске, без обращений к сторонним сервисам. Повторы убираются по идентификатору звонка, в расчёт идёт последнее событие с итоговым статусом, а часовой пояс клиента определяет библиотека разбора номеров. Всего 739 входящих за 90 дней, и пояс определён у каждого. Считать всё по одному времени было нельзя: восемь утра на восточном побережье — это пять утра на западном, и вывод исказился бы.

• больше всего звонят в 11:00 по местному времени клиента; на промежуток 09:00–12:00 приходится 38% звонков
• 82% звонков приходится на рабочее время, 5% — на вечер, 1% — на ночь. Представление «звонят вечером» не подтвердилось
• в понедельник звонят почти вдвое чаще, чем в пятницу
• 496 звонков из 739 пришли в объявленные часы работы, и 310 из них пропущены
• всего за 90 дней пропущено 530 звонков, около 180 в месяц, — столько же показала и первая выгрузка из телефонии
• в дневном отчёте 7 недозвонов из 9 пришлись на объявленные часы работы

Отсюда цифра, ради которой всё и считалось: если закрываться на два часа позже, в 17:00, линия приняла бы ещё 133 звонка за 90 дней, около 44 в месяц. Праздники в расчёте вычисляются по формуле, потому что таблицу с датами рано или поздно забудут продлить.

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

Карточка «Вчера» на странице звонков

Рядом с очередью появилась сводка за прошедшие сутки: сколько автоответов ушло, сколько не ушло и почему. Карточка собирает данные из всех источников, и на этом построена её проверка. На полных тестовых данных она должна показать «не ушло 2» и назвать две причины. Если какой-то источник подменить заглушкой, получится «не ушло 0», и тест сразу это заметит.