E-commerce
June 30, 2026
9:27 AM, Tuesday, June 3, 2026: Shopify checkout, admin, and POS go down. Your customers see "This store does not exist" instead of an outage message. Your support team no longer has access to Gorgias. Instagram DMs are piling up: "Scam?", "Has my card been charged?"
PYMNTS reports an outage of about two hours affecting storefronts, payments, and access to merchant support (PYMNTS, Shopify outage June 2026). Digital Applied points out that a status page kept up to date during the incident can reduce support contacts by 60 to 80% (Digital Applied, outage playbook 2026).
This guide #278 covers customer communication during a technical incident with checkout or payment: messages, channels, macros, bot, and recovery. No neighboring content covered this specific moment. Distinct from payment declined (#payment) (individual card decline): here, it is a system outage affecting all customers.
Summary
Why does incident communication matter as much as resolution?
During an e-commerce checkout outage, support becomes the channel of truth when the store can no longer speak for itself. The customer does not distinguish between Shopify, Stripe, and your brand: they see a brand that "doesn't work."
Three risks if you remain silent
Support load ×10: same question "is the site down?" without a macro
Definitive abandonment: customer leaves for a competitor during the outage
Chargebacks: pre-authorized debit perceived as fraud
What transparency brings
SmartSMS Solutions illustrates a 23-minute checkout outage on Cyber Monday: "investigating issues" generated 347 calls and 892 emails. A precise message ("checkout unavailable, cart saved, back in 30 mins") would have prevented 90% of these contacts (SmartSMS, status page). AWS Well-Architected recommends friendly error pages, status banners, and push notifications on surfaces you control (AWS, outage communication plan).
DTC fashion example
Brand with €180k monthly turnover, PSP outage of 47 minutes on a promo Thursday. Without a runbook: 214 tickets, 31 negative reviews. With a status page + INC-CHECKOUT macro + Instagram post within 8 minutes: 41 tickets, 0 chargebacks, 62% of customers return within 24 hours via the recovery email link.
How does it differ from declined payments and neighboring ops guides?
Six neighboring contents, six situations.
Payment declined (#payment)
Payment declined: individual card failure, 3DS, limit. #278: checkout unavailable for all, not a banking diagnostic.
BFCM Plan (#251)
BFCM Staffing (#251): peak headcount. #278: crisis communication when the peak becomes an outage.
Pricing errors (#247)
Pricing errors (#247): price display bug. #278: technical unavailability, not a price dispute.
Bot triage (#236)
Triage (#236): routing intent. #278 adds intent platform_outage priority P0.
Commercial gestures (#238)
Gestures (#238): post-incident recovery with defined caps.
Proactive messages (#proactive)
Proactive messages: promo widget. #278: incident banner and degraded bot mode. Technical fallback API detail: degraded bot mode (#279).
Promise #278
SEV grid, war room, 4-phase templates, INC-* macros, bot, blocked carts, customer post-mortems, pre-staging playbooks.
How do you classify the severity of a checkout incident?
The after-sales service incident severity grid sets communication deadlines and channels before the engineer confirms the cause.
SEV1: totally down checkout or payment
Symptoms: 0 confirmed orders, 100% checkout error, storefront down
First message: within 5 min on owned channels
Update frequency: every 15-20 min
Channels: status page + Instagram/Stories + website banner if possible
SEV2: partial loss
Shop Pay OK, CC KO. Apple Pay down, rest up. PayPal only. Update within 15 min, every 30 min. Status page + social if > 45 min.
SEV3: performance degradation
Slow checkout, sporadic timeouts. Update within 30 min. Status page only unless escalated to SEV2.
Quick decision matrix
Checkout monitoring (Better Stack, Pingdom body assertion) + Slack alert #incident. If 3 consecutive test checkout failures from 2 countries → SEV1 by default. AlertSleep: post "Investigating" even without an identified cause (AlertSleep, outage comms 2026).
Who does what during the first two hours?
The incident support war room separates technical resolution and customer voice right from T+0.
Minimal RACI for DTC SMBs
Incident commander (founder or ops): SEV decision, Shopify/PSP liaison
Customer comms owner: status page, social, macros (1 dedicated person)
Support lead: ticket queue, agents, incident-mode bot
Tech: diagnosis, pause Meta/Google ads if checkout is down
Timeline T+0 to T+120 min
T+0-5: Slack #incident ack, SEV assigned, comms owner named
T+5: "Investigating" status post + banner if CDN is accessible
T+10: Gorgias INC-* macro activated, outage-mode bot
T+15: pause checkout acquisition campaigns (manual or rule)
T+20 to resolution: status update every 15-20 min for SEV1
T+ resolution +15: "Resolved" post + email active carts if applicable
Digital Applied Rule June 2026
On a hosted platform, you do not always control the Shopify error page. Therefore, pre-stage email, social, backup domain, and status page off-platform (Digital Applied, owned surfaces).
What messages should be published at each phase of the incident?
Four incident communication templates cover the complete cycle. Adapt [SERVICE], [TIME], [TZ].
Phase 1: Investigating (T+5 min)
"We are experiencing difficulties with payment / checkout. Our team is investigating. You can browse the site and fill your cart. We will publish an update before [time + 20 min]. Status: [URL status]." Specify what is working vs what is down.
Phase 2: Identified (cause known)
"The cause has been identified ([payment provider / platform]). Fix in progress. Checkout expected to return around [time]. If you saw an error in the last 15 minutes, your cart has been saved, no need to re-enter everything."
Phase 3: Monitoring (fix deployed)
"Checkout has been restored. We are monitoring stability. If a problem persists, please contact us with a screenshot. Thank you for your patience."
Phase 4: Resolved (closure)
"Incident resolved at [time]. Duration: [X min]. Impact: payment temporarily unavailable. No banking data compromised. Orders placed during the window: see blocked carts section. Sorry for the inconvenience." AlertSleep recommends a public post-mortem if > 30 min (AlertSleep, post-mortem).
Writing Prohibitions
"Issue with our hosting provider" without useful info. "Come back later" without a time. Technical jargon "Error 502" on its own. Promising automatic refund not validated by finance.
Which support macros should be activated immediately?
Six customer service technical incident macros standardize responses while the comms owner updates the status page.
INC-SITE-DOWN
"Hello, we are experiencing a technical outage affecting [checkout / the site]. This is not an issue with your account. Follow updates: [status URL]. Latest info: [copy status sentence]. I remain available for your current order #[number] if applicable."
INC-CHECKOUT-FAIL
"Payment is currently failing on our side due to an ongoing incident. No final charge is processed until you receive the order confirmation. Your cart is saved. Please try again after [estimated time] or set up an alert on [status URL]."
INC-CHARGED-UNSURE
"I understand your concern. Let's check: did you receive a \"Order confirmed\" email with number #[format]? If not, this is often a temporary pre-authorization released within 3-7 business days. I will check our system once service is restored: [customer email]."
INC-ORDER-LIMBO
"Your attempt during the incident has been recorded. We reconcile orders within 24 hours. If paid and confirmed: normal shipping. If paid without confirmation: we will contact you with a refund or validation. Reference: INC-[date]-[ticket]."
INC-VIP-PRIORITY
Same content as INC-SITE-DOWN + "I am handling your case as a priority and will write to you within 2 hours after restoration." Align with VIP policy (#207).
INC-SOCIAL-PUBLIC
Short DM/comment reply: "Technical incident ongoing, not linked to your account. Updates: [link]. DM open if urgent order." Never debate in a public thread.
How do I configure the bot during an outage?
The bot checkout incident mode replaces product intents with status responses and rapid handoff.
Activation
Toggle the "incident_mode" in Notion or global Gorgias tag incident_active. Bot reads flag at the start of the session. If true: skip product recommendations, skip promos, intent checkout_error → macro INC-CHECKOUT-FAIL.
High-priority P0 intents
site_down,checkout_error,payment_failed_masscharged_no_confirmationwhen_back_online
Standard bot response
"Technical incident in progress with the payment system. This is not your card. Live status: [link]. Cart saved. Update scheduled at [time]. An agent can take over if the order is urgent (> €200 or event date)." Handoff if there is a 2nd message on the same topic or angry sentiment.
Guardrails
Bot does not promise a fixed timeframe not validated by the comms owner. Bot does not confirm order without lookup Shopify OK. See bot governance (#142). P0 triage #236.
Widget banner
Replace promo message with: "Checkout temporarily unavailable. [Status link]." Proactive messages in alert mode.
How to handle blocked carts and suspicious direct debits?
The abandoned cart incident protocol prevents duplicate orders and post-resolution chargebacks.
During the incident
Do not ask the customer to "try again 10 times"
Collect email + cart SKU via backup Typeform form if checkout is down
Tag ticket as
incident_stranded_cart
After recovery (within 24 hours)
Export Shopify orders created during the incident window
Cross-reference PSP logs: captured vs authorized only
List B: paid without Shopify order → contact customer for refund choice or manual order push
List C: high-value abandoned carts → recovery email with cart link + code INC-RETRY5 (-5% max, aligned with gestures #238)
script charged_no_order
"Our system confirms a bank authorization without a finalized order on [date] at [time]. We will issue a refund within 48 hours or manually validate your order according to your preference. PSP Reference: [id]." Document in the decisions registry.
BNPL and wallets
If Shop Pay / Klarna / Alma: same logic, check the financing provider's dashboard post-incident. See split payment (#194) for refund synchronization.
What communication pitfalls should be avoided during an outage?
Seven incident communication anti-patterns amplify the crisis.
Common mistakes
Silence 30+ min: customer assumes scam or bankruptcy
Contradictory agents: one says "it's fixed", the other "we don't know"
Blaming Shopify in public: you remain the visible brand
Promising -20% to everyone: token budget exploded, future expectations set
Continuing checkout ads: CPA burned during outage
Ignoring social media: 80% of public feedback occurs during SEV1
Closing tickets in bulk without checking limbo carts
Standard response for negative tweet, June 2026
"We experienced the same outage as thousands of shops today. Checkout restored at [time]. If you have questions about your order: [support email]. Transparency: [status/post-mortem link]."
Single source of truth
Comms owner alone edits the canonical paragraph copied by agents, bot, and social. Slack #incident pinned with the latest wording.
Which KPIs should be monitored during and after the incident?
The support incident measurement proves communication ROI and feeds internal post-mortems.
KPIs during (live)
Time to first public update: target < 5 min SEV1
Tickets / 15 min vs baseline for the same time slot
First response time incident-tagged
Negative social mentions volume
KPIs post (D+1 to D+7)
Stranded carts recovered %
Chargebacks incident window
CSAT tickets tag incident_*
Repeat purchase 7 days contacted customers INC-*
Ticket reduction vs incident without comms (internal benchmark)
48-hour internal post-mortem
Timeline, root cause, what worked in comms, preventive actions. Share a lighter customer version on the blog or status page if SEV1 > 30 min.
How does Qstomy handle checkout incidents on the support side?
Qstomy switches to incident mode: prioritized checkout intents, status link injected, enriched handoff for limbo carts.
Capabilities
Toggle incident_mode: 1 click, widget sync + responses
Dynamic status URL in every bot response
Intent checkout_error P0: bypass promo flows
Cart email collection if checkout is inaccessible
Export incident_* tickets for D+1 reconciliation
Encrypted DTC Scenario
Cosmetics brand, 38-minute PSP outage, active ads traffic. Before runbook: 127 tickets, FRT 18 min, 4 chargebacks. After Qstomy incident_mode + 6 INC macros + status page: 29 qualified tickets, FRT 4 min, 0 chargebacks, D+1 email cart recovery 34%, post-incident CSAT 3.8/5.
Explore AI customer support, Shopify, request a demo.
Which playbooks should you prepare before the next outage?
Playbook 1: status page (2 h)
Create status page on owned domain (Better Stack, Instatus). Embed footer link + Instagram bio. Test manual post.
Playbook 2: INC-* macros (1 h)
Import 6 templates from section 6 into Gorgias. Auto-tag incident_active on keyword rule "site down", "checkout", "payment impossible".
Playbook 3: war room doc (1 h)
Notion 1 page: RACI section 4, links Shopify status, PSP, templates section 5, contact Meta ads pause.
Playbook 4: quarterly drill (45 min)
Tabletop simulation: "checkout down 10:00". Clock first update. Fix gaps.
Playbook 5: incident_mode bot (2 h)
Configure section 7. Test pack of 10 messages. Link triage (#236).
Playbook 6: reconciliation template
Sheet columns section 8 ready. Owner finance + support. Mesh: payment declined, BFCM plan (#251), escalation (#193).
The June 2026 outage recalled a simple rule: you do not always control the error page, but you always control what your support team replies.
Enzo
June 30, 2026
