Triage ShipBob shipment exceptions before customers email

When ShipBob reports a problem with a shipment, I want it triaged and in front of my ops team before the customer notices. Trigger this workflow on a ShipBob webhook subscribed to the order.shipment.exception and order.shipment.on_hold topics.

When an event arrives, pull the full picture before deciding anything. Use ShipBob Get Shipment Status Timeline for the shipment named in the event to get the carrier status history, and ShipBob Get Order for the parent order to get the order reference, the customer name and email address, and the items in the shipment. If the event does not identify the shipment clearly, use ShipBob Get All Shipments for Order to find the right one.

Classify the exception into exactly one of four buckets: a carrier delay, a damaged or lost package, a bad or undeliverable address, or an on hold data problem caused by missing or invalid order information. Base that call on the carrier status history and the order data rather than on the webhook topic name alone. Then judge separately whether the exception is customer impacting, meaning the customer's delivery is actually late, at risk, or has already failed.

Always post a triaged alert to our ops channel using Slack Bot Send a Message, whatever the classification turns out to be. Include the order reference, the customer name, the classification and whether it is customer impacting, a short readable version of the carrier status history with timestamps, and one concrete recommended next action such as opening a carrier claim, contacting the customer for a corrected address, or fixing the order record in ShipBob.

For customer impacting exceptions only, also draft and send a proactive apology to the customer with Gmail Send a Message. Keep it short and human: acknowledge the problem, state the current tracking status in plain language, give the expected resolution, and say what we are doing about it. Never invent a delivery date the carrier has not actually supported, and never send the customer raw carrier status codes.

Two rules matter more than anything else here. First, on hold cases caused by missing or invalid order data are an internal problem, so they get the Slack alert and never generate a customer email. Second, send at most one customer email per shipment, because carriers often fire repeated exception events for the same parcel. Before sending, check for an existing email about that shipment using Gmail List Messages with a search over sent mail for the order reference and the shipment id, and if one is already there, skip the email and note in the Slack alert that the customer has already been contacted.