Delivery Credit
Prototype purchasing credit through the pharmacy website, viewing the balance, topping up and receiving confirmation. Agree charges, refunds, accounting and family permissions before production.
A personal proposal for discussion
These suggestions follow feedback from drivers and the pharmacy and draw on my delivery-driving experience and web development skills. They are offered for discussion with PharmDel’s owners and the Mossley pharmacy team. The pharmacist and pharmacy owner would need to review and approve any proposal before it could proceed; no partnership, pilot or development plan has been agreed.
Complement the existing platformPharmDel remains authoritative for its jobs and delivery status.
Minimum route access firstUse stable stops and versioned snapshots through an agreed interface.
Separate changes from suggestionsExport access alone cannot update PharmDel records.
Recommended direction · 18 October 2026
Delivery Credit, then a shared Assist phase.
A suggested development sequence, not a claim that these services are already implemented. Build and test with fictional data before an authorised pilot.
Patient Assist & Driver Assist
Develop the two connected assistants together in one phase: accessible patient arrival updates, acknowledgements and verified charge information, alongside voice-led round help, relevant patient replies, package reminders, returns and operational summaries. Explore the smallest useful shared workflow in a fictional sandbox, then discuss a bounded pilot with the pharmacy and PharmDel.
PharmDel / Titan adapters
Emulate round, status, next-delivery, ETA, instruction and charge events with fictional records. Validate the supplied protocol and exact permissions. Partner-approved production connectivity follows demonstrated behaviour.
Credit meets Patient Assist
Answer “Do I owe anything today?” from authoritative payment records. Measure acknowledgement, doorstep waiting, failed attempts and usability against a baseline. Benefits remain hypotheses to test.
Optional Patient App
Retain completed work for richer prescription information, history, payment, nominated collectors, preferences and pharmacy messages. The app is optional; web assistance comes first.
Suggested sequence: Delivery Credit → Patient Assist & Driver Assist together. Sandbox work supports both Assist services from the start. Pilot and production integration require agreed pharmacy policy and partner permissions.
Complement existing systems
One operational source. Two helpful assistants.
PharmDel manages the delivery operation. Patient Assist prepares and informs the patient. Driver Assist helps the driver through the round. The pharmacy website provides the patient-facing service and commercial layer.
Titan PWR / PMRAuthorised pharmacy-system data · capabilities to validate
PharmDelAuthoritative delivery round and operational status
PDS integration layerFictional sandbox first · clearly defined, replaceable adapters
Patient Assist
ETA • voice-capable help • acknowledgement • charges • Delivery Credit
Driver Assist
Voice-led round help • relevant patient replies • reminders • operational insights
Exchange only relevant delivery events. A separately authorised Titan adapter may support non-round services; this diagram does not confirm any production data access. The optional Patient App can later reuse these services.
Minimum necessary data in; minimum necessary operational information back. AI must never invent, waive or alter a charge, change delivery policy or treat a patient acknowledgement as proof of handover.
Shared Assist experiment
Help the patient prepare for the door.
Start with a fictional pharmacy, patient, delivery and charge. A sandbox can test the patient and driver experiences together without a live connection.
Arrival estimated
An authorised or simulated next-delivery event estimates arrival in 3 minutes. Only enabled patients receive the update.
Respond naturally
“I’m coming to the door”, “I need a little longer”, “I won’t be available”, or “Do I have anything to pay?” Text and touch remain available.
Share the useful detail
“Patient acknowledged — may need additional time to reach the door.” Routine conversation stays with Patient Assist; exceptions go to pharmacy staff.
Join Driver Assist
In the same proposed phase, Driver Assist would consume the shared contract and trigger eligible patient updates. Completion still comes from the authoritative delivery system.
Fictional charge example: “Your delivery charge is £1.00. You have £4.00 Delivery Credit available.” Display only verified balances and policy amounts; missing data must be reported as unavailable. This page processes no payments.
The proposed division of work
A proposed patient and driver assistance layer alongside PharmDel.
PDS / pharmacy website and Assist services
- Delivery Credit through the pharmacy website, with approved charging and account rules.
- Patient Assist, in the shared Assist phase: accessible arrival updates, routine questions and acknowledgements.
- Repeat request acknowledgement, verified history, collection and delivery updates.
- Early split-supply preferences, patient replies and an accessible website.
- Driver Assist, in the same phase: round-aware voice help and relevant patient responses, subject to agreed interfaces.
- A shared core adapted to multiple pharmacies with isolated records.
PharmDel collaboration questions
Respect PharmDel’s existing delivery platform and confirm the supported scope of rounds, proof of delivery, optimisation, notifications, tracking, fleet, mileage, reporting and PMR integration.
- Is a scoped optimised-route export/API available?
- How are stop, job, package and household identities represented?
- Can updates be requested, acknowledged and reconciled safely?
- What delivery events can be exposed to an authorised patient service?
- Would a companion interface, deep link or embedded view suit the platform better?
Interface concepts
Show the connection, not a promise.
Illustrative screens using fictional route and patient references. No API calls, real locations or live updates occur here.
Proposed interoperable workflow
PDS / PharmDel · Fictional interface concept
A small starting point
Read the round. Agree every change channel.
“Grab the route” starts the discussion, but patient holds, shared journeys and delays require clear ownership and reconciliation.
| Interface proposal | Minimum useful information | Boundary to agree |
|---|---|---|
| Authorised route snapshot | Pharmacy/driver scope, route ID/version, stable stop/job references, sequence, approved navigation point, package count, relevant windows/policy flags. | Read-only starting scope. Confirm access, refresh, expiry, location necessity and permitted use. |
| Delivery events | Approved dispatch, status, delay and outcome events with time, source and stable references. | Patient notifications must be based on authorised data. An ETA is an estimate, not handover evidence. |
| Hold or combine request | Patient intent linked to their own prescription/parts. Pharmacy approval, request ID and expected route version. | Optional separate write/event channel. Reject stale/conflicting changes; return acknowledgement. A read export does not grant mutation access. |
| Reconciliation | Versioned refresh, applied/rejected result and unresolved changes visible to staff/driver. | Repeat requests must not duplicate actions. Avoid silent divergence between overlay and source round. |
| Handover evidence | Authorised outcome reference and suitable photo/evidence access if supported. | Agree evidence owner, storage, retention and viewer permissions; a photo alone cannot relax policy. |
An example worth testing together
“Wait for part 2” after the vehicle leaves.
A late request arrives
The patient asks for one combined handover. The app records intent and acknowledges receipt, not approval.
Review the hold
Staff check urgency, policy and part readiness. Other household members’ deliveries remain separate.
Apply or reject
Through an agreed change mechanism, check the current version, acknowledge the decision and refresh the round.
Confirm the update
Review when safely stopped. Preserve custody/return tracking for the loaded part; update affected ETAs.
If no route-change API exists, start with read-only demonstration and a documented pharmacy/driver reconciliation process. Do not pretend a local hidden stop has been removed from PharmDel.
Integration options to discuss
Choose the least disruptive fit.
Round-aware assistant
Read-only scoped route, reminders and notes. PharmDel remains the driver’s delivery platform. Minimal interface requirement first.
Deep link or embedded view
Launch patient-response or assistance views from an existing driver flow if the platform supports and approves it. Identity boundaries need explicit agreement.
One pharmacy app workspace
Restricted driver login, checklist and live replies. Requires enough agreed route/status interoperability to avoid duplicated operational authority.
Patient value
Before the doorstep or counter
Let patients request repeats, understand split supply, prepare for arrival and view verified history. Voice/status reading is a future accessibility goal alongside touch and text.
Collection can use an authorised reference or QR/NFC and nominated-carer checks, with a staff-assisted fallback. The focus remains reliable customer delivery and collection.
Data and evidence boundaries
Round locations, references and notes can identify people. A live pilot needs agreed roles, access scopes, retention and data-sharing arrangements. Avoid broad clinical access merely for navigation.
Distinguish measured, calculated, estimated and demo metrics. No savings or break-even claim is presented as proven.
First foundation · Delivery Credit
A clear patient account for delivery costs.
Propose nopCommerce multi-store for pharmacy shops, with pharmacy-specific loyalty rules. Prepaid delivery credit would be a separate ledger from shop reward points.
Approved top-up
Use a confirmed payment result, show the balance and issue a receipt. Define refunds and insufficient-credit handling.
QR/NFC confirmation
Identify the authorised delivery transaction and confirm the agreed amount. Repeated scans/taps return the same result without another deduction.
PharmDel boundary
Agree whether and how charge/receipt status is exchanged. A route interface does not imply payment capabilities; drivers do not invent charges or waivers.
Optional automatic deduction: With prior patient agreement and an explicit pharmacy charging policy, an authoritative delivery-confirmed event could deduct prepaid delivery credit once and issue a receipt. Duplicate events or QR/NFC confirmations must return the existing transaction, not charge again. Agree the source event and fee/waiver/split-supply rules; a route snapshot alone cannot authorise a financial action.
The next conversation
Confirm feasibility before implementation.
What interfaces exist, which option fits PharmDel, and what would a bounded fictional proof need to show?
1 · Sandbox contract
Validate the supplied protocol, fictional round events, identity and minimum data. Confirm exact PharmDel/Titan permissions and supported capabilities.
2 · Connected Assist proof
Prove the arrival message, acknowledgement, extra-time response and verified charge using fictional events. Include missing data, stale events and duplicate notification handling. Demonstrate Driver Assist alongside Patient Assist in the same phase.
3 · Pilot, measure, integrate
Agree participants, safety/data arrangements, baseline measures and support. Proceed only after evidence and partner approval.
PharmDel feedback
Share an idea.
Tell us which boundary, interface or driver experience would be practical.