assess.one – AI-powered business operations platform

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

  1. 1
    Create delivery exception recordcreate record

    Creates the delivery exception record from the submitted form.

  2. 2
    Set status to Investigatingupdate record

    Marks the exception status as Investigating.

  3. 3
    Email customer: investigatingsend email

    Emails the customer to let them know their delivery issue is being investigated.

  4. 4
    Owner: investigate with carriercreate task

    Assigns the owner a task to investigate the exception with the carrier and decide on a recovery action.

  5. 5
    Save investigation findingsupdate record

    Persists the carrier claim reference, findings, and recovery decision to the record.

  6. 6
    Route on recovery decision

    Routes the workflow based on the recovery decision made by the owner.

    recovery_decision: "Redeliver"→Dispatch: arrange redelivery
    recovery_decision: "Replace"→Dispatch: send replacement
    recovery_decision: "Refund"→Finance: process refund
    Default→Dispatch: arrange redelivery
  7. 7
    Dispatch: arrange redeliverycreate task

    Assigns dispatch a task to arrange the new delivery and record the new delivery date and tracking number.

  8. 8
    Save redelivery detailsupdate record

    Persists the new delivery date and tracking number to the record.

  9. 9
    Email customer: redelivery arrangedsend email

    Emails the customer with the new delivery date and tracking number.

  10. 10
    Dispatch: send replacementcreate task

    Assigns dispatch a task to send a replacement and record the replacement order number and tracking number.

  11. 11
    Save replacement detailsupdate record

    Persists the replacement order number and tracking number to the record.

  12. 12
    Email customer: replacement sentsend email

    Emails the customer with the replacement's tracking number.

  13. 13
    Finance: process refundcreate task

    Assigns finance a task to process the refund and record the refund amount and date.

  14. 14
    Save refund detailsupdate record

    Persists the refund amount and date to the record.

  15. 15
    Email customer: refund processedsend email

    Emails the customer that their refund has been processed, with the amount.

  16. 16
    Set status to Resolvedupdate record

    Marks the exception status as Resolved once the recovery action has been completed.

  17. 17
    Owner: record carrier claim outcomecreate task

    Assigns the owner a task with no due date to record the carrier claim outcome and cost recovered.

  18. 18
    Save carrier claim outcomeupdate record

    Persists the carrier claim outcome and cost recovered to the record.

  19. 19
    Set status to Closedupdate record

    Marks the exception status as Closed, ending the process.

Fields

Show all 22 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

Exceptions by Status

Recommended integrations

Setup the following integrations to extend workflow capability.

  • Send email in the workflow

    AWS SES logoAWS SES
delivery exceptionshipment exceptionlate deliverylost shipmentlogistics issue

Similar Workflows

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.

Delivery Exception Workflow | assess.one