All posts
Use case12 March 2026Β·7 min read

Broken parcels, missed deliveries, angry customers β€” and the ops work behind each one

Every delivery incident triggers a chain of manual coordination across email, Teams, and spreadsheets. Whirl handles the research and queues the actions. Your team just approves.

Whirl Inbox
5 items this morning
🚨

Failed delivery β€” address not found

via Email Β· 3m ago

Review
πŸ“¦

Customer asks for ETA update

via Aircall Β· 8m ago

Draft ready
πŸ”„

Re-delivery scheduled for #4891

via Email Β· 15m ago

Approved
πŸ“‹

POD received β€” 12 parcels

via Email Β· 22m ago

Approved
⚠️

SLA breach risk β€” shipment #7230

via Teams Β· 31m ago

Review
A dispatcher's Whirl inbox mid-morning β€” delivery exceptions, customer inquiries, proof of delivery, and SLA alerts all surfaced in one place.

The coordination tax

Every delivery operation looks roughly the same from a distance: pick up, move, drop off. But the people running these operations know the truth. The actual work is everything that happens around the delivery β€” the coordination, the exception handling, the customer communication, the documentation.

A driver reports a failed delivery. Someone needs to look up the customer's contact details and delivery preferences, figure out if there's an alternate address or a safe place to leave the parcel, notify the customer, reschedule, update the tracking sheet, and alert the dispatch team if it affects the rest of the route. That's one exception. On a busy day there are dozens.

Then there are the customer calls and emails. β€œWhere's my package?” β€œCan you deliver before 2pm?” β€œI need to change the address.” Each one requires pulling up tracking data, checking driver schedules, and composing a response. Meanwhile, the dispatch team is juggling route changes, capacity issues, and SLA deadlines across Teams or Slack, email, spreadsheets, and whatever delivery platform they're running.

Delivery ops teams spend more time coordinating around deliveries than on the deliveries themselves. Every exception creates a ripple of manual work across 4-5 tools.

How Whirl works for delivery teams

Whirl monitors the channels your dispatch and ops team already live in β€” Outlook or Gmail, Aircall, Teams or Slack, and notifications from your delivery platform. When something comes in, Whirl reads it, pulls the relevant context from your customer records, delivery docs, and tracking systems, and either drafts a response or queues the right actions for your team to review.

Your team stays in control. Whirl does the lookup, the cross-referencing, and the drafting. Nothing gets sent or updated without approval. Here's what that looks like across the most common delivery workflows.

Handling delivery exceptions

Failed deliveries are the biggest source of coordination overhead. The driver couldn't find the address, nobody was home, the access code didn't work, the parcel was damaged. Each exception requires a different response β€” and the right response depends on the customer's preferences, the delivery SLA, and the contents of the shipment.

Incoming

🚨

Failed delivery

Driver reports: address not found for shipment #4891, 3 parcels

Whirl researches

  • Customer contact details & preferences
  • Alternate delivery address on file
  • Shipment contents & priority level
  • SLA deadline (next-day guaranteed)

Actions queued

  • βœ‰οΈEmail customer with re-delivery options & alternate address form
  • πŸ“ŠUpdate tracking sheet with exception status & reason
  • πŸ’¬Alert #dispatch in Teams/Slack with re-delivery needed flag

Whirl looks up everything the team would need to look up manually β€” customer preferences, alternate addresses, SLA constraints β€” and queues the right set of actions. The dispatcher reviews, approves, and moves on. What used to be a 10-minute scramble across three tools becomes a single click.

Responding to customer inquiries

β€œWhere's my package?” is the most common question in delivery ops β€” and the most tedious to answer. Each response requires pulling up the specific shipment, checking its current status, estimating arrival, and composing a reply with the right level of detail. Multiply that by dozens of inquiries a day across email and phone.

Incoming

πŸ“ž

Customer inquiry

"Can you tell me when my order will arrive?" β€” via Aircall voicemail

Whirl researches

  • Order number & shipment tracking
  • Current driver location & route
  • Estimated delivery window
  • Any exceptions or delays on file

Actions queued

  • βœ‰οΈDraft email with tracking update, ETA, and driver contact if needed

Whirl pulls the tracking data, checks for any exceptions or delays, and drafts a response with the specific ETA and current status. If the customer called via Aircall, Whirl drafts an email follow-up. If they emailed, Whirl replies directly. Same research, adapted to the channel.

Coordinating pickup requests

