Delivery Evidence
Delivery Handoff Evidence: A Bounded Review Method
A research method for reviewing failed dispensary delivery handoffs using attempt logs, order states, product returns, and customer communication.

Key takeaways
- A failed contact is not a failed delivery until the sequence is reviewed.
- Keep product, order, and communication states separate.
- Report unresolved returns and customer promises.
Published November 3, 2026
Question and scope
This review asks how a cannabis dispensary can describe a failed delivery handoff from its own records without turning the customer or the driver into the explanation. The decision it supports is whether the delivery routine needs a clearer contact rule, a different return path, or a better customer update. It is not a fraud investigation, a safety assessment, or a judgment about whether a customer was home. Those conclusions require evidence and authority beyond the delivery log.
The unit is one delivery event from dispatch to final disposition, including the contact attempts, the order state, the product return, and the customer communication. The population is every delivery event in a declared window that reached the at-location state, whether or not the handoff succeeded. Including successful deliveries matters because it shows the routine's normal path and prevents a review of failures from being mistaken for a description of the whole service. Keeping successful and failed events in one population lets the review compare the normal path with the exception.
What the sources establish
The Virginia Cannabis Control Authority publishes the state framework for licensed cannabis activity, and the U.S. Small Business Administration offers general guidance on managing business records. The NIST Privacy Framework provides a structure for handling customer information. These sources support the idea that delivery records should be controlled and that customer data should be limited, but they do not publish a dispensary delivery-failure rate or a standard contact sequence. The local policy is therefore the document that defines whether a contact attempt was sufficient.
That gap is important. A public rule may define who may receive a delivery or how a licensed business must operate, but the store's own policy determines how many contact attempts are made and what the driver does when the recipient is unreachable. The review can describe whether the store followed its written path. It cannot use a public source to declare that a particular failed handoff was reasonable or unreasonable without the local policy and the observed facts.
Definitions and measures
Define the handoff start as the driver's arrival at the approved location and the first permitted contact attempt. Define the end as the verified transfer or the return of the product with a documented disposition. A delivery that is rescheduled before the driver arrives belongs to a different event. A delivery that fails after three attempts and returns to the store belongs to this review. Keep the event key stable when the order is edited or the driver changes.
Useful measures include the number of events, the number that reached the location, the number with a completed handoff, the number with a failed contact, the number returned, the number still open, and the time from first attempt to final disposition. Each measure needs a denominator and a time zone. Do not report a contact-attempt count as if it were a customer count. One event may involve several attempts, and one customer may have more than one event in the window.
Evidence standard and data handling
The evidence package should include the dispatch record, the attempt log, the customer communication, the product return record, and the final order state. Record the time and channel of each attempt. If the driver used an approved alternative, link the authorization. If the customer called the store, link that contact to the event instead of creating a separate case. A later reviewer should be able to follow the sequence without interviewing everyone who was involved.
Limit personal data in the working file. The review does not need a full purchase history to determine whether a handoff was completed. Use the customer reference and the minimum contact fields. Keep the file in an approved location, restrict access, and set a disposal date. The NIST Privacy Framework is a useful reference for the lifecycle, but the store must still decide which records it may retain and who may see them. A delivery review should not become a second customer database.
Sampling and collection
A weekly sample should include completed deliveries, failed contacts, returns, and events that were rescheduled after a failed attempt. Sampling only failures will miss the conditions that make the routine work. A simple random sample may miss the rare building-access problem, so include a small purposive group of known exceptions. Report both the representative sample and the exception group separately. That keeps the findings useful without pretending the exception group is typical.
Collect the data from the dispatch system and the order record at the same time. If the customer later calls, link the call to the original event rather than closing the old record and opening a new one. Record the observation window and the system version. If a driver's note is the only source for an attempt, label it as a driver observation rather than an independently verified event. The review should distinguish what the store observed from what someone reported.
Analysis and reporting
Report the sequence, not just the outcome. A completed delivery, a failed contact followed by a successful redelivery, and a failed contact followed by a return are different paths. Show the counts for each path and the unresolved cases at the end of the window. Compare the customer's description with the attempt log where both exist. Do not average them or choose the version that supports the faster close.
Look for patterns by time, location, building type, driver, and contact channel, but treat those patterns as questions rather than conclusions. A cluster of failures at one building may reflect an intercom problem, a changed access code, or a scheduling window that does not match the recipient's availability. A cluster on one shift may reflect staffing or dispatch timing. The review should identify the next piece of evidence needed, not announce a cause.
Limits and sources of error
The attempt log may be incomplete, especially if the driver used a personal phone or a channel the store does not capture. The customer may have been reachable but unable to answer at the exact moment. The product return record may be delayed, and the financial resolution may happen in a different system. Those gaps make a simple success rate misleading. The report should show the missing evidence and the cases that remain unresolved.
Public sources cannot fill those gaps. The Virginia authority can describe the regulatory setting, the SBA can support a general recordkeeping discussion, and NIST can frame privacy handling. None of them measures the store's delivery reliability or proves that a particular driver or customer acted in good faith. The local review should stay within what the records can show and label the rest as unknown.
Review and next action
End the review with one operational change and one evidence improvement. The operational change might be a second contact field, a clearer customer confirmation, or a dispatcher available during the delivery window. The evidence improvement might be a required attempt timestamp or a return-record field. Give each change an owner and a review date. Then repeat the review with the same definitions so the comparison means something.
Share the result with drivers, dispatchers, and the front desk. The people closest to the handoff can explain why a step is hard to follow. Their input may show that the policy is clear but the tooling is not, or that the tooling is fine but the customer message sets the wrong expectation. The review is most useful when it leads to a specific repair rather than a general reminder to be more careful.
Conclusion
A failed delivery handoff is a sequence of events, not a single verdict about a customer or a driver. A defensible review links the dispatch, the attempts, the customer communication, the product return, and the final order state. It reports unresolved cases and avoids claiming that a public source proves local reliability. That method gives the store a factual basis for changing the routine.
The strongest conclusion is limited but actionable: here is how many events reached the location, how many handoffs completed, where contact failed, what happened to the product, and what the customer was told. Those facts are enough to improve the next delivery without overstating what the store knows. It also shows where the store still lacks evidence. Those gaps belong in the next review rather than in a conclusion the data cannot support.
Sources
The sources below support the regulatory, recordkeeping, and privacy context for this review. They do not measure this dispensary's own operation, and no source is presented as a local benchmark. They frame the reason the queue matters and the privacy boundary around it. The operational finding still comes from the store's own records.
- Virginia Cannabis Control Authority
- U.S. Small Business Administration, manage your business
- NIST Privacy Framework
This article describes a measurement method rather than legal, medical, or compliance advice. Confirm current requirements with the applicable authority and qualified advisers. Keep the local definition, observation window, and source links with the report. Recheck the sources before reusing a number or a regulatory description.
Reviewed by the DispensaryVA editorial team on 2026-11-03.