Разработка и DevOps / кейс 01
Dodo Engineering: Telegram Mini App для голосового заказа еды
Голосовой заказ еды с проверкой корзины и оплатой внутри Telegram. Распознанные фразы сопоставляются с каталогом, но финальный состав заказа всегда подтверждает пользователь.

Голосовой заказ сокращает путь постоянного гостя только тогда, когда скорость не подменяет контроль. В этом проекте пользователь мог назвать позиции внутри Telegram, получить структурированную корзину, исправить результат распознавания и только затем подтвердить оплату. Неоднозначная фраза останавливалась до оформления, а повторный запрос или callback не создавал второй заказ и вторую оплату.
Паспорт проекта
- Направление: Telegram Mini App, backend, AI, интеграции.
- Задача: Дать гостю возможность надиктовать заказ голосом, проверить собранную корзину и оплатить ее внутри Telegram без установки отдельного приложения.
- Продолжительность: 4 месяца, включая discovery, MVP, пилот и стабилизацию.
- Команда: PM, tech lead, 2 backend-разработчика, 2 Mini App-разработчика, AI-инженер, QA, дизайнер, DevOps частично. Всего 10 человек.
- Роль AIFlowPoint: Разработка голосового сценария заказа: Mini App, преобразование речи в корзину, серверная проверка, платежный контур и кабинет оператора.
Бизнес-ситуация и цена ошибки
Постоянный гость проходил тот же длинный путь заказа, что и новый пользователь, хотя часто знал нужные позиции заранее. Голос мог сократить этот путь, но ошибка в названии, размере, количестве, модификаторе или адресе не должна была превращаться в оплату.
Поэтому задача не сводилась к подключению распознавания речи. Нужно было связать свободную фразу с актуальным каталогом, показать пользователю итоговую структуру заказа и оставить окончательное решение за ним. Финансово значимые операции требовали отдельной защиты: повтор сообщения, сетевой retry или несколько одинаковых callback от платежной системы не должны были порождать новые сущности.
Границей работы стал полный голосовой сценарий заказа внутри Telegram. В него вошли интерфейс Mini App, распознавание, сборка корзины, серверная валидация, оплата, статусы и операторский контур. Автоматическое оформление без проверки пользователем сознательно исключили.
Как зафиксировали критерии до реализации
Сначала разобрали обычный путь заказа и убрали лишние действия для постоянного гостя. Затем отдельно определили риски распознавания названий, размеров, количества, модификаторов и адреса. Команда исключила автоматическую отправку заказа без проверки и подтверждения пользователем. Проверку Telegram initData и защиту от повторных операций перенесли на сервер.
Эти решения задали простой продуктовый принцип: AI возвращает предположение, но не получает право незаметно завершить заказ. Пользователь всегда видит состав корзины, может изменить количество, удалить позицию или выбрать другой вариант. Если фраза непонятна или позиция недоступна, система не продолжает путь как будто ошибки не было.
Реализация пользовательского пути
Работу построили вокруг одного наблюдаемого пользовательского пути:
- Разработали Mini App с меню, поиском, корзиной, промокодами и выбором способа получения.
- Добавили прием голосовых сообщений, распознавание речи и преобразование результата в структурированный заказ.
- Настроили сопоставление разговорных названий с позициями меню, размерами и модификаторами.
- Создали экран проверки корзины, где можно изменить количество, удалить позицию или выбрать другой вариант.
- Подключили адреса, зоны доставки, расчет времени, платежи и статусы заказа.
- Добавили кабинет оператора для ручной корректировки и просмотра истории обработки.
- Защитили создание заказа, списание и платежный webhook от повторной обработки.
- Подготовили аналитику по этапам воронки без хранения голосовых сообщений дольше согласованного срока.
В результате гостю не требовалось устанавливать отдельное приложение. Он отправлял голосовое сообщение, получал готовую к проверке корзину, исправлял спорные места и переходил к оплате только после явного подтверждения. Оператор при этом мог увидеть источник ошибки и восстановить путь заказа по журналу событий.
Технический контур и защита от отказов
React и TypeScript отвечают за быстрый интерфейс внутри Telegram. ASP.NET Core обслуживает корзину, меню, оплату и интеграции с внутренними системами. PostgreSQL хранит заказы и их состояния, Redis удерживает короткие сессии и защищает часто вызываемые операции, Kafka передает события между заказом, оплатой и уведомлениями. Сервис распознавания речи возвращает предположение, а финальная проверка состава заказа выполняется по каталогу.
Telegram initData проверяется только на сервере. Для создания заказа используется ключ идемпотентности. Даже если клиент повторит запрос или платежная система несколько раз отправит один callback, в базе останется один заказ и одна подтвержденная оплата.
Технологический контур проекта: React, TypeScript, Telegram Mini Apps SDK, Telegram Bot API, .NET 8, C#, ASP.NET Core, PostgreSQL, Redis, Kafka, API распознавания речи, API платежного провайдера, Docker, Kubernetes, GitLab CI, Prometheus, Grafana, Playwright и xUnit. Технологии связаны с конкретными частями пользовательского пути, платежного контура, наблюдаемости и тестирования.
Безопасность здесь включает не только платежи. Непонятное распознавание не превращается в действие, недоступная позиция исключается до оплаты с объяснением, а голосовые сообщения не хранятся дольше согласованного срока. Кабинет оператора и журнал событий обеспечивают вмешательство оператора в случаях, которые нельзя надежно обработать автоматически.
Результат и измерение
У постоянного гостя появился короткий путь заказа без установки отдельного приложения: назвать позиции голосом, проверить готовую корзину и подтвердить оплату. Неоднозначное распознавание останавливается до оформления, а повторный запрос или callback не создает второй заказ и вторую оплату.
Измеримый результат: Медианное время от голосового сообщения до проверенной корзины менее 60 секунд; не менее 60% голосовых сессий доходят до проверки корзины; ноль дублей заказов и оплат.
Эффект: Голосовой сценарий заметно сократил путь заказа, не пожертвовав контролем пользователя и безопасностью оплаты.
Приемка и проверка результата
Критерии проверки охватывают весь путь и его отказные ветки:
- Пользователь проходит путь от голосового сообщения до оплаты внутри Telegram.
- Непонятная фраза не превращается в заказ без подтверждения.
- Повторный запрос не создает дубль и не списывает деньги второй раз.
- Недоступная позиция удаляется до оплаты с понятным объяснением.
- Оператор видит источник ошибки и восстанавливает путь заказа по журналу событий.
- Основные сценарии проверяются на iOS, Android и Telegram Desktop.
Результат фиксируют видео полного заказа, скриншоты Mini App, аналитика воронки, отчет по повторным callback и идемпотентности. Вместе они показывают полный пользовательский путь, метрики и защиту от повторных операций.
Что передали клиенту
- Исходный код Telegram Mini App и backend.
- Схема интеграций и модель данных.
- Конфигурация окружений.
- Автотесты ключевых сценариев.
- Инструкция оператору.
- Описание релиза и порядок отката.
Такая передача позволяет продолжить развитие внутри команды клиента, повторить выпуск и выполнить откат по документированному порядку, не оставляя критическую логику только в знаниях подрядчика.
Кому релевантен этот опыт
Кейс релевантен продуктам, где AI преобразует свободный пользовательский ввод в финансово или операционно значимое действие. Особенно там, где нужны проверка каталога, явное подтверждение, идемпотентность, операторское вмешательство и наблюдаемая воронка.
Если нужно сократить путь заказа, но сохранить контроль пользователя и безопасность оплаты, начнем с одного принимаемого голосового сценария и его отказных веток.