New pickup requests come in from clients throughout the day β€” sometimes scheduled, sometimes urgent. Each one needs to be matched against driver availability, route capacity, and SLA requirements before the client gets a confirmation and the driver gets dispatched.

Incoming

πŸ“¦

Pickup request

Client requests same-day pickup: 8 pallets from warehouse, deliver by 5pm

Whirl researches

  • Driver availability & current routes
  • Vehicle capacity (8 pallets = large van minimum)
  • Client SLA & priority tier
  • Warehouse operating hours

Actions queued

  • βœ‰οΈConfirm pickup window with client via email
  • πŸ’¬Dispatch driver via Teams/Slack with pickup details & deadline
  • πŸ“ŠAdd to daily manifest in tracking sheet

Whirl checks driver availability, vehicle capacity, and the client's SLA tier β€” then queues the confirmation to the client and the dispatch message to the driver. The dispatcher just verifies the match makes sense and approves.

Processing proof of delivery

When a driver completes a drop-off, the paperwork begins. The tracking system needs updating, the customer needs a confirmation, the client needs an invoice-ready record, and any issues noted during delivery need to be flagged. It's routine work β€” but it adds up fast when you're processing hundreds of deliveries a day.

Incoming

πŸ“‹

Proof of delivery

Driver submits POD: 12 parcels delivered to Acme Warehouse, signed by J. Rivera

Whirl researches

  • Original shipment manifest (12 of 12 delivered)
  • Customer notification preferences
  • Client billing & POD requirements
  • Any partial delivery or damage notes

Actions queued

  • βœ‰οΈSend delivery confirmation to customer with POD reference
  • πŸ“ŠUpdate tracking sheet β€” mark complete, log signature
  • πŸ“Archive POD documentation in Google Drive

All the routine post-delivery documentation β€” customer notification, tracking update, filing β€” gets queued in one action set. The team approves and the paperwork is done. No more chasing drivers for missing PODs or manually emailing customers one by one.

Escalating SLA breaches

The most expensive problems in delivery are the ones you catch too late. A shipment sitting in a depot while the SLA clock ticks. A driver stuck in traffic with a time-sensitive delivery. A failed first attempt on a next-day-guaranteed order. Whirl watches for these and escalates before they become costly.

Incoming

⚠️

SLA breach risk

Shipment #7230 β€” guaranteed by 12pm, driver delayed, ETA now 1:30pm

Whirl researches

  • SLA terms & penalty thresholds
  • Nearest available driver with capacity
  • Customer contact & escalation preferences
  • Shipment priority & contents value

Actions queued

  • πŸ’¬Alert #urgent-dispatch in Teams/Slack with breach risk & alternatives
  • βœ‰οΈDraft proactive customer email with revised ETA
  • πŸ“ŠFlag shipment as at-risk in tracking sheet

Whirl doesn't just flag the problem β€” it researches the options. Which driver is closest? What are the penalty terms? Should the customer be notified proactively? The dispatch team gets a complete picture and can act immediately instead of scrambling to gather context.

What it connects to

Whirl integrates with the tools delivery teams already run on. No new systems to adopt, no workflow migration:

  • Outlook & Gmail β€” monitors customer inquiries, delivery notifications, and client communications. Drafts and sends replies directly from whichever inbox your team uses
  • Teams & Slack β€” sends dispatch alerts, exception notifications, and SLA warnings to the right channels, tagging the right people
  • Aircall β€” picks up voicemails from customers and drivers, drafts email follow-ups with the right context
  • Excel & Google Sheets β€” updates tracking manifests, delivery logs, and exception reports in real time
  • SharePoint & Google Drive β€” reads delivery procedures, client SLA docs, and route playbooks to make accurate decisions
  • Your delivery platform β€” connects to Onfleet, Spoke, Bringg, and other delivery management tools for shipment tracking, route data, and driver status

A single delivery exception might trigger updates across email, Teams, and your tracking sheet β€” and Whirl handles all of them in one queued action set. Your team reviews and approves instead of doing the legwork.

The result

Delivery teams using Whirl handle more volume without adding headcount. Exception resolution drops from 10-15 minutes to a single approval click. Customer response times go from hours to minutes. SLA breaches get caught before they become penalties.

The dispatch team stops being a bottleneck and starts being a decision layer. They review Whirl's research and actions instead of doing the lookup, typing, and cross-referencing themselves. Same team, more capacity, fewer fires.

Ready to try Whirl?

Your ops team deserves this

If your team spends hours on coordination, message processing, and data entry β€” Whirl can give that time back.