Workflow Template
Delivery Exception Workflow
Captures a delivery exception (delayed, lost, or damaged), notifies the customer while it is investigated, has the owner investigate with the carrier and decide on redelivery, replacement, or refund, executes the recovery action via dispatch or finance with customer notification, then closes out the case by recording the carrier claim outcome and cost recovered.
This workflow is designed for logistics, customer service, and operations teams that handle delayed, lost, or damaged deliveries and need a consistent way to manage each case from report to resolution. It automates customer notification, owner investigation with the carrier, routing to redelivery, replacement, or refund, and the recovery execution by dispatch or finance, then closes the loop by recording the carrier claim outcome and cost recovered. The result is a clear, timestamped record of every exception and its financial outcome, without relying on manual tracking across emails and spreadsheets.
Business Outcomes
- Faster customer communication after a delivery issue is reported
- Fewer dropped cases through structured owner investigation and routed recovery actions
- Clearer visibility into which exceptions are pending, in recovery, or closed
- Better tracking of cost recovered from carrier claims over time
- Reduced manual coordination between dispatch, finance, and the case owner
Workflow Steps
Steps
- 1Create delivery exception recordcreate record
Creates the delivery exception record from the submitted form.
- 2Set status to Investigatingupdate record
Marks the exception status as Investigating.
- 3Email customer: investigatingsend email
Emails the customer to let them know their delivery issue is being investigated.
- 4Owner: investigate with carriercreate task
Assigns the owner a task to investigate the exception with the carrier and decide on a recovery action.
- 5Save investigation findingsupdate record
Persists the carrier claim reference, findings, and recovery decision to the record.
- 6Route on recovery decision
Routes the workflow based on the recovery decision made by the owner.
recovery_decision: "Redeliver"→Dispatch: arrange redeliveryrecovery_decision: "Replace"→Dispatch: send replacementrecovery_decision: "Refund"→Finance: process refundDefault→Dispatch: arrange redelivery - 7Dispatch: arrange redeliverycreate task
Assigns dispatch a task to arrange the new delivery and record the new delivery date and tracking number.
- 8Save redelivery detailsupdate record
Persists the new delivery date and tracking number to the record.
- 9Email customer: redelivery arrangedsend email
Emails the customer with the new delivery date and tracking number.
- 10Dispatch: send replacementcreate task
Assigns dispatch a task to send a replacement and record the replacement order number and tracking number.
- 11Save replacement detailsupdate record
Persists the replacement order number and tracking number to the record.
- 12Email customer: replacement sentsend email
Emails the customer with the replacement's tracking number.
- 13Finance: process refundcreate task
Assigns finance a task to process the refund and record the refund amount and date.
- 14Save refund detailsupdate record
Persists the refund amount and date to the record.
- 15Email customer: refund processedsend email
Emails the customer that their refund has been processed, with the amount.
- 16Set status to Resolvedupdate record
Marks the exception status as Resolved once the recovery action has been completed.
- 17Owner: record carrier claim outcomecreate task
Assigns the owner a task with no due date to record the carrier claim outcome and cost recovered.
- 18Save carrier claim outcomeupdate record
Persists the carrier claim outcome and cost recovered to the record.
- 19Set status to Closedupdate record
Marks the exception status as Closed, ending the process.
Fields
Show all 22 fieldsShow fewer fields
FormDelivery Exception Report
- Owner Name*· Text
- Owner Email*· Email
- Customer Name*· Text
- Customer Email*· Email
- Order Number*· Text
- Tracking Number*· Text
- Carrier*· Text
- Exception Type*· Choice
- Description*· Long text
- Photos· File upload
TaskOwner: investigate with carrier
- Carrier Claim Reference*· Text
- Findings*· Long text
- Recovery Decision*· Choice
TaskDispatch: arrange redelivery
- New Delivery Date*· Date
- New Tracking Number*· Text
TaskDispatch: send replacement
- Replacement Order Number*· Text
- Replacement Tracking Number*· Text
TaskFinance: process refund
- Refund Amount*· Number
- Refund Date*· Date
TaskOwner: record carrier claim outcome
- Carrier Claim Outcome*· Long text
- Cost Recovered*· Number
Other fields
- Exception Status· Choice
- Owner Name*
- Owner Email*
- Customer Name*
- Customer Email*
- Order Number*
- Tracking Number*
Forms
Delivery Exception Report
10 fields
Data Views
Delivery Exceptions
order_number, customer_name, exception_type, recovery_decision +2 more
Dashboard Widgets
Recommended integrations
Setup the following integrations to extend workflow capability.
Send email in the workflow
AWS SES
Similar Categories
FAQs
Why should we automate delivery exception handling instead of managing it manually over email?
Manual handling of delivery exceptions tends to rely on scattered emails and inconsistent follow-up, which makes it easy to lose track of open cases or delay customer updates. This workflow creates a single record per exception with a status and timeline, so the case owner, dispatch, and finance always know what stage it is at. Customers are automatically notified at key points, which reduces the number of status-check inquiries the team has to field.
What is the ROI of using this workflow compared to handling exceptions case by case?
The workflow reduces the time staff spend tracking down case status, chasing carrier updates, or manually drafting customer emails, since notifications and task assignments happen automatically at each step. It also creates a consistent record of carrier claim outcomes and cost recovered, which supports better decisions on carrier performance over time. Teams handling a moderate to high volume of exceptions are likely to see the most time savings from this structure.
Who is responsible for each step in the process?
The owner investigates the exception with the carrier and decides on the recovery action, then later records the carrier claim outcome and cost recovered. Depending on that decision, dispatch arranges redelivery or sends a replacement, or finance processes a refund. Each task is assigned to a workspace member and the workflow waits for it to be completed before moving forward.
What happens at the recovery decision step?
After the owner investigates with the carrier and records their findings, the workflow routes based on the Recovery Decision field they set: Redeliver, Replace, Refund, or otherwise. Each path triggers a different task — dispatch for redelivery or replacement, finance for a refund — and the customer receives an email specific to that outcome once the task is completed.
How does the customer stay informed without needing to log into anything?
Customers are notified by email at each key stage: when investigation begins, and again once redelivery, replacement, or refund is confirmed. They submit the initial exception details through a public request form and receive these updates directly by email, with no account or login required.
Can this workflow be adjusted for how our business handles exceptions?
Yes, a workspace can change the workflow by describing the desired change in plain English or editing the steps directly in the workflow editor. This allows teams to adjust task assignments, email content, or add steps as their exception-handling process evolves, and earlier versions of the workflow are kept for reference.
What information is captured for carrier claims and cost recovery?
The owner's investigation task records the Carrier Claim Reference, Findings, and Recovery Decision on the record. Once the recovery action is complete, a separate owner task with no due date captures the Carrier Claim Outcome and Cost Recovered, giving a documented history of how each claim was resolved financially.
How is the delivery exception submitted in the first place?
A delivery exception is captured through a request form asking for owner and customer details, order and tracking numbers, carrier, exception type, a description, and photos. Submitting the form creates the record and immediately sets its status to Investigating, starting the workflow.
How do we know the status of an exception at any point in time?
Each delivery exception record has a status — such as Investigating, Resolved, or Closed — along with a timeline of what has happened on the case. Table views and dashboards in the workspace show records by status, making it straightforward to see which cases are open, in recovery, or fully closed.
Does this workflow help with compliance or refund policy documentation?
The workflow records the statuses, task entries, and timeline for each delivery exception, including recovery decisions, refund amounts, and carrier claim outcomes. This creates a documented history a business can refer to, though each business should confirm its own compliance and record-keeping obligations separately.
Ready to use this workflow?
Create a free account and customise this workflow for your business.
