A merchant promises different delivery speeds by destination and cannot tell which carrier or lane is the reason a promise is missed. In this case, the immediate task is to analyze delivery performance against stated commitments. The workflow should produce a carrier and lane view where each shipment is measured against the commitment it was sold under.
First replace every [bracketed] placeholder with real store scope and constraints, then add any actual records or data you have, and paste it into your preferred AI assistant or Spark agent. Spark will follow this page's workflow to produce structured output and verification steps.
Act as a Shopify operations specialist.
Help me analyze delivery performance against stated commitments.
My store context is [describe the business, products and target audience].
My scope is [specify the affected products, pages, customers or reporting period]. Use these inputs: [the delivery promise recorded at purchase per order with its destination and service level, first acceptance and delivery scan times per shipment, the merchant's calendar rules for weekends and holidays, the destination timezone, and the merchant's minimum sample size per lane]. Measure each shipment against the promise it was sold under by comparing the delivery scan with the promised date in the destination's timezone, counting a shipment as met only when the promise was achieved inside that stated calendar, and excluding from the rate any shipment still in transit, returned to sender, or sold under a promise later changed, each excluded shipment listed with its reason.
Return a delivery performance report with variance notes by carrier and lane for the specified task.
Show the relevant evidence or before-and-after examples and explain how I can verify the result.
If essential data is missing, ask for it and mark unsupported conclusions as unknown.
Do not invent metrics, product claims or customer facts.
For any publication, message, account or store change, use only connected tools within my explicitly authorized scope and report success only after verification; otherwise provide the draft or proposed steps.Split the work into input, judgment, and deliverable phases. Verify each step's output before moving to the next.
Pull, for the merchant-defined reporting window, the delivery promise communicated to each customer at purchase with its destination and service level, the first carrier acceptance scan and the delivery or final scan for every shipment, and the calendar rules the merchant applies to weekends and holidays.
Measure each shipment against the promise it was sold under by comparing the delivery scan with the promised date in the destination's timezone, counting a shipment as met only when the promise was achieved inside that stated calendar, and excluding from the rate any shipment still in transit, returned to sender, or sold under a promise later changed, each excluded shipment listed with its reason.
Deliver a carrier and lane table showing shipment count, met count and the days of variance per late shipment, report any lane whose shipment count sits below the merchant's stated minimum sample size with raw counts instead of a rate, and reconcile the shipments in the table against the order export for the same window.
Cover decision rules, frequent misunderstandings, and required inputs so the team aligns on prerequisites before execution.
The one communicated to that customer at the moment of purchase, because a later internal target was never promised to them and cannot judge a past order. The boundary is a promise the merchant and the customer explicitly re-agreed after checkout, in which case the later promise governs and the change is noted on the row.
No, only shipments carrying a delivery or final scan are measured, since an in-transit parcel may still meet its promise. Those shipments are listed separately with the days elapsed, so the merchant can see exposure that has not yet resolved instead of a penalty that may never be owed.
Whichever the stated promise counts, because the merchant's calendar rules decide whether weekends and holidays are elapsed time or excluded days. Applying one rule to some lanes and another to others makes them incomparable, and where a promise is silent the report states the calendar it used.
Start with scenarios under the same topic, then expand into cross-topic matches suggested by similarity.
Ciwi Spark builds Shopify-native AI tools and agents around the workflows merchants actually run: research, ads, translation, and customer support. Stop rewriting the same prompts by hand.