Shipping questions look simple until a visitor needs a promise. \u201cWhen will it arrive?\u201d can mean when an order leaves the warehouse, time in transit, availability for a region, a daily cut-off, a weekend exception or an order-specific tracking update. A chatbot should make these boundaries clear rather than compress them into one confident estimate.<\/p>\n
Separate dispatch from transit. State which days count as business days, the local time zone for an order cut-off, regions served, delivery methods, exclusions, and what changes during peak periods. Put each exception next to the rule it qualifies. \u201cShips in 1\u20132 days\u201d is not useful if a visitor cannot tell whether that means warehouse dispatch or carrier delivery.<\/p>\n
Give the policy an owner and effective date. If a supplier\u2019s delay, seasonal restriction or remote-area surcharge is temporary, mark its scope and expiry. The chatbot should draw from the approved rule, cite it, and avoid turning a general range into an individual delivery promise.<\/p>\n
Use the same terms everywhere. If the site says \u201cdelivery\u201d in one place and \u201cdispatch\u201d in another, explain the difference. Headings such as \u201cWhen we dispatch,\u201d \u201cCarrier transit time\u201d and \u201cRegions and exclusions\u201d reduce the need for a chatbot to interpret vague prose.<\/p>\n
| Visitor question<\/th>\n | What the answer must establish<\/th>\n<\/tr>\n<\/thead>\n |
|---|---|
| \u201cI order at 16:50 on Friday\u2014when does it leave?\u201d<\/td>\n | Cut-off, time zone, business-day treatment and dispatch versus arrival.<\/td>\n<\/tr>\n |
| \u201cDo you deliver to the Isle of Skye?\u201d<\/td>\n | Whether the region is served and any published exception; no guess from a mainland rule.<\/td>\n<\/tr>\n |
| \u201cWill my parcel arrive tomorrow?\u201d<\/td>\n | Only a stated service condition, or a limit if individual order data is needed.<\/td>\n<\/tr>\n |
| \u201cWhy has my package not moved?\u201d<\/td>\n | A human or tracking route when the answer requires shipment data.<\/td>\n<\/tr>\n |
| \u201cDoes free delivery apply to bulky items?\u201d<\/td>\n | Threshold, exclusions and applicable product conditions.<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/figure>\nDo not claim order visibility you do not have<\/h2>\nVisitors commonly ask for tracking, address changes or an exception after dispatch. Unless the chatbot is explicitly connected to an order system and that scope is documented, these are human or self-service questions. Do not imply a tracking integration from a shipping-policy source. A helpful response can explain the published process and direct the visitor to the right contact route without pretending to inspect their parcel.<\/p>\n RobiFox\u2019s public measurement examples treat account-specific information as deliberately unanswerable when it requires system access. Its product materials also describe an honest refusal and a human handover where approved knowledge has no coverage. That boundary is especially important in delivery conversations, where a guessed date can become a customer expectation.<\/p>\n Use citations to keep the answer precise<\/h2>\nA good cited answer names the relevant element: \u201cOrders placed before the stated cut-off are dispatched on the next business day; the carrier\u2019s transit range is separate.\u201d The citation should open the policy that defines those terms. It should not point vaguely to a homepage or a generic contact page.<\/p>\n RobiFox says its answers show the page they came from and that a conversation record keeps the question, answer and referenced source. Those records give an operator evidence to inspect when a visitor says the chatbot promised something different. The source still needs to be clear and current; citations make a poor policy easier to discover, not correct.<\/p>\n Maintain the policy through changes<\/h2>\nWhen you change a courier, cut-off, region or free-shipping threshold, test the direct question and nearby variants before the new policy takes effect. Check regional wording and the path to a person outside business hours. RobiFox\u2019s review queue is intended to surface conflicting information, and its website re-read can process changed pages, but the business remains responsible for deciding the rule.<\/p>\n Keep older policies for internal reference, but remove them from active customer-facing sources. A clearer old page is still unsuitable evidence if it describes last winter\u2019s delivery schedule. If the replacement rule is not ready, use a human route rather than a provisional promise.<\/p>\n Review recurring shipping handovers and unanswered questions. A cluster around rural delivery may mean the policy needs an explicit paragraph. A cluster around parcel status may correctly remain human-only. Record the visitor page too, because a checkout-page question can expose different expectations from a help-centre question. The goal is not to automate every shipment conversation; it is to give visitors reliable published information and a clear path when the answer depends on their order.<\/p>\n For the product controls behind this approach, see RobiFox features<\/a>, How it works<\/a> and How we measure<\/a>.<\/p>\n For the next step, write clearer website FAQs<\/a>.<\/p>\n Cover image: AI-generated editorial illustration, not a product screenshot.<\/small><\/p>\n |