Pharmacy landing page: refills that stall

A local visitor has a medicine that runs out on Friday. They open the pharmacy's landing page on their phone, see a large refill button, and tap it. The form asks for a prescription number, a date of birth and the name of the prescriber. The prescription number is printed on the label, but the label is in a kitchen drawer across town. The visitor tries to remember it, guesses, and gets an error that does not say which field is wrong.

• Tap refill, then transfer. Do they lead to different forms with different fields?
• Read every required field aloud. Is each one printed on a bottle label or a receipt?
• Type a wrong prescription number. Does the error name the field that failed?
• Start a transfer. Does it ask for the old pharmacy's name and phone number?
• Does the request need a code sent by text? Note the screen where a visitor without a phone stops.

Pharmacy pages sometimes put one large button at the top. Refill and transfer both lead to a form, but they need different information. A refill needs the prescription number and the prescriber's name. A transfer needs the name and phone number of the pharmacy that holds the prescription now, plus the medicine and its strength. A visitor who has a bottle and wants to move it has to read the form to learn which path they are on, and the form may not explain that before the first field. The check is simple: tap each button in turn and note which fields appear. If the two lists match, a visitor is guessing which button is theirs.

Landing page testing

Some pharmacy logins send a one time code by text message before a request can be sent. Visitors in Mimiq have a working email inbox, so an email code arrives, but they cannot receive a text. If your site sends the code only by text, the simulated visitor stops on the code screen, and the report shows that screen as the step where it stopped. That is a limit of the test and not proof that a real patient would stop there, because a real patient has a phone. It is still worth checking. Ask whether the page offers an email option, and whether the code screen says where the code was sent and offers a resend link.

Look at that screen on a phone, with the number typed in the form. If the number field accepts a landline or a country code the form does not expect, the code never arrives, and the visitor sees no error to explain it. Write down the exact words the screen shows when nothing arrives in the time you would accept. A patient who waited and then got no message will read that silence as a broken pharmacy, not a slow one.

Chains can send the visitor through a store picker before the form. The page asks for a town or a ZIP code, then shows one branch. If that branch does not accept online requests, the visitor fills in the whole form and is then told to call the branch. A visitor who lives between two stores may pick the nearer one and never see the store that takes requests.

Test it with two addresses on either side of a branch boundary, and with the branch you know takes requests. The report shows which store the visitor picked and what the form said at the end. If the answer changes between the two addresses, the picker is the cause, and the fix belongs on the picker, not on the form. A form that works for one branch and fails for another looks healthy on your own computer, because you usually test with the store you know.

The first run finds whichever stopped the visitor: the prescription number field, the text code or the store picker. Branches open, close and change which store takes requests, and a refill form gets edited between seasons. Rerun the refill visitor after each change, then the transfer visitor, so both paths get checked.