Дивизион IT и Инноваций

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

Постановка задачи

• Необходимость предупреждать получателя о плановом времени прибытия.
• Информировать о задержках и изменениях в маршруте.
• Обзвон по нескольким номерам и фиксация результатов каждого звонка.
• Логирование и мониторинг всех попыток дозвона.

Архитектура решения

Микросервис автодозвона (Stasis)

Разработан независимый микросервис, получающий команды через REST API. Каждый потребитель (система-инициатор) регистрируется с выдачей токена, что позволяет разделять учёт затрат по бизнес‑юнитам и настраивать параметры дозвона индивидуально:

• число повторов;
• продолжительность каждой попытки;
• интервал между попытками.

Генерация голосовых сообщений

При необходимости сервис принимает текст и через Яндекс.СpeechKit конвертирует его в аудиофайл в формате Opus. Для тонкой настройки речи используются специальные теги интонации и пауз. Файлы сохраняются в файловом хранилище и доступны Asterisk по HTTP.

Инициация звонка в Asterisk

• Запрос к микросервису получает уникальный ID и список номеров.
• Если передан текст, происходит генерация звукового файла (или используется заранее загруженный).
• Формируется и отправляется команда Originate в Asterisk с указанием номера, параметров таймаутов и переменных окружения (ID звонка, ссылка на аудиофайл).
• Asterisk устанавливает соединение, воспроизводит файл и возвращает события (StasisStart, PlaybackFinished и др.).

Алгоритм дозвона

• На каждом номере производится попытка в течение заданного потребителем времени (например, 20 с).
• При неуспехе (статус calling или failed) делается пауза (по умолчанию 120 с), затем повтор.
• Процесс повторяется до успешного звонка (started, finished) или исчерпания числа попыток.
• Если звонок прерывается на этапе прослушивания сообщения (hanged), это не считается ошибкой: достаточно того, что абонент услышал часть сообщения («звонок за час»).

Классификация результатов

• finished — сообщение прослушано полностью;
• hanged — абонент дослушал не до конца, но начал прослушивание;
• started — абонент снял трубку;
• calling и failed — неуспешные попытки (нет ответа или техническая ошибка).

Обработка ошибок и мониторинг

• Ошибки генерации и воспроизведения (404, проблемы доступа к файловому хранилищу) логируются и моментально приводят к уведомлениям в службу поддержки.
• При технических сбоях (failed) формируется письмо в службу поддержки для оперативного восстановления.
• При бизнес‑ошибках (calling) — письмо диспетчерам с просьбой ручного обзвона, если в течение 15 минут не получен успешный результат.
• Метрики выводятся в Grafana; при критических ситуациях панели «краснеют», а уведомления дублируются в Telegram‑канал службы поддержки.

Результаты внедрения

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