E-commerce
June 28, 2026
"Your agent promised me delivery on Friday. It's Monday, and still nothing." The ticket reopens. The previous agent wanted to reassure. The brand pays in lost trust, public reviews, and sometimes chargebacks.
ORNER points out that in 2026, only 9% of consumers believe that retailers keep their delivery promises (ORNER, delivery expectations 2026). eesel AI distinguishes between hallucination of facts and inventing commitments: "I'm on it," "refund within 48 hours," "delivery guaranteed Thursday" (eesel AI, hallucinations 2026).
This guide #209 addresses false support promises: deadlines, refunds, exceptions. Distinct from response consistency (#191) (multi-channel sync) and AI governance (#142): here, do not promise what ops cannot execute.
Summary
Why does a false support promise cost more than a delay?
A false e-commerce support promise creates an implicit contractual expectation. The customer plans, waits, and then feels betrayed. An honest delay irritates. A broken promise humiliates.
Three measurable consequences
Reopened ticket + chargeback: the customer quotes the agent word for word
1-star review: "I was lied to" weighs heavier than "late package"
Lasting loss of trust: repeat purchases collapsed in the affected segment
Promise Drift
Promise Alignment describes "Promise Drift": the gap between what support commits to and what ops delivers (Promise Alignment, AI support 2026). In DTC e-commerce, the agent or the bot becomes the voice of the brand at the most fragile moment: lost package, delay, defective product.
Promise vs. information
"Standard delivery time 3-5 business days according to our delivery page" = information. "I guarantee you Thursday" = promise. The boundary lies in the verb and the certainty.
How does it differ from neighboring guides?
Four contents, four angles on the quality of responses.
Consistency (#191)
Consistency (#191): help hub, bot, and agent convey the same policy. Article #209 addresses the case where a single response promises too much, even if consistent with the others.
AI Governance (#142)
Governance (#142): RACI, validation, kill switch. Article #209 details forbidden phrasings and anti-promise guardrails.
Hallucinations (#123)
Hallucinations (#123): invented facts (product spec). Article #209 covers invented commitments ("refund approved").
Delay communication (#184, bot shipping)
Delay communication and shipping bot (#203): how to inform. Article #209: what is forbidden to guarantee.
Promise #209
Promise typology, say/do not say table, bot guardrails, agent training, post-promise recovery, breach KPIs.
What types of false promises are the most common?
Map out the support promises at risk before drafting your guardrails.
Top 8 high-risk commitments
Guaranteed delivery date: "Thursday without fail" without data carrier
Fixed refund processing time: "within 48 hours" whereas BNPL = 5-14 days
Unvalidated exception policy: "return accepted past deadline" without a manager
Approved refund: junior agent who "grants" it without Shopify processing
Stock / restocking: "we are receiving some tomorrow" without warehouse visibility
Immediate ops action: "I am cancelling the shipment" when the package is already picked
Promised compensation: "€20 voucher sent tonight" without workflow
Fictional escalation: "the director will call you back" without a ticket created
Triggering customer verbatims
"You promised me", "the agent assured me that", "your bot said it was guaranteed". Helpdesk tag: promise_breach, priority P1.
Why do agents and bots over-promise?
Understanding the root causes of support over-promising guides training, not just prohibitions.
Human Agent Side
Misaligned empathy: wanting to appease at all costs
SLA pressure: closing quickly with "good news"
Vague policy: no written limits on deadlines/refunds
Junior without a decision tree: copying the senior agent who was improvising
AI Bot Side
Double2 observes that LLMs learn reassuring phrasings ("rush delivery available") without checking zip code, stock, or cut-off constraints (Double2, guardrails 2026). AskDolphin recommends removing exact date promises from the bot corpus by default (AskDolphin, support without doubtful answers).
Marketing Spillover Side
A "delivery tomorrow everywhere" banner despite a 2 p.m. cut-off and excluded areas. Support inherits the marketing promise that is impossible to keep.
Which formulations should be allowed and prohibited?
A "say / don't say" table aligns agents, macros, and bots on the same level of caution.
Delivery and Lead Times
Forbidden: "guaranteed Thursday", "without fail tomorrow", "I personally guarantee"
Allowed: "estimated delivery Thursday, April 4th, subject to carrier", "indicative lead time 3-5 business days"
Refunds and Gestures
Forbidden: "refund approved", "you will be credited tomorrow"
Allowed: "I have initiated the request, standard bank processing time is 5-10 days", "our finance team processes this within 48 business hours"
Exceptions Policy
Forbidden: "exception made for you" without manager approval
Allowed: "I am forwarding your request to our manager, response within 24 hours"
Reassurance Without Commitment
Replace "don't worry, it's sorted" with "I understand the urgency, here is the status of your case: [factual status]". MarqueFactory: the bot explains, it does not approve (MarqueFactory, e-commerce agents 2026).
What bot guardrails prevent over-promising?
Three layers of bot anti-promise guardrails: hard boundaries, validation, escalation.
Layer 1: hard boundaries
Never an exact delivery date without carrier API + order status
Never "refund confirmed" without Shopify refund succeeded webhook
Never a discount > agent ceiling without manager intent
Never "shipment cancellation" if fulfillment status = fulfilled
Layer 2: output validation
Post-generation filter: detects guarantee verbs (guaranteed, promised, assured, without fail) → auto-rewrite or block. Double-check: parse DELIVERY_TIME = tomorrow → check MIN_DELIVERY = 3 days → FAIL → safe response.
Layer 3: mandatory escalation
Client insists on a precise date, threatens review, amount > threshold, policy exception. Human handoff with promise_risk flag. See handoff (#12).
Standard system instructions
"Always use "estimated", "depending on carrier", "usual timeframe". If information is unavailable, say so and offer an agent. Never invent a commitment."
How do you train agents not to make promises?
The anti-promise agent training complements the bot guardrails: the human remains the source of unscripted promises.
Decision tree before commitment
Can I verify this fact in Shopify/carrier now?
Does the policy authorize this exception?
Does my agent cap cover this gesture?
If no to any: escalation or cautious formulation
Safe macros vs. risky macros
Replace macro WISMO-OLD "your package arrives tomorrow" with WISMO-SAFE "current status [X], estimated delivery [date range] according to [carrier]". Quarterly audit: grep "guaranteed", "promised", "without fail" in all Gorgias macros.
Onboarding roleplay (15 min)
3 scenarios: furious customer with birthday delay, immediate refund request, out-of-time return exception. Score: 0 forbidden promise = certified. SurveyMonkey: 89% want a human option; the human must be reliable, not lax (SurveyMonkey, CX 2026).
Mandatory internal note
If agent makes a manager-validated exception: ticket note "Exception approved [manager] on [date]: [detail]". Traceability in case of dispute.
How do you recover when a promise has already been made?
The broken promise recovery playbook limits damage when the error is proven.
Step 1: acknowledge without jargon
"You were right to expect a shorter timeframe. The current estimated delivery is [date]. I understand the frustration." No generic "sorry for the inconvenience."
Step 2: immediate factual status
Live tracking, Shopify refund status, name of the ops lead contacted. Zero new promises to make up for the first one.
Step 3: validated proportionate gesture
If the ops promise is proven false (agent said "shipment cancelled" but package sent): free return shipping, €10-15 voucher, or express upgrade if still possible. Manager validation if > ceiling.
Step 4: internal post-mortem
Tag promise_breach, root cause (macro, bot, agent, marketing), corrective action within 48 hours. Shippit: closing the "promise gap" checkout vs reality reduces disputes (Shippit, promise gap 2026).
How to align marketing, checkout, and support?
False support promises are often born upstream of the ticket.
Checkout and PDP
Display delivery windows based on 90-day carrier data, not vague "fast delivery." Shippit observes retailers announcing 5.2 days at checkout for 2.2 actual days: an acceptable under-promise; the opposite (promising 2 days, delivering 5 days) destroys trust.
Marketing banners
Before a "free 24h delivery" campaign: ops validation + support brief with updated macros. See delivery communication (#204).
Policy change sync
Flow #191: policy → CSR → hub → bot → macros. Refund delay modified? Remove all mentions of "48h" from the corpus within 24 hours.
Carrier notifications
WARNING: false "delivered" notification = broken promise at the worst moment. Audit tracking apps that send premature statuses.
Which errors amplify the risk?
Five support promise anti-patterns to eliminate as a priority.
Mistake 1: aggressive marketing bot
"I'll sort that out for you" on lost package disputes. Fix: immediate handoff, no false hope.
Mistake 2: promising just to close the ticket
Agent promises a refund to get a "thank you" and close. Fix: only close after Shopify action is confirmed.
Mistake 3: copying and pasting obsolete macros
2024 macro saying "45-day return" when policy is 30 days. Fix: review date on each macro + owner.
Mistake 4: no agent limit
Junior agent promises an €80 voucher. Fix: VIP policy (#207) limits and escalation matrix.
Mistake 5: ignoring "you promised me" tickets
Treating them like standard WISMO. Fix: P1 promise_breach queue, senior agent, playbook section 8.
How does Qstomy avoid over-promising?
Qstomy separates catalog information and engagement ops via built-in guardrails.
Anti-promise features
Guarantee verb filter: auto-rewrite to estimated formulations
Live Shopify ETA: date range based on order status, not LLM
Refund promise block: displays actual refund status or triggers escalation
promise_risk intent: handoff if client refers to an agent promise
Commitment log: tracks any high-risk phrasing for QA
Quantified DTC Scenario
Home brand, 6.2% of tickets mentioning "promised/guaranteed", dispute segment CSAT 41/100. Deployment of Qstomy guardrails + say/do not say table + agent training + macro audit. After 10 weeks: promise_breach tickets -52%, post-closure reopenings -31%, chargebacks for "broken promise" reason -44%, dispute CSAT +18 pts (41 → 59).
Explore AI customer support, Shopify integration, request a demo.
Which operational playbooks should be launched in 30 days?
Playbook 1: promises audit (3 h)
Grep macros + bot corpus: guaranteed, promised, flawless, approved, tomorrow. List 20 occurrences. Classify safe / to correct / delete.
Playbook 2: do/do not say table (2 h)
Draft section 5 by top 10 volume intent. Validation lead support + ops. Publish Notion sidebar agents.
Playbook 3: bot guardrails (1 d)
Implement 4 hard boundaries section 6. Test 15 aggressive customer verbatims. Zero forbidden promises in output.
Playbook 4: training + roleplay (2 h)
Team session section 7. Certify agents. Forbid non-certified macros to juniors.
Playbook 5: KPI W+4
Ticket rate tag promise_breach, reopenings, chargebacks motive promise, audit score 10 gold questions (intent delay/refund). Monthly review.
Useful mesh
Trustworthy support does not promise faster. It promises less, more accurately, and keeps its word.
Enzo
June 28, 2026
