Чому бот-асистент — не просто чат?
Ми розробляємо діалогові інтерфейси для мобільних застосунків, які автоматизують приймання замовлень. Це не чат з оператором: кожна дія — створення, зміна, скасування — атомарна та відкочувана. Користувач може передумати на будь-якому кроці, а бот зберігає контекст.
У нашій практиці понад 50 проєктів з інтеграції ботів з OMS. Наприклад, для мережі кав'ярень ми реалізували бота, який обробляє 300+ замовлень на день. Середній час оформлення — 30 секунд, що вдвічі швидше за лінійні скрипти. Такі рішення скорочують навантаження на підтримку на 40% та економлять до 500 000 ₴ на рік для мережі з 20 точок. Оцініть потенціал під ваш кейс — зв'яжіться з нами.
Як state machine запобігає втраті даних?
Оформлення замовлення через бота — форма з кількома кроками, розтягнута в часі. Між репліками користувач може згорнути застосунок, переключитися в інший, повернутися через 10 хвилин. Стан має зберігатися. Ми використовуємо state machine на Redis: кожен крок — скінченний автомат з явними переходами. Wikipedia - Finite-state machine
Структура слотів для діалогу замовлення:
{ "session_id": "uuid", "step": "confirm_address", "order_draft": { "items": [ {"sku": "ITEM-123", "qty": 2, "price": 1500} ], "delivery_address": null, "payment_method": "card", "promo_code": null }, "expires_at": "2025-01-15T14:30:00Z" } Стан зберігається на сервері (Redis з TTL 30–60 хвилин). Мобільний застосунок передає лише session_id з кожним повідомленням.
Критичний момент: кожен крок діалогу має підтримувати команди «назад» та «скасувати». Якщо користувач на кроці підтвердження адреси напише «змінити товар», бот має повернутися до кроку вибору складу, не обнуляючи вже введені дані.
State machine дає в 2–3 рази менше багів, ніж кастомні обробники діалогів — це доведено на десятках проєктів. Бот з state machine обробляє замовлення вдвічі швидше за звичайні скрипти.
Як ми інтегруємо бота з бекендом замовлень?
Бот не має містити бізнес-логіку. Він викликає методи API:
-
POST /orders/draft— створити чернетку -
PUT /orders/draft/{id}/items— змінити склад -
POST /orders/draft/{id}/submit— оформити -
DELETE /orders/{id}— скасувати
Типова проблема: бот дозволяє користувачеві додати товар, якого немає в наявності, і про це дізнається лише при фінальному submit. Це поганий UX. Перевірку наявності треба робити при додаванні позиції в чернетку.
Якщо використовується LLM для обробки повідомлень — function calling робить інтеграцію чистішою: модель викликає add_to_cart, remove_from_cart, apply_promo_code як інструменти, а не намагається розібрати намір через регулярки. Це дає вдвічі менше помилок розпізнавання та скорочує кількість покинутих кошиків на 25%.
UI на мобільному клієнті
Крім текстового чату, бот часто використовує структуровані елементи:
Quick reply кнопки — після питання «Спосіб оплати?» показуємо варіанти як тапабельні чипи, не змушуємо користувача друкувати.
Картки товарів — при підтвердженні складу замовлення показуємо міні-картки із зображенням, назвою, ціною. На Android це RecyclerView горизонтальної прокрутки всередині bubble повідомлення, на iOS — UICollectionView з horizontalScrollDirection.
Резюме замовлення — фінальний екран перед підтвердженням окремим компонентом, не plain text. Користувач бачить повний список, суму, адресу та кнопку «Оформити». Завдяки такому UI конверсія зростає на 15%.
| Компонент | iOS (SwiftUI) | Android (Jetpack Compose) |
|---|---|---|
| Quick reply | HStack з чипами | Row з Surface |
| Картка товару | LazyHStack з AsyncImage | LazyRow з AsyncImage |
| Резюме замовлення | List з Section | Column з Card |
Сповіщення про статус
Після оформлення замовлення бот продовжує роботу через push-сповіщення: «Замовлення прийнято», «Кур'єр виїхав», «Доставлено». На iOS — APNs через Firebase Cloud Messaging, на Android — FCM напряму.
Сповіщення містить deep_link з параметрами, які відкривають чат з історією цього замовлення, а не головний екран застосунку.
Процес роботи
- Проектування сценаріїв: звичайне замовлення, зміна, скасування, повторне замовлення, промокод.
- Розробка state machine на сервері + інтеграція з API замовлень.
- Мобільний UI: bubble layout, quick replies, картки товарів, резюме.
- Тестування нестандартних шляхів: переривання в середині, суперечливі команди, сесія, що закінчилася.
Технічні деталі state machine: на сервері state machine реалізована на Python з бібліотекою transitions. Стани та переходи описані в YAML-конфізі, що дозволяє змінювати сценарії без перескладання. Кожен стан має таймаут TTL — якщо користувач бездіє 30 хвилин, сесія завершується.
Що входить у результат
- Вихідний код сервера та мобільного клієнта
- Документація з API та сценаріїв
- Налаштування push-сповіщень та deep linking
- Тестування на реальних пристроях (iOS/Android)
- Інструкція з деплою в App Store та Google Play
- Гарантія 6 місяців на баги
На iOS використовуємо StoreKit 2 для in-app purchases та TestFlight для бета-тестування. Бот обробки замовлень на базі state machine підходить для складних сценаріїв.
| Етап | Тривалість |
|---|---|
| Проектування сценаріїв | 1–2 дні |
| Розробка state machine | 2–4 дні |
| Інтеграція з OMS | 2–3 дні |
| Мобільний UI | 3–5 днів |
| Тестування та налагодження | 2–3 дні |
Орієнтири за термінами
Бот з лінійним сценарієм (вибір → адреса → оплата → підтвердження) + мобільний клієнт — 1–1,5 тижні. З нелінійними сценаріями, інтеграцією з системою лояльності, історією замовлень та push-сповіщеннями — 3–4 тижні.
Наша команда має 8-річний досвід у мобільній розробці. Замовте аудит — ми запропонуємо оптимальне рішення. Отримайте консультацію — розповімо, як бот підходить вашому бізнесу.