Каталог · корзины · оплата · доставка
Покупатель не переходит между пятью сервисами. Бот показывает действительный товар, хранит корзину, принимает заказы, запускает оплату и возвращает статус доставки — а учётная система остается источником истины.
Короткий ответ
Для небольшого ассортимента достаточно диалога. Когда есть фильтры, ревизии, выбранное и сложным checkout, витрину открываем как Mini App, а бокт оставляем для консультаций, статусов и возвращения клиента. Формат определяется после карты каталога, а не по моде.
Интерактивное представление
Обычные презентации показывают только « успешную оплату ». Мы проверяем каждое состояние: что видит покупатель, проверяющий сервер, где хранится истина и кто действует, если останок, платеж или доставка не подтвердились.
Категории, цена, фото, возможности и базовые данные приходят из согласованного источника.
Формат интерфейса
Telegram официально даёт Mini Appts полноценный HTML5-интерфейс внутри приложения. Однако большой интерфейс нужен не каждому магазине - иногда короткий диалог быстрее приводит к повторному заказу.
Подходит для повторных заказов, товаров с несколькими параметрами, консультации, подбора комплекта и отправка ссылки на оплату.
Требуется, если покупатель сравнивает многие позиции, размеры или цвета, работает с поиском, выбранным и корзиной. Бот возвращает в app по прямой ссылке и отправляет статусы.
Для большинства сложных магазинов это самая простая модель: Mini Appp отвечает за browse и checkout, бот - за напоминание, повторное заказы, статус и передачу менеджеру.
Техническая возможность Mini Apps, mobile-first дизайн и проверка `initData` сверяем с документацией Telegram Mini Apps, а платежный сценарий для физических товаров - с Telegram Bot Payments.
Контур данных
Бот не становится новой учётной системой, он оркестрирует шаги покупателей, а доменные системы подтверждают свои части: учет — товары и останки, провайдер — платеж, служба доставки — отправка.
Идентичность, диалог, витрина, статусы
Кошик, станы, проверки, журнал, повтори
Для заказа видно, кто и когда изменил состояние, которое внешний ID вернула система и что ответили клиенту.
Повторный callback или timeout не создаёт второго заказа. Платёж и запись имеют стабильные ключи операции.
Команда видит не только покупки, но и ошибки синхронизации, незавершённые checkout и состояния без следующего действия.
Аудит к рейтингу
Названия платформ недостаточно. Перед прототипом мы берем реальный SKU, тестовый заказ и доступную документацию, чтобы найти границы API, ручные операции и нестабильные места до тех пор, пока они не будут потеряны.
Проверяем SKU, варианты, категории, фото, характеристики, единицы измерения и знак публикации. Давайте посмотрим, кто изменяет имя и цену, как быстро обновления доходит до бота и что показывать, когда карточка ещё доступна по старой прямой ссылке. Если сайт, 1С и таблица имеют различные коды одного товара, сначала создаем мапинг, а не скрываем различия в сценарии.
Мы выясняем, видит ли система остатка, сколько времени остается резервным резервом, как работают акции, персональные скидки и промокоды. Для последней единицы модируем две параллельные покупки и фиксируем, кто получает резервную копию, и перед оплатой корзина снова сверяет количество и сумму; изменения объясняются покупчиком, а не превращаются в языковую ошибку или ручной звонок менеджера.
Удостоверяем валюту, провайдера, фискалирование, назначение платежа, частичную оплату, повторный callback и возвращение. Переход покупателя на экран "скоро" — это не доказательство транзакции: backend проверяет подпись, сумму, order ID и фактическое статус в провайдере. Для timeout требуется демон заговора, а для повторного сообщения - идемотентная операция, которая не создаст второй заказ.
Проверяем поиск разделения, адресную доставку, вес, количество мест, послеплату, создание накладной и чтение статусов. Затем определим, кто действует, если адрес не валидный, отделение стало недоступным, накладная не создалась или заказ застряло без события. Менеджер получает не просто уведомления, а карточку с контекстом, причиной, уже введенной данными и допустимым ручным действием.
Реалистичное доказательство
Это не демонстрационный сценарий. В проведении BotLabs каталог синхронизировался с 1С, корзина хранилась между сессиями, заказы передавались в учет, а клиент получал статусы. Окремо работали LiqPay, Новая Почта, бонусы, рассылки и админ-панель.
Medhouse Club · e-commerce
Сложность была не в показе товаров, а в согласовании различных систем. Цена и остаток должны были приходить из учета, корзина - беспокоиться о закрытии бота, платёж - подтверждаются сервером, заказы - получать внешний ID, а статус доставки - возвращаться клиенту.
Что входит в решение
Каждая функция получает владельца данных, условие старта, успех и исключение, таким образом список «каталог, оплата, доставка» превращается в тестированный процесс.
Категории, SKU, фото, характеристики, варианты, фильтры, выбранная и прямая ссылка на товар.
Сохранение между сессиями, промокод, контакт, адрес, комментарий, повторное проверка цены и подтверждение.
Invoice или checkout провайдера, webhook, сверчка суммы, повторная проверка, отмена и маршрут возврата.
Насыщенный пункт, отделение или адрес, способ доставки, стоимость, накладная, трекинг и сообщение о состоянии.
Мадопинг SKU, частота синхронизации, резерв, цены, статусы заказа, повторите и журнал интеграции.
Заказы, пользователи, рассылки, тексты, исключения, ручное вмешательство, роли и история операций.
Баланс, история, отложенное на счет после возвращений, личные предложения и повторное заказы.
Источник, открытие товара, добавление в корзину, запуск checkout, оплата, ошибка, handoff и повторное покупка.
После checkout
Сайт хорошо приводит органический спрос, а мессенджер удобный для личного продолжения уже известного контекста, поэтому измеряем не только первую оплату, но и весь цикл: незавершенную покупку, выполнения заказов, поддержки и повторов.
Тригер проверяет, завершил ли клиент заказы в другом канале, или какие- либо товары и не меняли цену. Сообщение возвращает к корзине, а не на главный экран. Частоту, тихие часы и срок жизни договора фиксируем для запуска, чтобы хорошее напоминание не стало спамом.
Покупатель получает подтверждение не из внутреннего предположения, а после фактическиго события учета или доставки. Если посылка задерживалась, потому чтот показывает релевантный статус и собирает обращение вместе с номером заказа. Менеджеру не нужно повторно спрашивать телефон, товар и метод доставки - контекст уже подключен к передаче.
Бот может предложить вам повторить склад корзины, но перед checkout снова проверяет SKU, количество, стоимость и доступность доставки. Сегментация опирается на проверенные покупки, а не только на клики. В отчете разделяются органический потор, реактивация и продажа после персонального тригера.
Запуск
Выполнять заказы через тестовый контур: изменение цены, нулевая останка, повторный callback, неудачная оплата и невозможное отделение. Только после этого расширяем ассортимент и тригеры.
Сложить карту заказаSKU, варианты, цены, остатки, фото, категории, источник истины и частота обновления.
Станы корзины, резерва, платежа, комплектации, доставки, отмена и возврат.
Проверяем навигацию на реальном телефоне, длинные названия, варианты и checkout без тестовых "идеальных" данных.
Учет, платёж, доставка, CRM или админ-панель, устойчивые ID, журнал и контроль повторов.
Ограниченная группа товаров и покупателей, проверка ручных исключений и операционной работы менеджеров.
Аллеты, метрики воронки, ответственные, сценарий rollback и контроль первых реальных заявлений.
Логика стоимости
Витрины, варианты товаров, учет, резервы, платежи, доставка, личный кабинет, бонусы, админ-панель, миграция и количество каналов. Во- первых, мы расставляем на обязательный checkout и следующие модули, чтобы не строить всё одновременно.
Как формируется стоимость чат-ботаКороткий discovery
Полное техническое задание не требуется. Пришлите пример карточной карты, название учётной системы, способы оплаты и доставки и опишите, что менеджер сейчас переносит или проверяет вручную.
FAQ
Ответы зависят от каталога, учета и договора с интеграцией. Здесь - рамка, которую проверяем до оценки.
Бот может показывать каталог, искать и фильтровать товары, хранить корзину, оформлять заказы, передавать оплату, выбирать доставку, показывать статус и возвращать клиента в незавершенную покупку. Конкретный набор зависит от каталога, учётной системы и сценариев магазина.
Да. Для физических товаров можно использовать платёжный сценарий Telegram или открыть checkout подключённого провайдера. Перед запуском совпадают валюта, фискализация, callback платежу, повторное проверка статуса, возвращения и поведение после неудачной платы.
Да, если система имеет доступный API, обмен файлами или интеграционный шлюз. В процессе разработки зафиксируем источник истины для SKU, цен, останков, характеристик и статусов, частоту обновления и правила конфликтов.
Обычный бот удобный для краткого каталога, консультаций, повторных заказов и статусов. Mini Appp, установленный для большого каталога, фильтров, вариантов, визуальной корзины и более сложных checkout. Часто наиболее эффективно работает гибрид: бот ведет диалог и возвращает клиента, Mini Appp дает парусную.
Да, интеграция может искать населенные пункты и отделения, создавать отправку и чтение статуса. Окончательный компонент зависит от доступа, договора и API бизнес-кабинета. Для нестандартных адресов или ошибок требуется маршрут к менеджеру.
Да, если корзина находится на сервере и привязана к проверенному пользователю или сессии. Важно установить срок жизни корзины, повторную проверку цены и остаток перед оплатой и правилами для уже завершённых товаров.
Не обязательно. Бот может быть дополнительным каналом для повторных заявлений, персональных предложений, консультаций и статусов, а сайт останется основной SEO-витриной. Полное замена оправдана только после обработки каталога, трафика и потребностей покупателей.
От формата интерфейса, количества товаров и вариантов, источника каталогов, правил корзины, оплата, доставки, интеграции с учетом, личным офисом, бонусом, админ-панели, аналитики и миграции. Мы делаем это после карты одного заказа и списка исключений.
