One visit, every bag accounted for
Review multiple prescriptions for one patient and different patients at the same address, with clear bag reminders and separate outcomes.
For PharmDel’s owner · Review edition · 10 October 2026Build on PharmDel.
Build on PharmDel.
Make every package count.
Practical ideas for multi-package deliveries, driver assistance and a clearer connection between pharmacy, patient and prescription round—based on Jon’s experience as a Mossley delivery driver.
A timely discussion, building on your updates
Jon reports seeing a WhatsApp update from PharmDel’s owner showing driver-side changes, including “package delivered”. The demonstration has not been reviewed here. Please identify which ideas below are already supported, overlap your roadmap or would add something useful. This proposal does not imply those capabilities are missing.
Refine the remaining round
Multiple priorities, timed stops, patient replies and time at the door, with driver approval and reliable reconciliation.
A clear handover in both directions
Staff instructions reach the driver; recorded outcomes, held packages and returns reach the pharmacy through an agreed process.
Interactive proposal · fictional example
One address. Two people. Three bags.
Group the visit for convenience while keeping recipient identities, package counts and outcomes separate. This illustrates an idea, not PharmDel’s actual screens or scanning behaviour.
Proposed package reminder
Stop DEMO-19
3 bags · 2 recipients
Fictional address · confirmed group from loading review
Demo recipient A · 2 bagsDemo recipient B · 1 bag
Try selecting only one bag to see how the concept flags the others. Nothing is scanned or recorded in PharmDel.
Ideas to explore with your team
- Confirm the full address group and bag count while loading.
- Remind the driver of all associated bags at the stop.
- Make outstanding bags visible before treating the group as complete.
- Record different recipients’ outcomes separately.
- Handle a partial handover, hold or return without marking every package delivered.
Ask whether existing package-delivered updates already support these checks and how Multi currently relates a scan to associated bags.
Checks must fit actual package records
The mockup uses one checkbox per fictional bag to make the idea clear. Whether to use scans, a confirmation or existing grouped records is a joint design decision. A single scan must not be interpreted here as proof that every associated bag was handed over.
Pharmacy, patient and prescription delivery
Connect the round without exposing medicine details.
| Stage | Pharmacy / patient side | Driver side | Agreement needed |
|---|---|---|---|
| Preparation & dispatch | Staff retain prescription preparation, supply and release decisions. Provide authorised delivery work and special instructions. | Load the authorised round; review priorities, surgery paperwork and household bag groups. | What data exists, who supplies it and when delivery choices can become available. |
| Patient preferences | Patient requests a suggested/custom window, a hold, available items now, or authorised household combination. | Receive delivery instructions only; assess the remaining round and confirm a proposed change by voice. | Partial-supply information is not currently passed to Jon unless staff/patient relays it. Do not invent that data or disclose medicine details. |
| Progress & handover | Patient sees an estimated window and opted-in app/text updates. Pharmacy receives agreed delivery outcomes. | Keep PharmDel as the main record; account for each recipient/package under its agreed workflow. | What “package delivered” means, event availability, handover evidence and separate recipient outcomes. |
| Hold / unsuccessful delivery | Patient sees an acknowledged decision; pharmacy knows a return is expected. | Skip the agreed stop, retain the package on the return checklist and record the appropriate PharmDel outcome. | Distinguish return planned from physically handed back to pharmacy; confirm exact status names and who acknowledges receipt. |
| Collection | The separate patient proposal explores staff-ready status, arrival notice and an authorised collection code. | Do not confuse a pharmacy collection with driver-delivered status. | Current collection system and any role for PharmDel remain staff/team discovery questions. |
Keep the pharmacy’s existing systems authoritative
The patient and driver experiences are proposed convenience layers. No replacement for pharmacy prescription software is assumed. Share only agreed information and approved events, with ownership, permissions and responsibilities explicit.
Two possible pathsA · Jon’s preferred first pilot B · Developed with its team
Agree the connection before a pilot.
Companion Driver Assist
A separate dash-mounted iPhone or Android shows the next three deliveries, bag reminders, priorities, patient responses and checklists.
- Receive the day’s round through an agreed interface.
- Propose changes; driver confirms by voice.
- Reconcile changes and delivery progress with PharmDel.
- Continue using PharmDel for the main delivery record.
No-touch driver interaction is a design goal. The clickable proposal simulates voice; it does not implement it.
Native PharmDel enhancement
Explore the same assistance inside the existing round experience, rather than maintaining a second-device companion.
- Before optimisation: multiple priorities, time windows and household/package requirements.
- After optimisation: review, reminders and approved refinements.
- During the round: authorised patient responses, delays and reconciled changes.
- Round end: returns and practical handover checks.
Scope, ownership and delivery approach would be agreed with PharmDel.
Reported current use
Useful optimisation, informed by experience.
Load and optimise
Jon reports scanning delivery orders into the driver app, then choosing route optimisation. He finds this a useful starting point for the round.
Local refinements
School closing times, local knowledge and passing nearby outstanding stops can justify changes. Current know-how is mostly passed on verbally.
“Make first”
Jon reports an option to reoptimise the round or move one order first while keeping the remainder unchanged. Exact labels and sequence need product-team confirmation.
These are driver-reported behaviours, not verified PharmDel documentation or a claim that the current optimiser is deficient.
A concrete late-response scenario
A patient replies after departure.
| Step | Proposed behaviour | Discovery needed |
|---|---|---|
| 11:00 · round starts | Assistant receives the agreed round, priorities and time windows. | Route identity, stop references and supported export/interface. |
| 12:30 · patient replies | Request to hold, combine, or change availability is assessed against remaining stops. | Authorised message source, permissions and household boundaries. |
| Driver decides | Assistant explains the proposed change. Driver confirms by voice. | Reliable speech confirmation, error handling and change ownership. |
| Reconcile the change | Update through the agreed interface, or a defined manual PharmDel action. Do not silently replace its source route. | Versioning, acknowledgement, conflicts, retries and disconnected operation. |
| Update the patient | Send the changed arrival window only after approval and the agreed reconciliation step. | Completion/progress events and notification timing. |
| Hold / return | Skip the stop in the assistant plan; retain the package on the pharmacy-return checklist. Record returned/failed in PharmDel under the agreed workflow. | Exact status names; distinguish patient-requested hold from unsuccessful handover. |
More realistic timing. Fewer omissions.
Time at the door
Estimate travel plus actual delivery time. Use arrival/completion signals, average stop duration and editable per-address extra-time allowances.
Voice notes explain extra interaction without exposing medicine details or confidential conversations.
All bags at the stop
Jon reports existing counts generally group multiple prescriptions for one person, but can miss different people at the same address.
Review address groups while loading. Remind the driver of all confirmed bags; preserve each person’s separate outcome.
Practical checklists
Before departure: pen and backup, missed-delivery cards, float, surgery paperwork and household checks.
Afterwards: all bags accounted for, returns and collected prescriptions handed in, fuel range, vehicle condition and incidents. Report to the pharmacy.
Patient connection
Could authorised preparation/hold/combined-delivery preferences and patient responses feed into PharmDel? Could staff relay phone requests through PharmDel? Initial standalone staff requests remain phone calls; no extra staff app is required for that case.
Questions for a joint discussion
What would make this workable?
Interface and ownership
- Which round and event interfaces exist or could be agreed?
- Which system owns ordering, ETAs and each delivery outcome?
- What can a companion change, and who approves it?
- What licensing, support and data permissions are needed?
Scope and testing
- Which path best fits PharmDel’s roadmap?
- Can arrival/completion events support stop-time metrics?
- How should late replies, offline operation and conflicting updates behave?
- Which fictional scenarios should precede a bounded live pilot?