What the documents look like
On a Shopify standalone store, the merchant configures payment, shipping and fulfillment services directly. There is no platform-wide automatic return process comparable to a marketplace that centralizes returns. This difference shapes how after-sales conversations are designed, because the assistant must trace each question back to a specific record rather than to a single platform status.
Four record families feed the conversation: order details, shipping templates, shipping labels and refund records. They originate from Shopify Admin, payment gateways, carrier systems and inventory location data. Their status fields do not align by default. An order marked as paid is not thereby marked as shipped. A purchased shipping label is not evidence that the carrier has collected the parcel. A created refund record is not evidence that funds have reached the buyer's account. Multi-turn dialogue has to ask and cross-check between these states. Records update per order and daily. This page does not depend on batch synchronization or transaction-triggered mechanisms.
Constraints at the multi-turn prompts step
Prompts need to state the material scope, the answering task and how missing evidence is handled. The model does not fill in business facts on its own.
For history, when a non-empty chatId is supplied, the system retrieves the session from the database and uses the last element of the messages array as the user question; the remaining messages are ignored. When chatId is not supplied, context is built entirely from the messages array. The two inputs carry different content, so verification must distinguish a new session from a continued session.
For question optimization, when continuous knowledge-base dialogue is required, check coreference resolution and question expansion. Short questions do not automatically qualify.
For model and length, check the context the model supports and the reply settings, and test long documents combined with follow-up questions. For reply format, choose according to the downstream consumer. When json_schema is selected, fill in the corresponding format requirement and verify the returned structure.
Retrieval is not authorization. A similarity score is not a permission or entity filter.
Hypothetical paper exercise. The material text reads: "Order A was created on 2 March, payment status is paid, fulfillment status is unshipped, refund record is empty." A separate shipping template states: "East China region, first 1 kilogram, shipping fee 8 yuan." The draft sentence to be judged is: "Order A has shipped, expected delivery on 5 March, and the refund request has been accepted." The request is: "Please have the agent reply to the buyer about logistics and refund progress based on the above materials."
Configuration and implementation checks
| Configuration or check item | Value or state in this page's sample | Check method and basis |
|---|---|---|
| chatId | Hypothetical starting point: a session identifier dedicated to the sample | When supplied, the stored session is retrieved; when omitted, context is built from messages. Compare the two inputs. |
| messages | Last element is the buyer's follow-up text | Only the last element serves as the user question; the rest are ignored. Check what is carried in. |
| Memory rounds | Hypothetical starting point: a small number of history rounds | Reason: after-sales follow-ups need prior context. Compare against a no-chatId input built purely from messages. |
| Temperature | Hypothetical starting point: low | After-sales answers need stability. Compare answer variation against the default. |
| Reply format | Keep default | Select json_schema only when the downstream consumer needs a fixed structure, then fill in the format requirement. |
| Multimodal recognition | Chosen according to model capability | The dialog shows available options based on the model. Image recognition requires an image input. |
Three common errors
- Reading the order detail's paid status as shipped. Input is the sample material text; the compared field is fulfillment status unshipped; the observable result is that the draft sentence's "has shipped" lacks material support.
- Reading an empty refund record as an accepted refund. Input is the sample material text; the compared field is refund record empty; the observable result is that the draft sentence's "refund request has been accepted" is an addition.
- Treating a similarity score as a permission or entity filter. Input is the returned score and quoteList; the compared object is the authorized scope; the observable result is that a high-similarity record may still fall outside the answerable scope.
How to verify the setup
- Input the sample material text and the draft sentence. Compare each assertion in the draft sentence against the source subject, object and status. Judge consistency only when the source explicitly states the corresponding status. In this sample, "has shipped" and "refund accepted" are unsupported and should be recorded as pending verification.
- Input two consecutive follow-up rounds under the same chatId. Compare the history carried into the second round against the first-round question. Observe whether the last messages element serves as the user question and whether the rest are ignored. When chatId is omitted, compare whether context comes entirely from messages.
- Input a paper empty result [] to check the downstream design. Compare whether the downstream handles it as an output with no references. Do not claim that a fictional rule-based retrieval necessarily returns []. For libraries across different vector models, first check identifiers and exclude non-matching ones, record actual observations, and do not infer missed recall or redundant results.