витрина, заказ, оплата
Телеграм-бот магазина: каталог, оплата и заказ, который не потеряется
Продавать в мессенджере просто ровно до первого платежа. Дальше начинаются остатки, статусы, возвраты и сверка — то есть настоящий магазин.
Магазин в мессенджере заводят по понятной причине: клиент уже здесь, ему не надо никуда переходить, а путь от «посмотрел» до «оплатил» короче, чем на сайте. До определённого объёма это работает отлично и стоит недорого. Ломается всё на второй сотне заказов, и ломается не витрина, а учёт.
Первое решение, которое приходится принять, — где живёт правда о товаре. Если остатки и цены ведутся в учётной системе, бот обязан читать их оттуда, а не хранить свою копию: копия расходится за неделю, и вы продаёте то, чего нет. Если учёта нет вовсе, его роль всё равно кто-то исполняет — таблица, тетрадь или человек, — и это стоит признать до запуска, а не после первого спорного заказа.
Второе — оплата. Мессенджер даёт удобный приём платежа, но деньги идут через вашего провайдера и по вашему договору, а вместе с ними приходят вещи, о которых на старте не думают: чек, возврат, частичный возврат, оплата не прошедшая, оплата прошедшая дважды, сверка в конце дня. Это ровно та работа, которую я делал в партнёрской платформе: эквайринг, идемпотентность операций, фоновые задачи с повторами на Redis и BullMQ и обмен с внешними системами, где потеря события недопустима.
Третье — интерфейс. Кнопками хорошо продаётся узкий ассортимент: десяток позиций, понятные варианты, короткий путь. Как только появляются фильтры, размеры, наличие по складам и картинки, которые надо листать, кнопки заканчиваются и разумнее открыть мини-приложение внутри мессенджера — обычный веб-интерфейс, работающий на ваших же данных. Граница проходит не по красоте, а по числу решений, которые покупатель принимает до оплаты.
И четвёртое, о чём стоит сказать прямо: бот не заменяет ни сайт, ни маркетплейс. У него нет поисковой выдачи, слабая витрина для незнакомого товара и полная зависимость от чужой платформы. Он силён в повторных покупках и в аудитории, которая уже вас знает: подписчики канала, постоянные клиенты, закрытые сообщества. Как единственный канал продаж это риск, как канал повторных заказов — один из самых дешёвых.
Что здесь обычно ломается
- Остатки в боте и в учёте разошлись, и клиент оплатил то, чего нет.
- Заказы приходят в чат и переносятся в таблицу руками — до первой ошибки.
- Оплата прошла, а заказ не создался: событие потерялось между системами.
- Возврат или частичный возврат делают руками и забывают отразить в учёте.
- Ассортимент вырос, и меню из кнопок перестало помещаться в экран.
- Клиент не понимает, что с заказом, и пишет в личку менеджеру.
Что нужно магазину в мессенджере и где это должно жить
| Что нужно покупателю | Где это живёт | Что ломается, если иначе |
|---|---|---|
| Актуальная цена и наличие | Учётная система, бот только читает | Копия расходится, продаётся отсутствующий товар |
| Выбор из большого каталога | Мини-приложение с фильтрами | Меню из кнопок перестаёт помещаться в экран |
| Оплата в два касания | Платёжный провайдер по вашему договору | Ручной перевод и сверка платежей глазами |
| Заказ, который точно создан | Ваша база с ключом идемпотентности | Двойной заказ при повторной доставке события |
| Статус и трек-номер | Учёт как источник, бот как канал | Клиент пишет менеджеру в личку каждый день |
| Возврат и отмена | Регламент плюс операция в провайдере | Возврат руками и расхождение в отчётности |
| Повторный заказ | История покупок клиента | Клиент собирает корзину заново и часто не собирает |
Что входит
- каталог, читающий цены и остатки из вашей учётной системы
- корзина и оформление заказа с проверкой наличия перед оплатой
- приём оплаты через вашего провайдера, чеки и понятные статусы
- идемпотентность: повторное событие не создаёт второй заказ
- создание заказа в учёте или CRM с повторами при недоступности
- статусы и уведомления клиенту вместо переписки с менеджером
- мини-приложение с фильтрами, когда ассортимент перерос кнопки
- админ-часть: очередь заказов, ошибки обмена, ручная досылка
Для кого
продавцам с узким или повторяющимся ассортиментом и уже собранной аудиторией: подписчиками канала, постоянными клиентами, закрытым сообществом.
Услуга: Веб-приложения и сервисы Стоимость: Чат-бот Часто идёт вместе с: Личный кабинет клиента Механика процесса: Обмен данными между системами Кейс по теме: Партнёрская PRM-платформа с AI-подбором и копайлотом
Частые вопросы
- Можно продавать без сайта вообще?
- Технически да, и для узкого ассортимента с готовой аудиторией это рабочая схема. Стратегически это ставка на чужую платформу: у мессенджера нет поисковой выдачи, и вся ваша витрина живёт по чужим правилам. Как единственный канал — риск, как канал повторных продаж — очень дешёвый способ.
- Как связать с 1С или другой учётной системой?
- Через API или контролируемый обмен, с одним источником правды по остаткам и ценам. Направление обмена и правила разрешения конфликтов фиксируются до разработки: без этого рано или поздно появляются две разные истины об одном товаре, и спор между ними придётся разбирать вручную.
- Кто отвечает за приём денег?
- Вы: договор с платёжным провайдером, касса и чеки — на стороне продавца. Моя часть — корректная механика: заказ и платёж связаны, повторное событие не создаёт вторую оплату, статусы совпадают с реальностью, а возврат отражается и в системе, и у клиента.
- Что выбрать: кнопки или мини-приложение?
- По числу решений до оплаты. Десяток позиций и два варианта — кнопки, они быстрее и дешевле. Фильтры, размеры, наличие по складам, галерея — мини-приложение: это обычный веб-интерфейс на ваших данных, просто открывается внутри мессенджера.
- Сколько времени занимает запуск?
- Первая рабочая версия — от 2 недели, если каталог небольшой и учётная система готова отдавать данные. Основной срок съедает не бот, а обмен: выяснение, где лежит правда о товаре, и приведение статусов к виду, понятному покупателю.
- А доставка, самовывоз и разные регионы?
- Это не витрина, а правила, и их стоит выписать до разработки. Какие способы доставки есть, как считается стоимость, что происходит при частичной отмене, кто пересчитывает сумму и в какой момент клиент видит финальную цифру. В боте всё это выглядит как пара дополнительных шагов, а в реальности определяет половину логики заказа: именно здесь чаще всего выясняется, что в компании нет единого ответа, и его приходится согласовывать между продажами, складом и бухгалтерией.
Есть разговор, который повторяется каждую неделю?
Опишите его — скажу, закрывается ли он сценарием, нужен ли там ИИ и во что это выльется по срокам и деньгам.
Обсудить проект