Telegram-бот со статусом заказа: ответ из базы вместо очереди в поддержку

MAATRIX · 17 октября 2026 · 8 мин чтения

Покупатель спрашивает не устройство вашей логистики. Ему нужно понять, что происходит с заказом и когда ждать следующего шага. Между тем в базе может стоять статус ready_for_fulfillment, в CRM — «передан», а менеджер пишет «скоро отправим». Три источника, три формулировки, один закономерно недовольный человек.

Бот полезен, когда читает достоверное состояние и переводит его на понятный язык. Его задача не угадывать дату доставки, а быстро сообщать то, что известно, показывать время обновления и оставлять путь к человеку, когда данных недостаточно.

Начните со словаря статусов

Выпишите реальные состояния из системы заказов. Для каждого подготовьте клиентскую формулировку, объяснение и допустимое следующее действие. «Оплата ожидается» предлагает проверить платёж, «передан перевозчику» показывает трек-номер, «требуется уточнение» ведёт в поддержку.

Не объединяйте разные события ради короткого списка. Заказ собран на складе и заказ принят перевозчиком — не одно и то же. Если система ещё не получила подтверждение передачи, фраза «уже в пути» создаёт обещание, которое потом придётся объяснять оператору.

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

Попросите коллегу прочитать формулировки без доступа к внутренней системе. Если он не понимает, требуется ли сейчас действие покупателя, текст стоит уточнить до запуска.

Отдельно храните ожидаемую дату и подтверждённую дату события. Прогноз можно показывать с соответствующей подписью. Бот не должен превращать ориентировочный срок в гарантию только потому, что в шаблоне не хватило места для слова «ожидается».

Кто имеет право увидеть заказ

Номер заказа обычно не является секретом достаточной силы. Он может быть последовательным, попасть на упаковку или оказаться в пересланном письме. Поэтому ответ на команду с номером должен учитывать, кому принадлежит заказ.

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

После открытия бота сервер проверяет код, срок, однократность использования и привязывает числовой Telegram ID. Не передавайте в ссылке пароль, постоянный токен или открытые контактные данные. Код должен погашаться атомарно, чтобы два одновременных запроса не подключили разных пользователей к одному разрешению.

В личном кабинете предусмотрите отключение бота и повторное подключение. Покупатель может сменить Telegram-аккаунт или потерять доступ. Для разовых покупателей без кабинета понадобится отдельный проверенный способ подтверждения, например код на контакт из заказа, с ограничением попыток и срока действия.

Источник истины должен быть один

Выберите систему, которая определяет состояние заказа: магазин, ERP или собственный сервис. Если информация о доставке приходит из другой системы, храните источник и время каждого поля. Не выбирайте произвольно самое новое значение из разных систем без правил приоритета.

Боту предоставьте минимальный интерфейс чтения. Это может быть внутренний API либо подготовленное представление базы. Не выдавайте процессу права менять цены, удалять клиентов и выполнять произвольные запросы. Удобство настройки редко оправдывает доступ к каждой таблице магазина.

Для внешнего API установите ограничение времени ожидания и обработку временных отказов. Если источник не отвечает, бот должен честно сообщить о задержке проверки. Последний известный статус допустимо показать с датой, но нельзя выдавать его за свежее чтение.

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

Запрос к базе с проверкой владельца

Предположим, в вашей собственной PostgreSQL есть таблица customer_telegram_links, связывающая клиента с Telegram, и таблица orders. Названия и поля ниже учебные: создайте соответствующую схему или адаптируйте запрос к существующей. Значение Telegram ID должно происходить из проверенного обновления бота, а не из текста сообщения пользователя.

SELECT o.public_number, o.status,
       o.status_updated_at, o.tracking_number
FROM orders AS o
JOIN customer_telegram_links AS l
  ON l.customer_id = o.customer_id
WHERE l.telegram_user_id = $1
  AND l.revoked_at IS NULL
  AND o.public_number = $2;

Передавайте параметры через драйвер, не подставляя номер заказа в строку SQL. Запрос возвращает запись только при действующей связи владельца. Общие правила выборки приведены в документации PostgreSQL. Если у вас семейные аккаунты или корпоративные покупатели, модель прав потребуется расширить явно.

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

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

Собираем разговор, а не меню из десяти этажей

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

Если есть трек-номер, формируйте ссылку по известному шаблону перевозчика или проверенному адресу из системы. Не превращайте произвольную строку из базы в доверенную кнопку. Внутренние комментарии, закупочные цены и служебные признаки в клиентский ответ не включайте.

Для оформления удобно использовать Python и aiogram. Важно отделить обработчик команды от слоя доступа к заказам: первый получает запрос Telegram, второй проверяет права и возвращает разрешённые данные. Тогда ту же проверку можно использовать в веб-кабинете и тестировать независимо от интерфейса чата.

Запуск обновлений выбирайте по архитектуре: long polling удобен для простого сервиса, webhook — для входящих HTTP-запросов с защищённым публичным адресом. Telegram описывает варианты в Bot FAQ. При webhook проверяйте предусмотренный секрет и не доверяйте произвольному JSON, присланному на открытый адрес.

Уведомления о смене статуса

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

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

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

Если пользователь заблокировал бота, отметьте невозможность доставки и прекратите бесполезные повторы. Статус заказа продолжает жить независимо от канала уведомлений. Для важных сообщений используйте предусмотренный бизнесом запасной способ связи, а не считайте Telegram единственным доказательством информирования.

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

Создайте два тестовых аккаунта с разными заказами. Первый должен видеть свои записи и не получать чужую карточку после подмены номера. Затем отзовите связь с Telegram и проверьте старые кнопки: они не должны сохранять прежние полномочия.

Проверьте неизвестный статус, отсутствие трек-номера, недоступность базы и устаревшие данные. Клиентский ответ должен оставаться понятным, а оператор — получать достаточно сведений для разбора. Технические ошибки и строки подключения не отправляйте в чат покупателю.

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

Где поселить бота

Для небольшого сервиса с внешней базой можно начать с VPS MAATRIX Uab Start: 2 vCPU и 4 GB RAM на поддерживаемой Ubuntu или Debian. Это пилотная конфигурация, которую проверяют на своём потоке запросов. При локальной PostgreSQL, нескольких интеграциях и большом кеше измерьте память и рассмотрите Heka Standard с 8 GB.

Настройте постоянный запуск, перезапуск после сбоя и проверку доступности источника данных. Резервируйте привязки пользователей и журнал событий, храните токен бота отдельно от исходников. Географию сервера выбирайте с учётом пользователей и требований к размещению клиентских данных.

На VPS MAATRIX можно разместить собственный бот и слой доступа к заказам. Покупатель получает короткий достоверный ответ, а поддержка занимается случаями, где действительно нужен человек. Иногда лучший способ сделать сервис внимательнее — перестать заставлять людей ждать информацию, которая уже есть в базе.