A merchant's exception feed mixes failed attempts, address problems and held parcels, so nobody knows which items need a person today. In this case, the immediate task is to identify shipping exceptions requiring action. The workflow should produce a queue in which each exception carries a severity, the party who must act and the path to resolve it.
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 identify shipping exceptions requiring action.
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: [carrier exception codes and event descriptions for the window, the delivery window and destination per affected shipment, order and customer references, open support tickets, and the merchant's responsibility split and severity levels]. Route each exception to whichever party must act, meaning the merchant, the carrier or the customer, using the responsibility split in the merchant's records, assign the severity from those same records ranked by whether the parcel is moving, held or returning, and move purely informational events out of the queue with a note that they were logged instead.
Return an exception queue with owners and response paths 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.
Gather, for the merchant-defined window, the exception codes and event descriptions each carrier reports, the delivery window and destination of the affected shipment, the order and customer reference tied to it, and any open support ticket already raised for that shipment.
Route each exception to whichever party must act, meaning the merchant, the carrier or the customer, using the responsibility split in the merchant's records, assign the severity from those same records ranked by whether the parcel is moving, held or returning, and move purely informational events out of the queue with a note that they were logged instead.
Deliver an exception queue where each open row carries its severity, the owning party, the action that resolves it and the deadline stated by the carrier or the merchant, verify that the open row count equals the distinct shipments still carrying an unresolved code, and move resolved rows to a closed state with the resolution and the time recorded rather than deleting them.
Cover decision rules, frequent misunderstandings, and required inputs so the team aligns on prerequisites before execution.
Those needing a decision from a person before the parcel moves again, such as failed delivery attempts, address corrections and customs holds. Informational scans are logged so they cannot crowd out rows needing action, and the boundary is any code the carrier marks as requiring a response from the merchant.
Narrow enough to map to a single owner and a single action, because a rule spanning several exception types produces a message no one person can resolve. Where two codes need the same response they may share a rule, provided the row still names which code triggered it.
No, it moves to a closed state with the resolution, the party who resolved it and the time, so the history stays auditable and repeat codes can be recognised. Leaving resolved rows open inflates the queue and hides genuinely new cases.
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.