A quick-commerce service assistant designed around policy and permitted actions

01

Business context and previous workflow

A quick-commerce support team receives many order questions. A user can ask about a delayed order, a missing item, a cancellation, a refund, or another policy issue. The answer can depend on order state, customer identity, policy, and the action that the order system permits.

A person must often find the policy, check the order, explain the result, and decide whether another team must take over. The proposed assistant brings these steps into one controlled interaction. It does not remove the support team or give a model direct authority over an order.

02

Designed scope

The design uses a primary routing layer and specialised tools. The router classifies the intent and asks for missing details. A policy tool returns approved guidance. Order tools expose narrow functions for the supported states and actions. A handoff route sends unsupported, uncertain, or sensitive cases to a person.

The system keeps session context, logs the intent and tool used, and records latency and response details for operations. The design also covers a Google Cloud deployment path, test stages, and environment controls. These elements are architectural scope. The source does not show a completed production release.

• Intent classification and clarification
• Approved policy retrieval
• Order-status-aware tool selection
• Narrow permitted actions
• Human handoff and operating logs

03

Control and review points

The application must check identity and order access before it returns protected information or requests an action. Policy data must have an owner and version. Tool arguments must match an approved schema. A document or user message cannot add a new permission.

A model can propose the next action. Application code decides whether the action is available for the current user and order state. A material action can require confirmation or a support review. Logs must avoid unnecessary personal data while keeping enough detail for diagnosis.

04

Results and next validation step

The design provides a clear route for policy answers, order actions, and human transfer. It does not provide a verified resolution rate, cost saving, handling-time reduction, or production adoption measure.

A pilot should use representative intents and order states. The team should measure correct routing, policy accuracy, tool denial, handoff quality, latency, reviewer corrections, and customer completion. A production claim requires an accepted deployment record and measured results.