Where is my order triage desk for ecommerce support teams

Build me a "where is my order" triage desk that my ecommerce support team opens every morning and works out of. This is not an alerting workflow and it must not be framed as one: nothing runs on a schedule and nothing gets pushed anywhere. It is a persistent queue that shows every in-transit shipment ranked worst first, so an agent can tell a simple status question apart from a real delivery exception in seconds.

The main view is a triage board. Load the in-transit shipments from EasyPost using List Trackers, and pull the full detail for a shipment with Retrieve Tracker when a row needs its complete scan history. Join each shipment to its store order in Shopify: use List Orders to match on the tracking number carried on the order's fulfillments, and Get Order to load the full order once a row is matched, so each row can show the customer name, the items in the box, the order value and the promised delivery date. Then check Gorgias for whether that customer has already written in: List Tickets filtered to the customer to find any open conversation, and List Messages to read the thread on it.

Sort every shipment into one of four buckets, ordered worst first. Delivery exception comes first: the carrier has reported a problem such as a failed delivery attempt, a bad address, the recipient being absent, or a customs hold. Stalled comes second: the package is still moving in theory but there has been no new carrier scan for longer than the stall threshold, which defaults to three days. Past estimated delivery date comes third: the carrier's estimated delivery date has passed and the package has not been delivered. On track comes last. Within each bucket, rank by how bad the row is, using days since the last scan, days past the promised date and order value, so the worst rows float to the top of the whole board.

The single most valuable column is the silent-problem flag, and it should be visually obvious on the board. A shipment gets flagged as a silent problem when it lands in the exception, stalled or past-due buckets but that customer has no open ticket in Gorgias. These are the customers who are about to be upset and have not written in yet, and reaching out first is the entire reason my team would open this app. Make it filterable so an agent can work only the silent problems, and show a count of them at the top of the board.

Each row on the board shows the bucket, the silent-problem flag, the customer name, the order number, the carrier and tracking number, the last carrier scan and how long ago it was, the promised delivery date and how far past it we are, the order value, and whether there is an existing ticket with its status and how long the customer has been waiting. Clicking a row opens a detail panel with three things side by side: the full carrier scan history from the tracker as a timeline, the order with its line items, shipping address and promised date, and the existing ticket thread with its messages in order.

Every row has a "Draft customer update" button that kicks off a background agent. The agent reads the full tracking scan history for that shipment, the matching order, and any existing ticket thread, then works out what actually happened to the package and writes a short plain-English update for the customer: where the package really is, what went wrong if something did, what happens next, and by when. It should sound like a human support agent wrote it, avoid carrier jargon and internal status codes, and never invent a delivery date the carrier has not given. The draft lands back in the app attached to that row as a reviewable draft, so the board shows which rows have a draft waiting.

A support agent reviews the draft in the app, edits the text if they want, and either approves or discards it. On approval the agent sends it as a reply on the customer's Gorgias ticket using Create Message. Nothing is ever sent to a customer without a human approving it first. If the silent-problem customer has no existing ticket, make that case explicit in the interface so the team knows the reply will start a new conversation rather than continue one, and let them choose whether to send it or just mark the row handled.

Two things need to persist. First, the stall threshold has to be configurable in a settings area, defaulting to three days without a carrier scan, because the right number is different for ground versus international shipping. Changing it re-sorts the board immediately. Second, each support agent can mark a row as handled so the queue actually clears, and the app records who handled it and when. Handled rows drop out of the default view but can be brought back with a filter, and if a handled shipment later gets a new exception it should come back into the queue. Show each person who else has already claimed or handled a row so two agents do not write to the same customer about the same package.

Design it for speed during peak season, when this queue gets long. The board should be dense and scannable with the bucket and the silent-problem flag readable at a glance, and an agent should be able to go from opening the app to sending a customer update without ever leaving the screen.