Delivery exception alerts in Slack, logged to a spreadsheet

When an EasyPost tracker webhook fires because a package tracking status changed (the tracker.updated event), first check the new status. Only continue if the status is an exception, error, failure, or return_to_sender style status. Ignore normal pre-transit, in-transit, out-for-delivery, and delivered updates so the team is never pinged for routine movement.

For a qualifying exception, use EasyPost Retrieve Tracker to pull the full tracker detail by its id. Read the tracking status, the status detail, and the tracking history to work out what went wrong (for example a failed delivery attempt, a bad or undeliverable address, damage, a customs hold, or a return to sender) and where the package last scanned. Decide one concrete recommended next step for the ops team, such as contacting the carrier, correcting the address, or reaching out to the customer.

Post a concise alert to our shipping-ops Slack channel with the Slack Bot Send a Message action. Name the carrier, the tracking number, the exception reason in plain language, where the package last scanned, and the recommended next step. Keep it to a few scannable lines.

Also log the incident to our running Delivery Exceptions Google Sheet with the Append Values action, adding a new row that records the date, tracking number, carrier, status, and reason. This running log lets us spot recurring problems, like a carrier or lane that keeps failing.