Order and delivery enquiries
Order enquiries are almost entirely a grounding problem. Connect answers from Knowledge, from files in the workspace and from the data grid, and refuses what none of those support rather than producing a plausible delivery date. What it does not have out of the box is a connection to your order system — that has to be supplied.
Where an answer can legitimately come from#
- Knowledge
- Sources the workspace supplies that answers must be grounded in, plus the Facts extracted from them. Policies, timescales, what happens when something is damaged — the answers that are the same for everybody.
- Files
- Attached by button, drop or paste, and read with the standard library: PDF, DOCX, XLSX, CSV and TSV, PPTX, images, TXT, MD and JSON. A dispatch spreadsheet is a legitimate source for a question about a specific order.
- The data grid
- An Excel-like view over 13 record sheets — companies, people, leads, prospects, follow-ups, deals, conversations, calls, cases, onboarding, knowledge, files and memory. Every change goes through the service that owns the record; the grid is not a second database.
- The relationship itself
- Once the sender resolves to a Person, their previous conversations, calls, cases and follow-ups are available to ground a reply.
What happens when the answer is not known#
It is refused, and the refusal is recorded with the rule that caused it. That is the behaviour you want on this use case specifically: a delivery estimate invented to be helpful becomes a promise the business has to honour, and a refund or replacement terms improvised on a call are a commercial term — refused by safe_sales and escalated to a person.
The practical effect is that the quality of order support tracks the quality of what you have written down, almost linearly. The decision log is therefore the most useful document you will have in the first month: it is a ranked list of the questions your Knowledge cannot yet answer.
Connecting real order data#
Decide the smallest thing that answers most enquiries. Usually a status and a date, keyed by an order reference the customer already quotes.
Result You avoid modelling your whole commerce stack to answer four questions.
Put it somewhere readable: a file the workspace holds, facts in Knowledge, or records pushed through the integration surface with an integration key.
Result The Assistant read-only tools —
data_query,read_file,ask_file,find_anything— can then ground an answer in it.Keep it fresh. Stale order data produces confident wrong answers, which is worse than a refusal.
Result A refusal sends the customer to a person; a stale answer sends them away satisfied and back angry.
Decide what a change request is allowed to do.
Result Cancelling, amending or refunding are actions in your systems, not in Connect. They become follow-ups and escalations.
The channel constraints that bite here#
- No dispatch text messages. Outbound SMS is provider-dependent and the live carrier carries none, so the classic despatch notification is not available. WhatsApp and email are the working channels.
- WhatsApp behaviour is the provider behaviour. Templates, session windows, media handling and delivery reporting are provider-dependent and are not simulated.
- Voice costs more than the enquiry is usually worth. A call is priced on audio tokens; a two-line order status question is cheap on email and not cheap on the phone. Answer where the customer wrote.
- No carrier tracking lookup. Nothing here documents a courier integration; a tracking number is data you supply like any other.
Cost and volume#
Order enquiries are high-volume and low-value individually, which suits the economics: text replies bounded by the daily allowance rather than priced per message. The allowance, not the model, is the ceiling — and when it is spent work is held rather than dropped, with the read cursor staying put so nothing is skipped.
The cost that grows unexpectedly is voice, when order enquiries arrive by phone during a promotion. If that is your pattern, look at the call length distribution rather than the call count.
Questions#
Can Connect look up an order status by itself?
Only from data it can read. There is no orders sheet among the thirteen and no built-in commerce connector documented here, so the answer comes from a file, from Knowledge, or from records pushed in through the integration surface. Without one of those, an order-status question is refused and escalated.
What stops it inventing a delivery date?
Grounding, plus the commercial-terms rule. An answer Knowledge cannot support is refused rather than improvised, and a delivery promise is treated as a commitment rather than as small talk. The refusal is recorded with its rule, so the gap is visible instead of being smoothed over.
Can a customer cancel or amend an order through Connect?
Not in your systems — Connect changes its own records, not somebody warehouse. What it does is capture the request against the relationship, create a follow-up with a reason, and escalate anything with a commercial consequence so a person makes the decision and the record shows who did.