Text version of this lessonExpand
Shipping setup is not just filling a rate table. First decide which markets you promise to serve, when you ship, when delivery happens, who handles duties, and who is responsible for exceptions.
The previous lesson leaves a policy promise consistency map: one delivery or duties promise, the relevant page and record, its first mismatch, a pause action, and a conditional next route. It makes it possible to review whether product-page, policy, email, and support wording contradict each other.
That map proves the wording deserves another check, but it does not prove that a market has the listed rate, a warehouse or supplier can meet the timing, a carrier will produce a first scan, duties were collected correctly, or support can execute the exception rule. A 20oz tumbler page that says “7-12 business days” still needs its market, SKU, checkout, fulfillment, and tracking record.
Enter this lesson when that public promise is named and the earliest blocker becomes whether it can actually be kept. The output is a shipping promise and exception matrix: market, rate, handling/transit window, duties, tracking, exception evidence, and pause action in one place; it is not proof of carrier performance, a duties outcome, payment settlement, or launch release.
Separate shipping promise into price, timing, and exception responsibility
Beginners often publish one vague delivery range. When delay, duty disputes, or lost parcels happen, support and policies have no usable rule.
This lesson separates fulfillment into primary markets, rate model, handling time, transit time, duty responsibility, tracking notices, and exception playbook.
- Step 1: start with the exact promise from the previous lesson. For example, “US delivery in 7-12 business days” or “who pays duties”; do not begin by writing one global line for every country.
- Step 2: split it back into real conditions: SKU, market, rate, clock start, first scan, and the person who checks the exception.
- Pass condition: keep the pause action until the evidence works. This lesson teaches how to collect proof and narrow the promise; it does not turn a policy sentence into a fulfillment result.
Decision lens for this lesson
- Fulfillment promise: The stated rule for shipping, delivery, tracking, duties, and exception handling.
- Handling time: The time needed after payment before the parcel is shipped.
- Exception playbook: Rules for delay, lost parcel, damage, address error, and refusal.
Lesson output: shipping promise and exception matrix. Use this output to decide whether the lesson is truly complete.
How this connects: fulfillment promise must sync with policies and support
Fulfillment setup is not only shipping rates. Handling time, transit time, duty logic, exceptions, and tracking milestones become policy copy and support scripts.
- Policy route: policies and compliance pages to put real delivery promises into refund, shipping, and tax language.
- Support route: customer service and post-purchase to turn exceptions, replacements, returns, and tracking into a support response path.
This lesson boundary: decide whether the shipping promise can be public
This shipping lesson does not replace the policy, support, or launch QA lessons. It answers one question: can the delivery promise shown to buyers be supported by Shopify settings, warehouse or supplier capability, tracking, duties language, and exception evidence at the same time?
| Question | This lesson owns | Route next |
|---|---|---|
| Can the delivery promise go public? | Primary market, rate, handling time, transit time, tracking, duties, and exception pause line. | This lesson. |
| How should policy pages say it? | Bring the real promise, evidence, and exception conditions. | Policies and compliance pages. |
| How should support reply and escalate? | Bring boundaries for delay, loss, reshipment, refund, and recheck time. | Customer service and post-purchase. |
| How should launch QA verify it? | Bring test-order, shipping-rate, tracking, and notification evidence. | Launch checklist and QA. |
First define what shipping setup actually configures
Shipping setup is not only a rate in Shopify and it is not only an estimated 7-15 day line. It configures a promise chain: what buyers see before checkout, what checkout calculates, how the warehouse or supplier ships, how the carrier updates tracking, and how support handles exceptions.
| Question | What you need to answer | If you do not answer it |
|---|---|---|
| What | Primary markets, rates, handling time, transit time, duties, tracking, exception playbook, and reverse logistics. | Buyers see vague promises and the team has to improvise after purchase. |
| Why | Shipping affects checkout conversion, payment completion, support load, chargebacks, and repeat purchase experience. | Ads may bring traffic, but surprise rates, no tracking, and duty shocks damage order quality. |
| How | Narrow primary markets first, run representative orders to checkout, record rate name, duties signal, estimated timing, and final total, then sync Shipping Policy, FAQ, order email, and support templates. | Storefront, admin, support, and supply chain say different things, and every exception becomes more expensive. |
Shopify admin paths: turn promises into reviewable fields
Do not rely on temporary images or verbal memory for this step. Translate each promise into a Shopify admin path and a field another teammate can review. The path is the operating language: operations knows where to change the rule, support knows where to check the order, the warehouse sees the timeline, and launch QA does not depend on a feeling.
| Promise to verify | Shopify admin path | Fields to record | If it fails, fix this first |
|---|---|---|---|
| Primary market can actually buy and ship | Settings -> Markets, then check target market countries, currency, and availability. |
Market name, country/region list, purchasable status, and test address. | Narrow the primary market before letting every country buy by default. |
| Rate rules support the storefront promise | Settings -> Shipping and delivery -> Shipping profiles. |
Shipping profile, zone, rate name, threshold, weight or price condition. | Fix profile and zone before changing free-shipping copy. |
| Handling time and fulfillment location match | Settings -> Locations and Orders -> target order -> Timeline. |
Fulfillment location, handling duration, order routing, and fulfillment status. | Split SKU promises if mixed warehouses create different timing. |
| Tracking exists after shipment | Orders -> target order -> Fulfillment and the carrier tracking page. |
Tracking number, carrier, first scan time, delivery status, and shipping-email subject. | Do not promise full tracking or fast delivery before first-scan behavior is clear. |
| Returns and exceptions have boundaries | Settings -> Policies, order timeline, and support inbox or ticket. |
Return window, return address, shipping-cost responsibility, resend/refund ID, and support template. | Align policy page and support template before adjusting ad or product-page promises. |
How to accept this table
Each field must be reviewable by a second person: open the same Shopify path, enter the same test address or order number, and find the same rate, location, tracking, timeline, or policy content. If the evidence cannot be reviewed, do not use it to support a public delivery promise.
Run the promise with a 20oz tumbler
Suppose you sell a 20oz tumbler with two first-batch SKUs: standard lid and straw lid. The United States is the primary market, the UK and EU are small tests, and remote regions are blocked for now. You want to promise free shipping over $49, 7-12 business day delivery, and full tracking. Do not write the page copy first. Run the chain.
A stronger fulfillment chain
First-order fulfillment timeline: 3PL, self-fulfillment, and dropshipping
Do not judge fulfillment only by speed or inventory weight. The first order must produce evidence for order intake, fulfillment, dispatch, first scan, delivery, exception handling, and support. After that timeline is visible, you can decide whether the storefront can honestly promise 3-7 days, 7-15 days, or a more conservative 10-20 days.
| Route | Day 0 | Dispatch and first scan | Delivery window | Storefront promise | Evidence to keep |
|---|---|---|---|---|---|
| 3PL / local warehouse | The order enters the 3PL queue; SKU, inventory location, address, and cut-off time are verified. | Day 0-1 pick and pack, then Day 1-2 carrier first scan and tracking email. | Core US regions usually deliver around Day 3-7; remote regions need a separate note. | Hero SKUs usually process within 1 business day; US delivery usually takes 3-7 business days. | Order routing, 3PL intake, pick slip, label, tracking, delivery proof, and exception review. |
| Self-fulfillment | Manually confirm payment, address, SKU, packaging material, and whether shipment should be bundled. | Day 0-2 quality check, weighing, and label printing; Day 2-4 carrier first scan. | Usually Day 7-15, depending on carrier, country, and address quality. | Orders usually process in 1-2 business days and arrive 7-15 business days after shipment. | Address validation, parcel weight, label ID, shipping-email sample, and support messages. |
| Dropshipping | The order syncs to the supplier; SKU, color/spec, stock, and dispatch timing are confirmed. | Day 1-4 supplier dispatch; Day 4-7 first scan or transfer checkpoint. | Usually Day 10-20; if tracking stays blank for 72 hours, trigger supplier inquiry. | Orders usually process in 2-4 business days and may take 10-20 business days to arrive. | Supplier intake, stock confirmation, tracking number, route note, customer feedback, and exception cost. |
The point is not to choose the more advanced-sounding model. The point is to write the promise your current model can keep. 3PL needs stable stock and status sync, self-fulfillment needs reliable manual work, and dropshipping needs supplier evidence plus a more conservative no-scan explanation.
3PL minimum evaluation checklist: do not ask only what it costs
A 3PL does not remove the shipping problem by itself. Rates, cut-off, inventory sync, tracking, DDP/DDU duty language, returns, and reships need one evidence chain. Otherwise faster storefront copy creates more support pressure.
| Check | Why it matters first | Minimum proof |
|---|---|---|
| Zones and costs | A 3PL quote is not one average number. Primary markets, remote zones, heavy parcels, and return fees need to match the Shopify rate setup first. | Rate card, representative checkout screenshots, remote-zone test order, and margin sheet. |
| Cut-off and status sync | If cut-off time, stock deduction, label creation, and Shopify fulfillment sync are unstable, a fast-delivery promise becomes support pressure. | 3PL dashboard, Shopify fulfillment timestamp, label, first-scan time, and exception-alert threshold. |
| Tracking first scan and exception rules | Tracking does not end at sending a number. Buyers and support need parcel status, first-scan timing, no-update threshold, and the next review time. | Shipment notice, tracking page, carrier record, no-first-scan ticket, and first-reply support template. |
| DDP / DDU duty boundary | DDP usually means the seller prepays and owns import duties. DDU or DAP is closer to the buyer paying duties on arrival. The exact rule still depends on carrier, destination market, and checkout setup. | Checkout duty notice, Shipping Policy, support script, label service, and refusal-handling rule. |
| Return and reship route | A 3PL can ship fast without handling exceptions fast. Damage, refusal, address error, return, and reship rules need a responsibility boundary before launch. | Return address, reship authorization, claim evidence, support escalation line, and cost ceiling. |
Acceptance line
Write the 3PL fast-shipping promise into product pages, policies, and ads only after the 3PL quote, Shopify rates, tracking first scan, DDP/DDU duty language, return/reship rule, and support escalation line explain each other.
Run one real SKU and representative address to checkout first. The record is not “we picked free shipping”; it is how the rate name, final total, weight, and margin hold together. One passing address does not make every country, remote region, or heavy order eligible.
Compress repeated wording into one fulfillment promise matrix
Do not write the same decision three times. The fulfillment model answers who ships, from where, and what cost or inventory risk you accept. The delivery promise answers what buyers see, what support can explain, and what policy pages can support. Exception handling answers what to check first, who owns cost, and when to reship or refund.
| Do not repeat | Keep as one field | Acceptance evidence |
|---|---|---|
| Repeating "we use dropshipping/warehouse, so delivery is about X days" in several places. | Fulfillment model: dropshipping, domestic stock, overseas warehouse, or hybrid; record SKU fit, location, cash pressure, and upgrade trigger. | Inventory location, supplier or warehouse handling time, and representative checkout rate name and final total. |
| Writing "7-15 days," "free shipping," and "tracked delivery" as separate versions on product page, policy page, and support script. | Delivery promise: handling time, transit time, rate rule, tracking update timing, and DDP/DDU or unpaid-duty language. | Shipping Policy, FAQ, product-page shipping block, order email, and support template version. |
| Re-explaining delay, lost parcel, refusal, and return rules in every module. | Exception handling: first evidence, responsibility, first-response time, and reship/refund/partial-compensation boundary. | Tracking, label, carrier record, support ticket, and review window. |
Completion standard
Keep one shipping promise and exception matrix. Storefront copy, Shopify rates, support replies, and supplier or warehouse timing should match. If one layer conflicts, do not scale traffic yet.
Why Shipping Setup Affects Conversion
Before paying, customers often care about three things beyond the product: how much shipping costs, how long it takes, and whether they can track it. If that answer is unclear, many of them leave before checkout.
Shipping Impacts 4 Outcomes
- Checkout conversion
- Payment completion
- Support load
- Refund and dispute loss
Choose the Fulfillment Model First
Shipping rates are the result of your fulfillment model, not the starting point. Decide whether you are dropshipping, shipping from domestic stock, using overseas warehouses, or combining models.
Choose from the way you can really ship today. If the standard-lid and straw-lid tumbler do not share location and handling evidence, assess them separately; do not write today’s SKU promise from a future warehouse-scaling ideal.
What Must Be Defined Before Launch
Core Fulfillment Checklist
- Handling time
- Main shipping countries
- Shipping rate model
- Tracking availability
- Exception-handling rule
Do Not Promise a Timeline You Cannot Control
- Conservative and reliable beats fast and unrealistic.
- Your website, confirmation email, and support responses should all match.
- Delayed expectations hurt less than broken expectations.
How to Design Shipping Rates
New stores rarely need highly complex shipping matrices. The rule should be simple enough for customers to understand and accurate enough for your margin model.
Three Common Models
Beginner Recommendation
- Start with the simplest rule customers can understand.
- If country economics vary a lot, limit launch markets first.
- Never set shipping rates without checking margin impact.
Tracking and Shipping Notifications Should Be Automated
If you plan to manually explain package status order by order, support load will rise immediately.
Minimum Notification Flow
- Order confirmation
- Shipment confirmation with tracking
- Internal exception alerts
- Clear support contact path
Tracking is a reviewable process, not a number that merely looks shipped. Confirm when order confirmation, shipment notice, first scan, and exception alert each occur; do not write an untested node as a stable buyer experience.
Exception Handling Determines Whether You Lose More Money
Problems will happen. The real question is whether you have a consistent response process.
Slow Response Often Costs More Than the Shipping Issue Itself
- Customers tolerate issues better than silence.
- Once a problem becomes a chargeback, your cost rises sharply.
- Support scripts, policy pages, and internal playbooks should align.
Give each exception one first piece of evidence and one next-reply time. That lets support, operations, and the policy page know what must stay aligned; it is preparation for an executable choice, not a promise of one order outcome.
When to Upgrade the Fulfillment Model
Upgrade Signals
- Core SKUs already sell consistently.
- Delivery speed is becoming a conversion complaint.
- Support and reship cost are eating margin.
- You are ready to optimize for repeat purchase and brand experience, not just launch speed.
Execution Advice
The best shipping setup for a beginner is not the most advanced one. It is the one you can explain clearly, execute reliably, and support consistently.
Your Next Moves
Define DDP, DDU, and duty responsibility clearly
Many stores do not fail because they cannot ship. They fail because no one defined tax and duty responsibility before launch. Customers place an order, then discover surprise charges at customs or final delivery. From the customer side, that is not an international shipping issue. It is a broken merchant promise.
At minimum, make two things explicit
- Whether your main markets are operating closer to DDP or DDU/unpaid-duty fulfillment.
- Whether website copy, FAQ, policy pages, checkout messaging, and support templates all explain duties with the same logic.
Do not design delivery promises as one vague range
A stronger promise is not just 7 to 15 days. It separates handling time, transit time, and known risk conditions by market. That creates more realistic customer expectations and gives support a cleaner script. Vague promises turn every delayed parcel into a new explanation problem.
A more usable promise structure
- Handling time: for example, ships in 1 to 3 business days.
- Transit time: split by core markets instead of using one global number.
- Risk notes: explain holidays, customs, remote zones, and pre-order exceptions separately.
- Tracking promise: say when tracking becomes available and how often it updates.
Reverse logistics cannot wait until something breaks
Many operators only design the outbound path and ignore the return path. In reality, refused parcels, bad addresses, uncollected deliveries, cancellations, and return requests all create reverse-logistics cost. Without minimum rules, returned parcels quickly absorb margin and support time.
Exception playbook must align support, warehouse, and policy rules
Shipping exceptions are not only a logistics problem. Customers experience them as a brand-reliability problem. A stable playbook means support knows how to reply, operations knows how to resolve, and policy pages reflect the same promise logic.
Minimum exception playbook
Shipping Promise Repair practice: repair the promise chain before support absorbs it
When shipping pressure appears, do not only write a warmer support reply. Decide whether the issue sits in the promise, Shopify settings, checkout display, email notice, carrier ability, duties language, or exception playbook. These four scenarios are where new stores most often turn shipping setup into conversion and support debt.
| Scenario | Tempting wrong move | Safer repair | First evidence | Pause line |
|---|---|---|---|---|
| Duties appear at delivery | Have support explain that international orders may have duties without changing page copy or fulfillment method. | Decide whether the promise is DDP, DDU/DAP, or unpaid duties; if duties are collected, confirm DDP-capable labels and carriers are actually used. | Checkout duties message, Shipping Policy, order label, carrier service, support record, and market test-order number. | Until duties language is consistent, do not run no-extra-fee or fast-customs claims. |
| Remote-zone free shipping loses margin | Keep one global free-shipping rule and manually cancel or ask buyers for extra postage after orders arrive. | Split markets into core, test, and blocked groups; add zone rates or block delivery for remote regions. | Rate names for 3-5 representative addresses, carrier quote, parcel weight, margin, and final total. | Before remote-region cost is tested, do not make free shipping on everything the main ad promise. |
| No tracking after 72 hours | Reply please wait without checking supplier dispatch, carrier first scan, and notice timing. | Check fulfillment status, carrier first scan, supplier dispatch time, and shipment-notice trigger before setting the next update time. | Order fulfillment status, tracking page, carrier record, shipment email, and supplier dispatch proof. | Until the no-scan cause is clear, do not label the route as a stable tracked or fast-delivery promise. |
| Hybrid SKU timing conflict | Keep one clean delivery range and let support explain differences after purchase. | Split the promise by SKU, location, and market: product pages state handling/transit time and checkout shows the matching delivery method. | SKU, inventory location, order routing, product-page promise, checkout method, order-email sample, and order timeline. | Before hybrid fulfillment display is working, do not place long-tail SKUs into the same fast-shipping product set or ad promise. |
Output of this module
Write the scenario, wrong move, safer repair, first evidence, update targets, and pause line into the shipping promise and exception matrix. The promise is ready for launch QA only when Shipping Policy, FAQ, product-page shipping note, checkout-adjacent message, order email, and support template say the same thing.
Official boundary: shipping promises must match Shopify settings and real fulfillment
Shopify shipping and fulfillment documentation places rates, packages, locations, order routing, delivery methods, timelines, and notifications inside fulfillment setup. The FTC Mail, Internet, or Telephone Order Merchandise Rule guide also stresses that shipment representations need a reasonable basis.
The point is not to memorize platform documentation. The point is that any public promise about ship time, delivery time, tracking, or duty responsibility needs evidence in Shopify settings, checkout fields, order records, labels, and support records.
Official boundary last reviewed: 2026-06-29. Shipping rates, locations, fulfillment routing, duties/import taxes, and FTC shipment-promise rules can change with Shopify capabilities, markets, carriers, and regulations. Before launch, recheck Shopify, carrier, customs/tax adviser, and target-market official sources. This lesson builds a shipping promise and evidence trail; it is not legal, tax, or customs advice.
Fulfillment Promise Worksheet: define shipping promise, cost, returns, and exceptions before launch
A shipping promise cannot be only "global delivery in 7-15 days." An executable promise separates processing time, shipping rate, delivery window, tracking notice, returns/reshipment, and fulfillment exceptions into a worksheet. The product page then knows what to say, the policy page knows what it can support, support knows what it can promise, and the team knows when to pause a fast-shipping or free-shipping claim.
| Worksheet field | What to define | Cost / exception check | Acceptance line |
|---|---|---|---|
| Processing window | Dispatch timing after payment, cut-off time, weekend handling, and preorder rules. | Labor, packaging, 3PL pick-pack fee, stockout, and custom-item exceptions. | Only promise same-day or next-day dispatch when stock, cut-off, warehouse log, and order notice can prove it. |
| Shipping rate and free-shipping threshold | Free shipping, flat rate, zone rate, remote surcharge, and blocked regions. | Test carrier quote, weight, package size, and order margin with representative addresses. | Only put free shipping in ads or hero copy after core, remote, and heavy-order addresses are tested. |
| Delivery window | When transit time starts, business-day language, carrier service, and country differences. | Weather, customs, carrier delay, promo peak, and cross-border transfer need prepared explanations. | Publish a specific window only when page, checkout, order email, and real first-order tracking match. |
| Tracking notification | When shipment notice sends, when tracking first scans, and when stalled tracking triggers a reply. | No first scan after 72 hours, split parcels, partial shipment, supplier delay, and address issues. | Only emphasize tracked shipping when notice trigger, tracking link, support template, and internal alert work together. |
| Returns and reshipment | Rules for late, damaged, lost, wrong, buyer-remorse, and size-fit cases. | Reship cost, return label, return warehouse, refund without return, chargeback risk, and product margin. | Only claim free returns or easy reship when policy, support template, order notes, and financial cost line match. |
| Fulfillment exception | Stockout, backorder, split shipment, address error, fraud hold, and supplier delay. | Refund reserve, replacement SKU, carrier upgrade, manual follow-up, and support first-response SLA. | Move to launch QA only when exception review lead, notification template, refund/reship authority, and review window are defined. |
Pick the field you struggle to explain and turn it into one team-ready sentence. For example: "US hero SKUs dispatch within 1 business day after payment and usually arrive 3-7 business days after shipment; remote regions, holidays, stockouts, and preorders are flagged separately; no first tracking scan after 72 hours triggers a carrier and warehouse check." That sentence reduces more conversion and support risk than a vague "fast delivery" claim.
When a 7-12 day delivery promise breaks: handle Day 0 to Day 20
If the page promises 7-12 business day delivery, do not only reply "please wait" when something goes wrong. Put the order on a timeline: which day of the promise is it, where should you check first, what should support say, and when does refund or reship review begin. In plain terms, 3PL means a third-party warehouse or fulfillment partner, and SLA means the team's time rule for first reply, recheck, and escalation.
| Day | What happens | Check first | Customer reply | Refund / reship boundary |
|---|---|---|---|---|
| Day 0 | Order is paid and the 7-12 day promise starts. | Order value, SKU, address, shipping rate, preorder status, remote region, and fulfillment location. | Your order is confirmed; processing time and transit time now follow the public promise. | No refund or reship discussion yet. Align order email, page promise, and backend route first. |
| Day 2 | Label is created, but the warehouse may not have handed the parcel to the carrier. | 3PL SLA, cut-off time, warehouse intake, label creation, real dispatch, and whether shipment notice was too early. | The parcel is in warehouse processing. Tracking updates after carrier first scan; we will recheck within 24-48 hours. | Do not reship before the promise window breaks; escalate only if warehouse confirms loss or internal SLA is missed. |
| Day 5 | Tracking still says label created, and the buyer starts to worry. | Warehouse dispatch proof, carrier pickup, supplier reply, split-parcel status, and internal exception alert. | We are checking warehouse and carrier records. The next update is X; if tracking is still blank by Y, we will offer reship or refund options. | Set a threshold: no first scan after 72 hours or no warehouse transfer proof triggers refund/reship review. |
| Day 8 | The buyer asks where the package is. Support SLA now matters. | First-response time, order timeline, tracking, 3PL/carrier case, policy promise, and internal escalation line. | The parcel is currently stuck at X. We have checked with Y, and the next reply time is Z. | If still inside the window, escalate inquiry first; if evidence shows no warehouse transfer or loss, reship or refund early. |
| Day 12 | The promise window ends; asking the buyer to keep waiting creates chargeback and review risk. | Last scan, carrier case, delivery proof, loss likelihood, reship stock, margin, and refund authority. | This has passed our promised window. You can wait until X, receive a reshipment, or receive a refund / partial refund under our rule. | Offer a clear option: wait, reship, refund, partial refund, or carrier claim. |
| Day 15 | Still unresolved, so cost and responsibility must be decided. | Buyer address, warehouse, carrier, duty refusal, supplier delay, or an overpromised page. | This order has moved into exception handling. The current option is X; if you choose reship / refund, we will complete it within Y. | Merchant fault usually reships or refunds; buyer address errors may require postage; carrier fault triggers a claim. |
| Day 20 | After resolving the order, write the issue back into the system. | Route exception rate, SKU exception rate, support tickets, refund / reship cost, and whether to pause fast or free shipping promises. | Finish affected-buyer resolution; for future buyers, rewrite the public promise into what the team can keep. | Record reship, refund, partial refund, claim, pause selling, or route change in the matrix. |
The timeline turns "shipping is slow" from a support mood problem into an operating decision. Inside the promise window, check evidence and give a recheck time. Once the window ends, or evidence proves no warehouse transfer, loss, or address exception, the buyer needs an executable option.
Fulfillment Promise Checker: judge 3PL delay, free shipping threshold, and tracking gaps
The worksheet answers how the promise should be written. The Checker answers whether that promise can remain public after fulfillment pressure appears. The common beginner mistake is to rewrite support replies first while leaving warehouse SLA, shipping subsidy, tracking first scan, refund/reship authority, and support SLA unchecked. That may calm one buyer, but the page keeps creating the next batch of the same problem.
| Check scenario | Trigger | Check first | Customer line | Pause line |
|---|---|---|---|---|
| 3PL delay | After the 3PL receives the order, pick-pack or carrier first scan runs 24-48 hours behind the promise. | Order entry time, warehouse intake status, cut-off time, label, first scan, and Shopify fulfillment sync. | Explain the parcel is in warehouse processing, the next check time, and what happens after threshold: reship, refund, or escalation. | If two batches exceed the promise window, pause same-day or next-day shipping claims. |
| Free shipping threshold | AOV rises, but remote addresses, heavy items, or low-margin bundles consume profit. | Checkout shipping, carrier quote, package weight, and order margin for metro, remote, heavy, low-margin, and bundle carts. | State eligible countries, threshold, product exceptions, and remote-region exceptions before the buyer orders. | Until primary and remote addresses are tested, do not use sitewide free shipping as the hero promise or main ad hook. |
| Tracking gap | The buyer receives shipment notice, but tracking has no first scan or stalls at transfer. | Whether shipment notice was too early, carrier first-scan rule, supplier or warehouse dispatch proof, split parcels, and internal alert threshold. | Explain when tracking may update, where it is stuck, the next check time, and options after threshold. | If a route repeatedly has no first scan, stop labeling it as tracked or fast shipping. |
| Refund / reship boundary | Late, lost, damaged, wrong, or returned parcels appear, and support improvises refund versus reship. | Responsibility source, photos, delivery proof, carrier case, policy screenshot, margin, reship cost, and refund authority. | Give clear options: wait for investigation, reship, refund, partial refund, or escalation, and state the evidence needed. | Before the rules are clear, do not claim easy reship, free returns, or risk-free purchase. |
| Support SLA | Shipping tickets grow, and support does not know where to check first, when to reply, when to escalate, or who can approve refunds. | First-response time, recheck time, escalation condition, review lead, allowed actions, and forbidden promises. | The first reply states known status, next update time, evidence needed from the buyer, and the option after threshold. | Do not scale complex fulfillment markets before support has first-response and escalation lines. |
The point of the Fulfillment Promise Checker is to move shipping problems from "what should support say" back to "can this promise stay public." If evidence is not ready, pause high-promise phrases such as fast shipping, sitewide free shipping, tracked delivery, and easy reship. Bring them back only after warehouse, carrier, policy page, support template, and finance cost line match.
The Checker is not a one-click release. Choose the scenario closest to the current pressure, take its trigger, first evidence, and pause line, then decide whether the page, rate, or support path needs repair.
Copyable lesson notes: fulfillment promise and exception record
If you promise global 7-15 day delivery while logistics, duties, and tracking differ widely by country, the issue becomes conversion and support debt.
Write these fields before copying
- Current pressure: Which issue hits conversion or support first: duties surprise, remote-zone margin loss, no tracking, or hybrid SKU timing conflict.
- First evidence: Which rate name, tracking, label, order number, or carrier record you will keep first.
- This-week action: One key market, rate, timing, or exception rule to sync this week.
- Pause action: Which delivery promise, free-shipping angle, ad, or product set must pause until evidence is ready.
- Review window: For example, recheck page and checkout in 48 hours, then exceptions and support records in 7 days.
- Official review date: When the Shopify, carrier, duties, and shipment-promise sources were last checked.
- Review lead: Who will recheck rates, tracking, duties language, and exception records.
- Store Launch Readiness Scanner input: Rate name, tracking, duties, official review date, and exception evidence for the launch check.
- Next route: Continue into policies, support playbook, or launch QA.
Before policy, support, and QA work, bring primary markets, shipping rules, handling time, transit time, duty logic, tracking milestones, exception review lead, official review date, next recheck time, and Store Launch Readiness Scanner input.
The record matters because the next review can see which promise has evidence and which one must remain paused. Return to policies for missing delivery wording, go to support for missing response/escalation action, and take it to launch QA only when the records align on one test path.