Telegram-система заказов для локальной сети доставки

Оформление заказов, оплата, live-статусы и внутренняя CRM внутри Telegram — без отдельного приложения и лишней нагрузки на операторов.

Telegram • FoodTech • Realtime • Payments

Обсудить FoodTech-контур

‹

Доставка · проект под NDA

в сети

Заказ #1824 · ETA 14:06

Статус обновлён: в печи

МенюПовторитьПоддержка

Live · кухня

События синхронизируются по WebSocket — без опроса чата.

Сообщение…

01 · Проблема

Операционный хаос в пиках — не «маркетинговая боль», а потеря денег

Фокус на повторяемых сценариях: где именно ломалась система без бота и почему это нельзя было решить «ещё одним менеджером».

Менеджеры как bottleneck

Вечерние пики превращались в очередь сообщений: часть заказов терялась в переписке.

Повторяемые вопросы

Статус, время, акции, оплата — одно и то же сотни раз в день.

Зависимость от операторов

Скорость и качество ответа становились случайной величиной.

Риск агрегаторов

Бизнесу нужен собственный контур удержания без «аренды» чужой воронки.

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

02 · Решение

Перенос заказа в Telegram как продуктовая платформа, а не «чат с оператором»

Связали пользовательский flow, платежи, удержание и внутренние операции так, чтобы снизить нагрузку на людей и сделать статусы предсказуемыми.

Разработали Telegram-бота с полноценным flow оформления заказа внутри мессенджера. Пользователь мог выбрать позиции, собрать заказ, оплатить онлайн и отслеживать статус доставки в реальном времени. Система объединила каталог, корзину, бонусную систему, реферальную механику, live-статусы кухни и доставки, а также внутреннюю панель управления заказами и стоп-листами.

03 · Почему Telegram

Низкий friction важнее «красивого приложения в сторе»

У аудитории уже был привычный канал. Задача — не заставлять скачивать новое, а аккуратно встроить заказ в существующий контур.

Быстрый вход: контекст пользователя уже в Telegram
Меньше трения: нет установки и онбординга «с нуля»
WebApp для сложных экранов без выхода из привычного UX
Нотификации там, где пользователь и так живёт

Мы сознательно не позиционировали это как «ещё одно приложение доставки». Это внутренняя платформа заказа: быстрые сценарии, предсказуемые состояния, минимум экранов между «хочу» и «оплатил». Детали реализации части интеграций скрыты по NDA.

Экран live-статуса доставки

Сценарий оформления заказа внутри Telegram

Карточки с upsell

Бонусы и промокоды

04 · Архитектура

Три контура: клиентский WebApp, realtime-слой и ядро данных

Схема упрощена: конкретные сервисы, очереди и схемы БД под NDA. Ниже — логические границы, которые позволили держать скорость и контроль.

Клиент

Telegram WebApp + сценарии бота: короткие экраны, устойчивость к перезапуску WebView.

Realtime

WebSocket для статусов и «живых» апдейтов без лишнего трафика в Bot API.

Ядро

Node.js, PostgreSQL, Redis: очереди, кеш, идемпотентность оплат и синхронизация ролей.

05 · Flow заказа

Путь пользователя как конвейер: короткие экраны, явные состояния

Каталог → корзина → комбо/upsell → оплата → повтор. Каждый шаг должен быть дешёвым по вниманию, особенно ночью и в пик.

Каталог

Категории, стоп-листы, быстрый поиск

Корзина

Минимум шагов, понятные модификаторы

Комбо

Сборка наборов без ломки UX

Upsell

Контекстные предложения без давления

Оплата

T-Банк, возвраты и edge-кейсы

Повтор

Один тап — снова в корзину

06 · Live delivery system

Статусы как продукт, а не «переписка с оператором»

Цепочка отражает реальные этапы кухни и логистики. Пользователь видит прогресс, а менеджер не тонет в однотипных вопросах про «где заказ».

RealtimeWS · 1.2s p95

Принят
Создание заказа и слот доставки
Готовится
Кухня и очередь станций
В печи
live
Горячий контур производства
Передан курьеру
Синхронизация статусов
Курьер рядом
Гео + ETA без лишних сообщений
Доставлен
Закрытие чека и бонусы

07 · CRM и удержание

Промокоды, бонусы и рефералки — как часть одной модели данных

Повторный заказ в один клик — это не «фича ради фичи», а снижение трения у ядра аудитории.

Промокоды и акции

Правила применения и конфликты скидок — на сервере, UI остаётся простым.

Бонусы

Прозрачное начисление/списание, чтобы не ломать доверие в момент оплаты.

Реферальная механика

Органический рост без покупки трафика агрегаторов — в рамках политики Telegram.

08 · Внутренняя панель

Операции, стоп-листы и аналитика — чтобы кухня и логистика не расходились с тем, что видит клиент

Admin

Панель операций

Стоп-листы, очередь заказов и сигналы пиков — в одном интерфейсе. Часть внутренних метрик скрыта по NDA.

Стоп-лист · SKU (обезличено)12 мин

Очередь кухни · стабильно

Пик нагрузки · вечер

агрегировано

SLA ответа

↓

оператор

Повторы

↑

Средний чек

↑

upsell

Популярные позиции (обезличено)

09 · Engineering

Ограничения Telegram WebApp — часть дизайна, а не «сюрприз на проде»

Тон: спокойный, инженерный. Ниже — решения, которые мы закладывали в архитектуру, без раскрытия внутренних endpoint’ов.

WebApp и сессии. Учитывали ограничения окружения, перезапуски WebView и потерю локального состояния — критичные шаги не держим только на клиенте.
Realtime. Обновления статусов через WebSocket: снижаем «опрос» и нагрузку на Bot API, сохраняем ощущение live.
Синхронизация заказов. Идемпотентность оплат, повторные callback’и, гонки между кухней и курьером — закрыто на уровне транзакций и очередей.
Скорость интерфейса. Минимизировали число экранов: каждый тап должен быть оправдан.

Stack

Node.jsPostgreSQLTelegram Bot APIWebSocketRedisDocker

Интеграции

Telegram Bot API···

Telegram WebApp···

T-Банк API···

PostgreSQL···

Realtime delivery updates···

10 · Результаты