Order Processing Assistant Bot in Mobile App
An order-processing bot is not just a chat. It's a conversational interface over business logic: order creation, composition changes, status tracking, cancellation. Every action must be atomic and reversible — users can change their mind at any step.
Dialog State Management
Placing an order through a bot is a multi-step form stretched across time. Between messages, users might minimize the app, switch to another app, return 10 minutes later. State must persist.
Structure of slots for order dialog:
{
"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"
}
State is stored on the server (Redis with 30–60 minute TTL). The mobile app sends only session_id with each message.
Critical: each dialog step must support "back" and "cancel" commands. If the user, on the address confirmation step, writes "change item", the bot should return to the item selection step without losing already-entered data.
Backend Order Integration
The bot shouldn't contain business logic. It calls API methods:
-
POST /orders/draft— create draft -
PUT /orders/draft/{id}/items— change composition -
POST /orders/draft/{id}/submit— place order -
DELETE /orders/{id}— cancel
Typical mistake: bot lets users add out-of-stock items and discovers it only on final submit. Poor UX. Check availability when adding to draft.
If using an LLM for message processing — function calling makes integration cleaner: the model calls add_to_cart, remove_from_cart, apply_promo_code as tools, not trying to parse intent via regex.
Mobile Client UI
Beyond text chat, the bot often uses structured elements:
Quick reply buttons — after "Payment method?" show options as tappable chips instead of forcing typing.
Product cards — when confirming order composition, show mini-cards with image, name, price. On Android, this is a horizontal-scrolling RecyclerView inside the message bubble; on iOS, a UICollectionView with horizontalScrollDirection.
Order summary — final screen before confirmation as a separate component, not plain text. Users see the full list, total, address, and "Place Order" button.
Status Notifications
After placing an order, the bot continues via push notifications: "Order received", "Courier en route", "Delivered". On iOS — APNs via Firebase Cloud Messaging; on Android — FCM directly.
Notifications contain deep_link with parameters that open the chat with this order's history, not the app home screen.
Development Process
Designing scenarios: normal order, changes, cancellation, repeat order, promo codes.
Building state machine on server + integrating with order API.
Mobile UI: bubble layout, quick replies, product cards, summary.
Testing edge cases: interruptions mid-way, conflicting commands, expired session.
Timeline Estimates
A bot with linear flow (select → address → payment → confirm) plus mobile client — 1–1.5 weeks. With non-linear flows, loyalty system integration, order history, and push notifications — 3–4 weeks.







