Triage ShipBob shipment exceptions before customers email

PromptCreate

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.

What does this prompt do?

Watches your ShipBob fulfillment for shipments that hit an exception or get put on hold, and reacts the moment one happens
Reads the full order and the carrier's tracking history, then works out whether it is a carrier delay, a damaged or lost parcel, a bad delivery address, or an internal data problem
Posts a triaged alert to your ops channel in Slack with the order reference, the customer name, what the carrier has reported, and a recommended next step
Emails the customer a proactive apology with the current tracking status and an expected resolution, but only when the problem actually affects them, and only once per shipment

What do I need to use this?

A ShipBob account with access to your orders and shipments
A Slack workspace and a channel where your ops team wants these alerts to land
A Gmail account to send the customer emails from
Customer names and email addresses saved on your ShipBob orders

How can I customize it?

Pick which ops channel gets the alerts, or route damaged and lost parcels to a separate escalation channel
Change what counts as customer impacting, for example treating a delay of less than a day as internal only
Rewrite the tone of the customer email, or add a support link or goodwill discount for the worst cases

FAQs

Will my customer get an email every time the carrier reports a problem?

No. Carriers often report the same problem several times for one parcel, so this only ever sends one customer email per shipment. Every later event still shows up in your ops channel, with a note that the customer has already been contacted.

What happens when an order is on hold because of missing information?

That stays internal. If a shipment is held up because of missing or invalid order data, the workflow alerts your ops team so someone can fix the record, and it never emails the customer about a problem on your side.

Does this decide on its own whether to email someone?

Yes, that judgement is the point of it. It reads the carrier history and the order, decides whether the customer's delivery is genuinely late, at risk, or already failed, and only writes to them when the answer is yes.

Can I have it post somewhere other than a shared ops channel?

Yes. The alert can go to any channel your Slack bot can post in, or to a direct message if you would rather keep exception handling with one person.

Do I need a developer to set this up?

No. You connect your ShipBob, Slack, and Gmail accounts, tell it which channel to post in, and it runs whenever ShipBob reports a shipment problem.

Related templates

Build a credential rotation checklist when someone leaves

When someone leaves, we check which shared passwords they used in their final months and post a ranked rotation list to your security channel.

+1

Agentic Task

Trace phishing emails to the sending IP and report abuse

Every 15 minutes, forwarded phishing reports get traced back to the server that really sent them, with a verdict in Slack and the worst senders reported.