E-commerce
July 1, 2026
"I wrote 48 hours ago, still no response." "You promise a response within 2 hours on the chat, nobody answers." "Is it normal to wait 5 days for a refund?" Three messages where the customer is not asking for a business resolution, but an explanation regarding the support response time.
The e-commerce support response time questions align public promises, internal SLAs, and agent responses when the customer is waiting for a human reaction. Without a policy, every "why no news" ticket becomes a vague excuse or an over-promise.
This guide #401 covers the RESP-COMM policy, the RESP-FLOW flow, and the resp_wait KPI. It distinguishes itself from the internal SLA (#101) (operational definition of FRT) and the future schedule bot (#402): here, customer communication and customer service management of response time expectations.
Summary
Why do queries about response times overload customer support?
A support response delay ticket arrives when the customer has not received updates since their initial request, or compares your delay to a displayed promise.
Five typical customer frustrations
Perceived silence: Day+2 email with no auto-reply or update
Widget promise: "response in 2 mins" but human queue is full
Resolution confusion: refund processing time ≠ support response delay
Forgotten weekend: message sent Friday evening, waiting until Monday
Double channel: Instagram follow-up + email, no sync
Eightx places email FRT for e-commerce leaders at 1-2 hours, industry average is 8-12 hours (Eightx, channel resolution 2026). HubSpot highlights that 90% of customers expect an immediate response to chat (HubSpot, customer service 2026).
Angle #401 vs related content
Internal SLA #101: FRT ops grid, Gorgias configuration. #401 = customer communication and "why no response" tickets.
Hours Bot #402: future availability automation. #401 = agent processes and promise touchpoints.
Weekend #403: out-of-hours coverage. #401 = explaining delays when the team is unavailable.
Refund #370: refund processor status. #401 = support first response delay, not bank delay.
Bot handoff: agent wait post-bot. #401 = promise and updates during human wait time.
DTC Example
Fashion brand, "response in 4 hours" widget, 78 resp_wait tickets/month. After RESP-COMM + RESP-FLOW: resp_wait_fcr 84%, resp_expectation_miss -43%, resp_followup_ticket_rate -38%.
Typical resp_wait volume
3% to 12% of inbound tickets are response delay follow-ups or FRT confusion. Auto-reply + tier 0 bot cuts this in half.
How does response time differ from resolution time?
The customer often confuses first response and resolution time. Two promises, two support responses.
Delay Matrix → customer message
FRT (#401 focus): delay of first substantial response
Resolution: ticket closure delay (return, refund, investigation)
Processor delay: post-refund approved bank delay
Carrier delay: parcel transit, not support
Customer waiting formula
"We have received your message. First response under {{frt_promise}}. Estimated resolution: {{resolution_promise}} depending on the nature of the request." Two distinct lines in macro RESP-ACK.
Channel and FRT
Chat bot: < 30 s tier 0. Human chat: pickup < 2 min. Email: 4-24 business hours depending on #101. Instagram DM: < 60 min if promised.
Promise #401
Policy RESP-COMM, typologies resp_wait_*, flow RESP-FLOW, touchpoints widget/auto-reply, macros RESP-*, KPI resp_wait.
Which resp_wait_* typologies should be mapped?
Twelve response time ticket typologies for consistent routing.
Twelve resp_wait scenarios
resp_wait_email_early: Day 0/Day 1 email within normal SLA
resp_wait_email_sla_exceeded: email past promised SLA
resp_wait_chat_queue: human chat, waiting > 2 min
resp_wait_chat_offline: message outside business hours
resp_wait_bot_handoff_pending: bot escalated, agent has not picked up yet
resp_wait_followup_same_ticket: follow-up "still no news"
resp_wait_cross_channel: wrote email + Instagram, confusion
resp_wait_weekend_gap: Fri-Sat message, waiting for Monday
resp_wait_peak_backlog: BFCM, announced extended delay
resp_wait_resolution_confusion: confuses FRT and refund timeline
resp_wait_vip_expectation: VIP customer, priority response expected
resp_wait_threat_chargeback: threat if no quick response
Helpdesk Tags
resp_wait, resp_sla_ok, resp_sla_miss, resp_followup, resp_off_hours. Distinct wismo, refund_status, complaint.
Intake data RW-1
original ticket_id, channel, created_at, last_agent_reply_at, hours_since_last_reply, Gorgias sla_status, business_hours flag, customer_verbatim.
How to write the RESP-COMM policy in eight rules?
The response time communication policy RESP-COMM documents public promises and agent responses aligned with SLA #101.
Eight RESP-COMM rules
Public promise = SLA kept 90 %+: safety margin for widget/contact page
Immediate auto-reply: email/DM acknowledges receipt + estimated FRT + ticket #
Distinction FRT / resolution: always two timeframes in macro
Out of hours: bot message + explicit team return time {{next_open}}
Proactive update: if resolution > 48 hours, intermediary message to client
Peak communication: banner + widget if email FRT x2 (BFCM)
Do not over-promise on chat: "2 min" only if median pickup < 2 min 80 %+
Escalation resp_sla_miss: supervisor responds within 2 hours if breach confirmed
Publication touchpoints
Chat widget: "Usually replies in X min/hrs · Bot 24/7". Page /contact: channel table → FRT delay. Email footer: ticket status link.
Alignment #101
Public email promise "within 24 business hours" if internal SLA is 8 hours. Never display raw internal SLA to the client.
Prohibited RESP-COMM
"Instant reply" email. "24/7 human" if bot only at night. Blaming client for follow-up.
Contact page template
Table: Chat bot 24/7 instant · Chat human Mon-Fri 9am-6pm reply ~5 min · Email reply within 24 business hours · Instagram DM within 4 business hours.
How to apply the RESP-FLOW flowchart in eight steps?
The RESP-FLOW framework structures the ticket response response time.
Eight steps RW-1 to RW-8
RW-1 Intake: ticket_id, verbatim, typology resp_wait_*
RW-2 Read original ticket: created_at, channel, tags, last response
RW-3 Check Gorgias SLA: within SLA | breach | off_hours | pending agent
RW-4 Classify: early OK | sla_miss | confusion resolution | cross_channel
RW-5 Answer substance: process initial request IF not already done
RW-6 Explain delay: macro RESP-* grounded RW-3 data
RW-7 Escalate: confirmed sla_miss, VIP, chargeback threat
RW-8 Document: ticket note, tag resp_*, update proactive scheduled
RW-5 critical rule
Ticket resp_wait often symptom: initial request unprocessed. RW-5 resolves the core issue (return, WISMO) BEFORE or WITH RW-6 delay explanation.
RW-4 decision tree
within SLA + early → RESP-OK-01 reassurance
sla_miss → RESP-MISS-01 apology + priority processing
off_hours → RESP-OFF-01 next slot
resolution confusion → RESP-RES-01 FRT vs refund
handoff pending → RESP-HAND-01 queue status
SLA answer resp_wait
Ticket resp_wait: agent first response 2 hours. Confirmed sla_miss: supervisor 1 hour.
RW-3 Gorgias SLA check
Agent sidebar: SLA clock green/red. RESP-FLOW cites grounded status, not agent impression of delay.
Which RESP-* macros for agents?
Ten agent response delay macros cover 90% of resp_wait tickets.
RESP-ACK-01 (email acknowledgment of receipt)
"Thank you {{first_name}}. Message #[ticket_id] received on [date]. First response under [frt_promise]. Resolution based on request: [resolution_hint]. Follow-up: [ticket status link]."
RESP-OK-01 (within SLA, early)
"Your request #[X] is being processed. Usual typical first response time: [frt]. An agent will respond to you within [ETA]. Thank you for your patience."
RESP-MISS-01 (SLA exceeded)
"We apologize for the delay exceeding our commitment. Your request has been prioritized. Full response within 4 business hours. Ticket #[X] assigned."
RESP-OFF-01 (out of hours)
"Team available Mon-Fri 9 AM-6 PM (Paris). Bot active 24/7 for order tracking. Next agent response: Monday 9 AM. Ticket number #[X] registered."
RESP-RES-01 (resolution confusion)
"Refund approved on [date]. Bank processing time 5-10 business days. Distinct from support response time: we responded on [agent_reply_date]."
Other macros
RESP-HAND-01: bot handoff, agent within 15 min or queue ETA
RESP-PEAK-01: BFCM extended delay, proactive update
RESP-CROSS-01: merge channels, single ticket
RESP-VIP-01: queue priority, FRT 1 h
RESP-UPDATE-01: intermediate message for long investigation
Macro rules
Always cite ticket # and grounded FRT #101. Never blame client follow-ups. RW-5 bottom processed before RESP-OK alone.
Which touchpoints should be configured for customer expectations?
The response time promise touchpoints prevent resp_wait tickets upstream.
Seven RESP-COMM touchpoints
Chat widget: median FRT + "bot available now"
/contact page: channel table, response time, hours
Email auto-reply: Gorgias RESP-ACK-01 template
Offline chat message: RESP-OFF-01 after hours
Bot handoff message: agent ETA + ticket #
Peak site banner: email FRT x2 during high-traffic periods
Ticket status page: customer sees the latest response, no need to follow up
Chat widget calibration
Measure median pickup for 30 days. Display rounded P80 + margin. If queue > 5 min: dynamic message "current wait ~X min".
Mandatory auto-reply
100% of incoming emails receive RESP-ACK within 5 min via bot/rule. Reduces resp_wait_email_early by 40-60%.
Self-service link
Auto-reply includes WISMO bot #184 link, return portal, FAQ. Align with self-service (#28).
Instagram DM
Meta auto-reply + ticket number if routed to Gorgias. Prevents resp_wait_cross_channel.
Ticket status portal
Gorgias Help Center or branded page: customer sees status without follow-up email. Reduces resp_followup_ticket_rate by 25-35%.
How to manage peak, VIP, and chargeback threats?
Three response time edge cases require dedicated RESP-COMM playbooks.
BFCM Peak
Double the email FRT displayed on the widget. RESP-PEAK-01 macro. Proactive update at D+2 if investigation is lengthy. Align with BFCM plan.
VIP queue
Shopify VIP tag → priority Gorgias queue. RESP-VIP-01. Internal FRT 1 hr, customer communication "handling priority". See VIP escalation.
Chargeback threat resp_wait
resp_wait_threat_chargeback: supervisor within 1 hr, handle root cause + RESP-MISS. No refund promise solely to speed up response.
Bot handoff waiting
RESP-HAND-01: "Agent assigned, response within [ETA]. Summary transmitted: [intent]." Align with bot handoff.
Investigation > 72 hrs
Automatic RESP-UPDATE-01 on D+2 and D+4: "Investigation in progress, update on [date]." Reduces resp_followup_same_ticket.
Which resp_wait KPIs should be measured?
The communication response time KPIs link public promise and satisfaction.
Eight key metrics
resp_wait_ticket_rate: resp_wait tickets / total inbound
resp_wait_fcr: resolved without reopening within 72 hours
resp_expectation_miss_rate: customer mentions broken promise
resp_followup_ticket_rate: "still no news" follow-ups
auto_reply_coverage: % emails with ACK < 5 min
public_promise_accuracy: FRT widget vs actual median 90 days
resp_sla_miss_recovery_time: delay post RESP-MISS
resp_wait_csat: satisfaction post RESP-FLOW
DTC Benchmark
resp_wait_ticket_rate 3-8% inbound, resp_wait_fcr 80-88%, resp_expectation_miss < 2%, auto_reply_coverage 98%+, public_promise_accuracy gap < 15% widget vs actual.
Weekly dashboard
Top resp_wait_* typologies, Gorgias sla_miss correlation, resp_wait vs global CSAT, widget promise vs median pickup.
Ops alert
resp_expectation_miss > 5%: review widget/contact page within 48 hours.
CSAT correlation
resp_wait tickets have CSAT 0.6 pt below average if RW-5 background issue is unresolved. RW-5 + RESP-OK combo restores CSAT.
What response time anti-patterns should be avoided?
Ten response time communication anti-patterns to ban.
1. Email "instant response" widget
Impossible promise. Customer cites resp_wait in ticket.
2. Replying about the delay without addressing the core issue RW-5
Customer follows up on Day+1. Double ticket.
3. Blaming the customer "you have already written"
CSAT killer tone. RESP-MISS empathy mandatory.
4. Confusing FRT and refund delay
RESP-RES-01 systematic if refund pending tag is present.
5. No email auto-reply
24-hour silence = avoidable resp_wait.
6. Raw public SLA #101
Internal "FRT 4 h" ≠ 24-hour margin customer promise.
7. Offline chat without bot message
Customer feels ignored. RESP-OFF-01 widget mandatory.
8. Ignoring cross_channel
Merge tickets, one coherent response.
9. Peak without widget banner
resp_expectation_miss spike BFCM.
10. Bot handoff without ETA
Customer waits indefinitely. RESP-HAND-01 with queue position if possible.
How does Qstomy reduce ticket response times?
Qstomy on Shopify: 24/7 tier 0 bot, agent handoff ETA, auto-ACK chat, RESP-COMM corpus, priority VIP/chargeback routing.
Qstomy resp_wait capabilities
resp_bot_tier0: FRT < 30s WISMO, return, pre-purchase
resp_handoff_eta: grounded queue RESP-HAND message
resp_off_hours: RESP-OFF template + active bot
resp_ticket_status_link: customer self-check without follow-up
resp_vip_route: priority queue Shopify tag
Complement #101 and future #402
SLA #101 = internal ops. Qstomy compresses tier 0 FRT. Future scheduled bot #402 automates RESP-OFF. #401 = resp_wait agent macros.
Quantified DTC scenario
Fashion brand, 420 tickets/month, resp_wait 12% inbound.
After RESP-COMM + Qstomy: resp_wait_ticket_rate 4.2%, resp_wait_fcr 86%, auto_reply_coverage 99%, median email FRT 2.1h, resp_wait_csat 4.3/5.
Explore customer support and request a demo.
What is the checklist for deploying RESP-COMM?
RESP-COMM Checklist (12 steps)
Audit internal SLA #101 vs current public promises
Draft RESP-COMM 8-rule policy
Document 12 typologies resp_wait_* section 3
Create 10 Gorgias RESP-* macros
Configure RESP-ACK-01 auto-reply for 100% of emails
Calibrate chat widget FRT grounded median 30 days
Publish /contact page channel response times table
Train agents on RESP-FLOW RW-1 to RW-8 (30 min)
Activate RESP-UPDATE proactive investigation > 72 h
Peak playbook RESP-PEAK + banner
Weekly resp_wait KPI dashboard
Align future business hours bot #402 roadmap
At a glance
#401 = customer response time communication, not ops SLA (#101)
RESP-FLOW: verify SLA → handle issue thoroughly → explain delay
FRT / resolution distinction: two macro promises
Touchpoints: widget, auto-reply, offline, peak banner
resp_wait_fcr KPI: target 80-88%
FAQ
Difference with #101?
#101 defines internal FRT SLA by category. #401 manages "why no response" customer tickets and public promises.
What to promise on the chat widget?
P80 median pickup + margin. 24/7 bot separate from human. Never "instant" if queue > 2 min is frequent.
Refund delay relationship?
#401 = support response time. Bank delay = RESP-RES-01 or #370 refund status.
Relationship with #402 business hours bot?
#402 automates offline/holidays. #401 = policy and agent resp_wait macros.
Customer follows up 3 times?
RW-5 handle issues thoroughly, RW-7 escalate to supervisor, RESP-MISS if sla_miss confirmed.
Go further
This week: compare widget promises and contact page to Gorgias 30-day median FRT. Gap > 20%: recalibrate RESP-COMM rule 1 before the next volume peak.
Share this #401 guide with support and marketing: a response time promise kept is better than a quick response promised and missed.
Enzo
July 1, 2026
