Бот-асистент для обробки замовлень у мобільному додатку
Бот обробки замовлень — це не просто чат. Це діалоговий інтерфейс поверх бізнес-логіки: створення замовлення, зміна складу, відстеження статусу, скасування. Кожна дія повинна бути атомарною та відкатуватися — користувачі можуть передумати на будь-якому кроці.
Управління станом діалогу
Оформлення замовлення через бота — це багатокрокова форма, розтягнута в часі. Між репліками користувачі можуть звернути програму, переключитися на іншу, повернутися за 10 хвилин. Стан повинен зберігатися.
Структура слотів для діалогу замовлення:
{
"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": "2024-01-15T14:30:00Z"
}
Стан зберігається на сервері (Redis з TTL 30–60 хвилин). Мобільний додаток відправляє тільки session_id з кожним повідомленням.
Критично: кожен крок діалогу повинен підтримувати команди «назад» та «скасувати». Якщо користувач на кроці підтвердження адреси напише «змінити товар», бот повинен повернутися до кроку вибору складу без втрати вже введених даних.
Інтеграція з бекендом замовлень
Бот не повинен містити бізнес-логіку. Він викликає методи 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 як інструменти, а не спробує розібрати намір через регулярні вирази.
UI на мобільному клієнті
Крім текстового чату, бот часто використовує структуровані елементи:
Quick reply кнопки — після запитання «Спосіб оплати?» показуйте варіанти як тапабельні чіпи, не змушуйте користувачів печатати.
Карточки товарів — при підтвердженні складу замовлення показуйте міні-карточки зі зображенням, назвою, ціною. На Android це горизонтально-прокручувальний RecyclerView всередині bubble повідомлення, на iOS — UICollectionView з horizontalScrollDirection.
Резюме замовлення — фіналь ний екран перед підтвердженням окремим компонентом, а не plain text. Користувачі бачать повний список, суму, адресу та кнопку «Оформити».
Сповіщення про статус
Після оформлення замовлення бот продовжує роботу через push-сповіщення: «Замовлення прийнято», «Кур'єр виїхав», «Доставлено». На iOS — APNs через Firebase Cloud Messaging, на Android — FCM напряму.
Сповіщення містить deep_link з параметрами, які відкривають чат з історією цього замовлення, а не головний екран програми.
Процес розробки
Проектування сценаріїв: звичайне замовлення, зміна, скасування, повторне замовлення, промокод.
Розробка state machine на сервері + інтеграція з API замовлень.
Мобільний UI: bubble layout, quick replies, карточки товарів, резюме.
Тестування нестандартних шляхів: переривання в середині, суперечливі команди, втрачена сесія.
Орієнтири за часом
Бот з лінійним сценарієм (вибір → адреса → оплата → підтвердження) + мобільний клієнт — 1–1,5 тижня. З нелінійними сценаріями, інтеграцією системи лояльності, історією замовлень та push-сповіщеннями — 3–4 тижні.