Case study
Repeat prescriptions for a community pharmacy
A web application for a community pharmacy, built around a free repeat medication service patients can use without ringing the counter.
Supernet Pharmacy

The challenge
Repeat prescriptions are the highest-volume, lowest-variation task a community pharmacy handles, and traditionally they arrive by telephone. Every request occupies a member of staff who is standing at a counter with patients in front of them, and the details get read aloud and written down, which is the least reliable way to move a medication name between two people.
The volume is the problem rather than the difficulty. Each call is a minute or two. Multiplied across a week it becomes a meaningful part of a small team, spent on a task with a clear rule and no judgment in it, while the patients who need actual pharmacist attention wait.
The solution
A pharmacy site built around the repeat medication service rather than treating it as one page among many. A patient submits a request in their own time, in writing, without occupying anyone at the counter, and the details arrive in a form that does not depend on somebody hearing them correctly.
The rest of the site does what a local pharmacy site has to do: state the services offered, make the phone number impossible to miss for the cases that genuinely need a person, and stay legible on a phone, since that is where most of this traffic comes from.
What we delivered
- from brief to launch
- 5 weeks
- repeat medication, off the telephone
- Written requests
- where most pharmacy traffic arrives
- Mobile first
What this kind of build typically achieves
A typical community pharmacy dispenses somewhere between 100 and 200 prescriptions a day, and that volume can double through a winter surge, according to published guidance on pharmacy workload. Repeat medication is the largest and most repetitive slice of it.
The safety argument is the stronger one. Many GP practices refuse repeat requests by telephone outright, specifically because reading a medication name aloud invites error, and because every such call occupies a line somebody else may need urgently. A written request removes both problems at once.
Moving those requests into writing is therefore not only a time saving. It takes the highest-volume task in the building and makes it both auditable and safer, which is the same reasoning we apply to any process automation.
Figures above describe the sector, not this client. We publish a client’s own numbers only when they have measured and shared them.
What this involved
Tell us what is
not working.
Describe the problem in your own words. We will tell you what we would build, what it would cost, and whether you need us at all.