Proof of delivery is a dispute-resolution feature

The call that has no good answer

A patient rang the pharmacy to say their delivery had not arrived. The record said delivered, with a signature and a timestamp. Both were true. The medication had been left at a reception desk with somebody who worked in the building, and the patient had never been told.

At that point the pharmacy has no way to resolve the call except to send someone to look. The delivery record proved that a delivery happened. It could not say to whom, which is the only fact that mattered.

A signature is not proof

We had treated the signature as the end of the chain, the way most delivery systems do. It is not. A signature proves that somebody accepted the parcel. In a residential delivery that somebody is usually the patient; in practice it is frequently a neighbour, a receptionist, a family member or a care worker.

The record now captures who received it and in what capacity — the name, and the relationship to the patient. Two extra fields, captured at the door by the person already standing there with a device in their hand.

The cost of collecting them is a few seconds per delivery. The cost of not collecting them is an unresolvable phone call, a replacement dispensed at the pharmacy's expense, and in the worst case a controlled medication nobody can account for.

The report is the interface

Most of the value of that data arrives in a format nobody designs with much care: the export. Pharmacies hand these to auditors, to insurers, and to patients' families, and the thing being evaluated is the pharmacy's competence.

So the delivery report prints the whole chain on one page — status, pharmacy, customer, tags, amount requested against amount collected, prep time, actual completion, courier, signature, and the estimated completion it is being measured against. Eleven columns, chosen because each one has been the answer to a question somebody actually asked.

• Amount requested against amount collected, side by side, because the gap is the question
• Prep time and actual completion, so a slow delivery can be attributed to the right half of the process
• Cold-chain handling flagged on the row rather than in a separate system
• Who received it, and in what capacity

Patterns, not just records

Once the data exists per delivery, the useful question becomes which patients this keeps happening to. A patient with repeated missed deliveries or failed contact attempts is not a data point; they are usually someone who is elderly, unwell, or does not answer an unknown number.

The platform now counts those events per customer and raises an alert on the profile when the count crosses a threshold, so staff see it when they open the record rather than discovering it on the third failed attempt. That is a small feature that exists only because somebody wrote down what went wrong the first time instead of resolving the ticket and moving on.