Support is not an email address. It is the routing system after an order.
This lesson turns pre-purchase questions, shipping delays, refunds/returns, damage/wrong item, chargeback risk, reviews, and repeat purchase into one support SLA and post-purchase routing table. Without timing, evidence, person handling it, and review boundary, support is not a system.
The previous lesson leaves a launch regression evidence board: a named buyer path, evidence location, Go / Soft launch / Hold / No-go decision, pause action, retest action, and the first support-facing gap.
It tells you where a test path is blocked, butit does not prove that a real customer contacted support, an SLA ran, a refund or reship occurred, or that carrier performance, duties, payment settlement, or launch outcome is real. Now turn that gap into a next step a buyer can receive instead of treating a QA card as ready support.
This lesson leaves a support SLA and post-purchase routing table: first-response and next-update timing, first evidence, escalation trigger, write-back location, and automation state;a selected route or copied note is still not actual support performance, customer satisfaction, or launch approval.
One email address is not a support system
Improvised replies can survive a few orders. As volume grows, shipping delays, refunds, damage, disputes, low reviews, and retention touches collide in one inbox. Support is not only for calming customers; it is an input layer for product, shipping, page, and policy problems.
First response
Tell the customer someone has picked it up and give the next timing expectation.
Auto reply, first human response time, support entry, and working hours.
The selected SLAis a timing promise to meet, not proof that it has run. Record the first reply and next-update time in the order or ticket, then decide whether a real exception needs escalation.
Define support timing, order proof, and product identity first
Post-purchase work is not only the chat window. Beginners first need to know what timely response means, where order proof lives, and which product identity traces wrong-item or damage cases. Feed, SKU, and GTIN appear here only to show where the issue writes back, not to turn this lesson into a feed operations lesson.
SLA
Meaning
SLA means service-level timing. In this lesson, it is not a legal contract; it is the internal promise for first response, progress update, escalation, and refund review timing.
Where it appears
You see it in support auto replies, ticket notes, refund policies, shipping-exception snippets, and weekly review sheets.
Who reads it
Customers read it to know when someone will act; support and operations read it to know when a case must escalate.
What breaks
Without an SLA, support often says "we will handle it soon" without a next timing, and delay or refund cases can become disputes or low reviews.
Ecommerce example
For example, if tracking has not moved for five days, the SLA should say the carrier is checked within 24 hours and missed promise windows move into reship, compensation, or refund review.
Feed
Meaning
A feed is the product-data stream that sends title, image, price, inventory, SKU, GTIN, and related product facts to Merchant Center, ad platforms, or store systems.
Where it appears
You see it in Merchant Center, product-sync tools, ad product groups, onsite search, and product-data sheets.
Who reads it
Ad platforms, search systems, onsite recommendations, support, and warehouse teams indirectly read product facts from the feed.
What breaks
When feed inventory, color, or images are wrong, support receives cases like "I ordered black and got white" or "the page says in stock but it cannot ship."
Ecommerce example
If a black 20oz tumbler variant is out of stock while the feed still says available, support should write the issue back to inventory sync and the product page.
Merchant Center
Meaning
Merchant Center is the Google surface for product data, product review, and Shopping or Performance Max eligibility. It is not a support tool, but it affects whether Google can read product facts correctly.
Where it appears
You see it in product diagnostics, item status, feed sync, price and inventory review, and ad product eligibility.
Who reads it
Google reads product facts from Merchant Center; ads, search, support, and operations are affected by whether those facts are accurate.
What breaks
When Merchant Center price, inventory, image, or status differs from Shopify, support can receive complaints such as "the ad says in stock but the store does not" or "the price is different."
Ecommerce example
If a black 20oz tumbler still appears in ads while Shopify is sold out, support should write the complaint back to Merchant Center diagnostics and sync rules.
SKU
Meaning
SKU is the store-owned identifier for a product or variant. It separates color, size, bundle, warehouse picking, and support records.
Where it appears
You see it in Shopify product admin, orders, pick lists, feeds, support tickets, and refund/reship records.
Who reads it
Warehouse teams use SKU for picking; support uses SKU to diagnose wrong items, damage, batch clues, and repeated issues.
What breaks
When SKU naming is messy, support cannot tell whether the buyer received a wrong item, the page image misled them, or inventory sync failed.
Ecommerce example
If TUMBLER-20-BLK and TUMBLER-20-WHT are mismatched between warehouse and page, support should write back to SKU naming and QA sampling.
GTIN
Meaning
GTIN is a global trade item number, often represented as a UPC or EAN barcode. It helps Google, marketplaces, and some inventory systems identify the exact product.
Where it appears
You see it on product barcodes, Shopify product fields, Merchant Center diagnostics, feed files, and marketplace product data.
Who reads it
Google, marketplaces, inventory systems, and comparison surfaces read GTIN to match product identity.
What breaks
When GTIN is missing or wrong, the product can fail review, match the wrong item, and make wrong-item or batch support cases harder to trace.
Ecommerce example
If a tumbler has separate 20oz and 30oz barcodes and the feed swaps their GTINs, ads and support records can mix the variants together.
Every issue needs frontline action, evidence, SLA, and escalation trigger
Answer size, material, use case, shipping region, and limitations.
Customer question, product link, matching FAQ or product-page gap.
First response within 24 business hours.
Repeated question escalates into product-page or FAQ update.
This route shows the first action, evidence, and escalation condition;it does not mean the buyer has already been handled.Log the first evidence and next-update time from the result before deciding whether to escalate.
Keep tone, facts, tags, language, and human review in one case record
The routing matrix above tells you which line a case should take. This workspace adds what a template can hide: acknowledge buyer experience before reading back real facts; use tags to find repetition without treating a tag as the outcome; limit automation to acknowledgment and reminders; keep refund, reship, dispute, product safety, and unclear meaning with real evidence and human review. Everything stays in a current-browser classroom record.
0/7 classroom gates considered; completing gates only makes the record more complete, not a support, payment, product-safety, or release conclusion.
Shipping or promise mismatch
The buyer reports stalled tracking, a missed promise window, or an update that conflicts with the page promise.
Acknowledge the wait and uncertainty; do not make the buyer do the tracking work for you.
Read back the order, item, representative address, promise window, latest carrier scan, next-update time, and known exception.
Suggested classroom tag: support:shipping-delay
Write a real, reviewable next-update time instead of only saying "please wait."
Automated status messages can state a known scan; they cannot decide compensation, reship, refund, or a new delivery date.
Move to human review when the promise window is missed, address or market scope differs, delays repeat, or buyer concern escalates.
After the first interaction, does the buyer truly need no next step, or did they only receive an initial reply?
Evidence: Record issue tag, first reply, fact readback, outcome, reopen state, and buyer confirmation.
Do not count an automated acknowledgment or closed ticket as FCR; it is a review signal, not a staff score or satisfaction conclusion.
Once the case is actually complete with no unresolved refund or safety issue, how does the buyer rate the support experience?
Evidence: Record invitation condition, language used, send time, open-ticket state, and feedback wording or summary.
Do not send CSAT to unresolved, high-friction, or escalating cases, and do not treat a small response set as an overall satisfaction conclusion.
Within the same week, market, or SKU, which tags keep generating contacts and does the page or fulfillment promise need correction?
Evidence: Keep the same denominator, time window, market or SKU, tag count, and write-back action.
Contact rate is a diagnostic entry point, not a reason to reduce replies, delete tags, or make it harder for buyers to ask for help.
A buyer asks for a refund and reports discomfort after using a product. You have not confirmed the order, language, market, photos, or policy version. What should happen next?
Enter only non-sensitive classroom practice content. Save, restore, download, and clear happen only in this browser; they do not create Shopify tickets, customer tags, refunds, reships, marketing touches, or product-safety conclusions.
Check live availability and automatic-first-reply settings; use them for expectation setting, not as a case outcome.
Check the live paths for conversation assignment, common questions, and help content; this classroom record does not replace real messages or team access.
Check live availability of conversations, buyer details, and topic labels; do not treat a practice tag as a real customer or risk conclusion.
Check the live workflow, trigger, and other-app effects on tags; automated tagging still needs human review and testing.
A first reply is not a template. It tells the buyer what happens next
The first reply has four jobs: understand the buyer concern, explain why the case has risk, give the next timing, and log evidence in the ticket. Then refund, reship, escalation, and page updates have a basis.
"I ordered 10 days ago and tracking has not moved. Did you even ship it?"
This is not only a shipping question. The buyer is starting to doubt whether the store is reliable.
If the reply only says "please wait", the buyer gets no timing and no escalation rule. The next step can become a dispute or public low review.
- 1Acknowledge the issue: we can see tracking is stuck at a scan and we will check it.
- 2Give facts: order number, ship date, last tracking scan, and whether the promised window is still open or already missed.
- 3Give the next timing: for example, contact the carrier within 24 hours and reply with the next step by a clear date.
- 4Give the escalation line: if the promised window is missed with no update, move into reship, compensation, or refund review.
- Order number and email
- Screenshot of the last tracking scan
- Promised window from the Shipping Policy
- Next reply time and person handling it
Route the real support message before deciding refund, reship, or escalation
Many support problems do not fail because tone is bad. They fail because the first route is wrong. Stalled tracking, damage, wrong item, and chargeback threat all feel urgent, but they need different proof, handling paths, review timing, and page write-back.
"Tracking has not moved for five days. Did you actually ship it?"
Only paste the tracking link or ask the buyer to keep waiting.
Route to shipping exception: check last scan, promise window, carrier state, and next update time.
Acknowledge the stalled scan, say you will check with the carrier, and promise the next step within 24 hours.
Order number, last tracking scan, Shipping Policy promise window, and carrier check record.
If the promise window is missed with no update, escalate to reship, compensation, or refund review.
Write back to Shipping Policy, shipping notification, and delay-case snippet.
When the first order goes wrong, route delay, refund, and low-review cases separately
A first-order incident is easy to dismiss as a one-off. It often exposes three system issues: whether the shipping promise is real, whether the refund boundary is clear, and whether review or repeat-purchase automation will keep hurting the buyer. Choose the closest incident to see the first reply, evidence, resolution path, and write-back location.
Click the real first-order incident. Do not start with whether to pay. First decide whether it is a shipping promise, refund boundary, or review-risk issue; this choice is written into the final copyable notes.
The first real buyer says tracking has not moved for four or five days and starts doubting whether you shipped.
Only send the tracking link or say please wait, without a next update time or escalation trigger.
Acknowledge the stalled scan, state the last scan and promised window, say you will check the carrier within 24 hours, and explain the compensation, reship, or refund review after the promise window is missed.
Order number, last tracking scan, Shipping Policy promise window, carrier check record, and next reply time.
Inside promise window: give update timing. Past window: compensate or reship. Carrier confirms loss: move into refund/reship review.
Write back to Shipping Policy, shipping email, order-status copy, and delay first-reply snippet.
Before carrier check and next update time exist, do not keep sending a wait-only template.
The selected incident is a diagnosis, not a resolution. Lock the first evidence and next-update timebefore choosing a refund, reship, or page repair; it does not prove a refund, carrier performance, or buyer outcome.
After routing the case, write a reply the team can execute
A service script is not copy-paste support. It locks the opening line, evidence request, next timing, what not to say, and write-back location. Click the scenario closest to the current order; the panel turns it into a reply structure you can adapt, then write the conclusion into the copyable notes.
Shipping delay script
Acknowledge the delay and anxiety instead of making the buyer read tracking: I can see your parcel has not updated since {last_scan}; I will check the carrier and promised window first.
Order number, last tracking scan, promised delivery window, carrier check record, and next update time.
Give the next update within 24 hours; after the promise window is missed, review compensation, reship, or refund.
Write back to Shipping Policy, order-status page, shipping email, and delay first-reply snippet.
Do not only say "please wait," and do not promise a new delivery date without evidence.
Shipping delay short email
Subject: Update on your order delivery
Hi, we can see your parcel has not updated since {last_scan}. We will check with the carrier and update you before {next_update_time}. If the promised delivery window is missed and tracking still does not recover, we will review compensation, reship, or refund options.
Damage reship short email
Subject: About the damaged item you received
Hi, we are sorry the item arrived with an issue. Please reply once with your order number, outer-box photo, damaged-item photo, and SKU or package label. We will confirm before {review_time} whether this should be a reship, partial refund, return/refund, or supply-chain review.
Connect support, refunds, reviews, and repeat purchase into one post-order flow
Post-purchase work is not one template. A real order moves through confirmation, tracking, support case, refund or reship, review request, and repeat-purchase touch. Click the weakest step in your current flow; the panel shows what the buyer is asking, what support should do, what the system must record, when to pause, and where the issue writes back.
Order confirmation
Did my order go through? What are the address, amount, items, and next step?
Confirm order number, product/variant, shipping address, payment status, and expected dispatch window; do not make the buyer infer it from scattered emails.
Shopify order Timeline, order confirmation email version, Customer events purchase event, and support entry.
If address, payment capture, stock, or high-risk order status is unresolved, do not ship or continue automation.
Write back to order email, FAQ, address-change language, and launch QA test-order record.
This step only identifies the weakest part of the current flow.While support is unresolved, review, UGC, discount, and upsell touches must remain paused.Keep human follow-up and write-back first, then resume automation.
Use buyer questions to connect email, shipping, refunds, and reviews
A post-order flow is not just a backend diagram. It is a sequence of buyer questions that appear on different days. Click one time point to see the real question, weak reply, support move, evidence, system touch, write-back location, and what to pause before alignment.
Day 0: 10 minutes after order
The order confirmation email should show order number, product/variant, address, payment status, expected handling time, and support entry.
Shopify order Timeline, order confirmation email version, payment capture state, address completeness, and inventory state.
Order confirmation email, order status page, support entry, and address-change language.
If buyers repeat the same question, write it back to FAQ, first screen of order email, and post-checkout message.
Selecting a time point does not mean a notification was sent or the case was resolved;it only makes the current buyer question, evidence, and next step explicit.Keep unresolved support in human handling.
Do not treat every refund request the same way
The point of refund segmentation is not under-refunding. It prevents each support person from making cost decisions emotionally. Pre-shipment cancel, delay, lost parcel, damage, preference return, and duty refusal need different boundaries.
Pre-shipment cancel
Cancel and refund quickly to reduce friction and support load.
Support issues should flow back to pages, FAQ, and policies weekly
Repeated size, material, shipping, duties, and return questions.
Add to FAQ, product page, policy page, and order emails.
Customers do not understand use case, specs, limitations, or actual result.
Update product copy, visuals, comparison table, and trust assets.
Delays, duties, tracking, or remote regions create repeated inquiries.
Update Shipping Policy, product-page promise, and support snippet.
Real praise, low reviews, usage feedback, and common objections.
Praise becomes trust asset; low reviews become page and support playbook fixes.
Support state should control the next touch
Good reviews become trust assets, and low reviews become operating diagnosis. Review and repeat-purchase messages should not fire only by a fixed email delay. Satisfied, recovered, and high-friction customers need different paths.
Satisfied customer
Route into review request, UGC collection, replenishment, or bundle offer.
Asking too early reduces review quality.
A reply without next timing is not an SLA
A parcel is delayed and support wants to reply "please wait." There is no next update time, compensation boundary, or escalation rule. What should happen?
Support routing tells you what to fix next
The selected route carries only a named support record into System Integration: support entry, first-response and next-update timing, route, evidence location, escalation condition, automation state, and page or system write-back. It cannot replace an actual notification, case resolution, refund settlement, carrier performance, customer satisfaction, or launch approval.
Support routing is executable
Move into system integration and connect orders, notifications, support logs, automation, and weekly review.
Start system integrationTurn this lesson into support and post-purchase copyable notes
Support and post-purchase copyable lesson notes Current pressure: "Tracking has not moved for five days. Did you actually ship it?" First evidence: Order number, last tracking scan, Shipping Policy promise window, and carrier check record. First-order incident: First-order shipping delay - Inside promise window: give update timing. Past window: compensate or reship. Carrier confirms loss: move into refund/reship review. Current service script: Shipping delay script - A delay reply must state the last scan, next update time, and the boundary after the promise window is missed. Post-purchase flow step: Order confirmation - The order confirmation step should leave order number, payment, address, dispatch window, and support entry. Automation status: unresolved support state pauses review, UGC, discount, and upsell touches; keep human follow-up only. Empathy-and-fact record: Shipping or promise mismatch Classroom gates: 0/7 Decision feedback: Not selected yet Post-order 7-day question step: Day 0: 10 minutes after order - Day 0 should confirm order success, information accuracy, and when the next step happens. This-week action: Acknowledge the stalled scan, say you will check with the carrier, and promise the next step within 24 hours. Action to pause: do not only paste the tracking link or ask the buyer to keep waiting. Review window: review by the First response SLA, and escalate when if the promise window is missed with no update, escalate to reship, compensation, or refund review. Next route: Move into system integration and connect orders, notifications, support logs, automation, and weekly review. Classroom case and buyer concern: ___ Language and market readback: ___ Tag and first route: ___ Empathy line plus next step: ___ Fact readback and evidence: ___ Automation boundary: ___ Human-review condition: ___ Metric and write-back action: ___ Support entry: ___ SLA table: ___ Support routing table: ___ Service reply script: ___ Post-purchase flow board: ___ Post-order 7-day question map: ___ Refund/reship rules: ___ FAQ update table: ___ Review and repeat-purchase boundary: ___ Automation status: ___