Каталог · кошик · оплата · доставка
Покупець не переходить між п’ятьма сервісами. Бот показує актуальний товар, зберігає кошик, приймає дані для замовлення, запускає оплату й повертає статус доставки — а облікова система залишається джерелом правди.
Коротка відповідь
Для невеликого асортименту достатньо діалогового каталогу. Коли є фільтри, модифікації, обране й складний checkout, вітрину відкриваємо як Mini App, а бот залишаємо для консультацій, статусів і повернення клієнта. Формат визначаємо після карти каталогу, а не за модою.
Інтерактивна модель
Звичайна презентація показує лише «успішну оплату». Ми проєктуємо кожний стан: що бачить покупець, що перевіряє сервер, де зберігається істина і хто діє, якщо залишок, платіж або доставка не підтвердилися.
Категорії, ціна, фото, варіанти й базова наявність приходять із погодженого джерела. Бот не зберігає паралельний «ручний прайс», який завтра стане неактуальним.
Формат інтерфейсу
Telegram офіційно дає Mini Apps повноцінний HTML5-інтерфейс усередині застосунку. Але великий інтерфейс потрібен не кожному магазину — інколи короткий діалог швидше приводить до повторного замовлення.
Підходить для повторних замовлень, товарів із кількома параметрами, консультації, підбору комплекту та відправлення посилання на оплату.
Потрібний, коли покупець порівнює багато позицій, розмірів або кольорів, працює з пошуком, обраним і кошиком. Бот повертає в app за прямим посиланням і надсилає статуси.
Для більшості складних магазинів це найстійкіша модель: Mini App відповідає за 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 App доречний для великого каталогу, фільтрів, варіантів, візуального кошика та складнішого checkout. Часто найкраще працює гібрид: бот веде діалог і повертає клієнта, Mini App дає вітрину.
Так, інтеграція може шукати населені пункти й відділення, створювати відправлення та читати статус. Остаточний склад операцій залежить від доступів, договору та API бізнес-кабінету. Для нестандартних адрес або помилок потрібен маршрут до менеджера.
Так, якщо кошик зберігається на сервері та прив’язаний до перевіреного користувача або сесії. Важливо визначити строк життя кошика, повторну перевірку ціни й залишку перед оплатою та правила для товарів, які вже закінчилися.
Не обов’язково. Бот може бути додатковим каналом для повторних замовлень, персональних пропозицій, консультацій і статусів, а сайт залишиться основною SEO-вітриною. Повна заміна виправдана лише після аналізу каталогу, трафіку та потреб покупців.
Від формату інтерфейсу, кількості товарів і варіантів, джерела каталогу, правил кошика, оплат, доставки, інтеграції з обліком, особистого кабінету, бонусів, адмін-панелі, аналітики та міграції. Оцінку робимо після карти одного замовлення й переліку винятків.
