A dispatch log records movement or assignment. A delivery-exception collection can explain why a planned movement changed and what happened afterward. Keep the shipment, delivery attempt and resolution as separate units. Otherwise a successful second attempt can hide the first failure and the records explaining it.
Trace a fictional delivery exception
Shipment S-812 was scheduled for June 8. Attempt A-1 failed because the receiving site was unavailable. A message thread arranged a new slot, attempt A-2 completed on June 9 and a resolution note closed the exception. The final delivered flag does not show that sequence.
The map below is a fictional schema. In your inventory, use the identifiers that actually exist and mark any missing attempt or exception link.
| Stage | Fictional identity | Relationship to inspect |
|---|---|---|
| Dispatch | Dispatch D-73 | Shipment S-812 |
| First attempt | A-1 | S-812 and event time |
| Exception | Exception E-18 | A-1 and recorded reason |
| Reschedule | Message thread M-31 | E-18 or S-812 |
| Second attempt | A-2 | S-812 and completion evidence |
| Resolution | Note N-20 | E-18 and final outcome |
Keep proof of delivery in context
A signature, photo or delivery document needs a relationship to the relevant shipment and attempt. A file named with a date may require further inspection. A shipment reference in the attachment metadata is a stronger link to record.
One shipment may contain several consignments or stops. State the unit used by each record group so a stop-level exception is not interpreted as a failure of the entire shipment. Preserve the grouping table or reference if it is available.
Distinguish event time from system time
Dispatch time, scan time, message time and record-entry time can differ. Inventory their meanings and time zones. A note entered after the event may explain it without providing a precise event timestamp. Keep that distinction rather than forcing all records into a misleading minute-by-minute sequence.
Inspect one failed and one routine attempt
The comparison should show whether the same identifiers survive across the usual and exception paths. Record missing messages, unavailable attachments and cases resolved outside the recorded system.
- Shipment, stop and attempt identities
- Exception reason and its recorded source
- Rescheduling or replacement reference
- Proof-of-delivery relationship
- Resolution note or claim outcome
- Dates and time conventions for each group
Preserve the reason’s source
A dispatch code, driver note and customer message may describe the same delay differently. Keep the original record and its event reference instead of choosing one explanation and overwriting the others. The inventory can identify several recorded accounts without deciding which account is definitive.
Carry a precise scope question
Mercor names dispatch logs and shipping manifests among its logistics examples. Use that as the published-interest starting point, then ask about the actual linked exception collection. Name your tracking system and the attachments you can include.
Sources: Mercor
Questions about this comparison
Is a delivered status enough to describe delivery history?
It describes a final state. Attempts, exceptions and resolution require their own records.
What if the exception was resolved by phone?
Include a recorded call note if it exists and is in scope. Do not invent a transcript or message history.
Can one proof-of-delivery file cover several shipments?
Inspect its actual references and describe the relationship. Do not assume one file equals one shipment.
Sources
- Mercor program pageMercor · Checked 2026-10-06