E-commerce Order Help

Give shoppers a practical post-purchase assistant: find an order, show status, route change/cancel/return requests, and collect support context.

The user wants a commerce or order-support bot for post-purchase workflows.

• What system should provide order data: API, ecommerce module, or staff/manual lookup?
• Which shopper identifier should be collected: order number, email/phone, or platform profile?
• Which actions are allowed: tracking only, delivery change, cancel before fulfillment, return after delivery, refund request, or support handoff?
• Where should support and return-policy links point?

• Open a compact order-help menu
• Ask for the order number when the bot does not already have one
• Load an order snapshot through an API or a clearly marked placeholder action
• Show status, ETA, and tracking link
• Route change/cancel/return requests through an eligibility check
• Collect issue details before sending the shopper to support

Good to know

• A production order lookup should use HTTP_REQUEST or an installed ecommerce module to read order status, tracking URL, ETA, and eligibility.
• If no order API is available yet, keep the lookup action as explicit SET_VARIABLE placeholders so the flow remains testable without pretending to be integrated.
• Route cancel/return/change requests through an eligibility branch; do not show destructive actions as final success without checking the current order status.
• Before telling the shopper that an action request was saved, run an explicit placeholder save action or replace it with an HTTP_REQUEST to the order/support system.
• Tracking links should use an INLINE URL button only after trackingUrl is known or safely defaulted.
• Use START_CONVERSATION in the support handoff flow so live support opens inside the workspace instead of only linking to an external page.
• Support handoff should collect orderId and orderIssue first so staff receive actionable context.

Keep in mind

• Do not create fake ecommerce module actions unless an installed module template exists.
• Do not show cancel, refund, or return as completed without an eligibility check or support fallback.
• Do not ask for every possible customer detail up front; collect the order identifier first, then ask for issue details only when needed.
• Do not route all outcomes to the same generic support message.