Pharmacy Automation Across Multiple Locations: What Should Be the Same at Every Site.

Ask the person who runs operations for a group of independent pharmacies what they want to know about pharmacy automation, and the question has two halves that pull against each other. Will it run the same way at every location? And does every location have to run the same way for it to work? The first half is about control. The second is about the fact that the refill queue at the store across town has never been worked quite like the one at the flagship, and nobody wants to spend a quarter forcing them to match before any software can start. Both halves deserve a straight answer, because the honest answer to both is yes.

Here is how to think about it, and how PAT (Pharmacy AI Technician) is built so that the two answers do not collide.

Why Pharmacy Automation Across Multiple Locations Is a Different Question

In a single pharmacy, the process lives in a few people's heads and the owner can see all of it from the counter. Across several locations, the process lives in several sets of heads, and each set has drifted a little. One site holds refills for a call when the last fill was recent. Another prints the label first. A third routes anything from a particular prescriber to the senior technician without asking. None of this is wrong. We wrote in July that there is no such thing as a standard refill queue, and a chain is simply that fact multiplied by the number of doors.

The drift is what makes an operations lead nervous about automation. If the software needs one process, the rollout starts with a standardization project nobody has budget for. If the software tolerates every local habit, the operation ends up with as many versions of the automation as it has sites, and the audit question gets harder rather than easier. The question underneath the question is which parts of the work are allowed to vary and which parts have to be the same, and most pharmacy automation has never been asked to answer it.

What Should Vary by Location, and What Should Not

The useful split is between the content of the work and the conduct of the work. The content is allowed to differ. The conduct should be identical.

The content can vary. Which refills wait for a call, when a label prints, which queue a finished prescription lands in, which prescribers get a second look. These are the pharmacy's own decisions, and a second location is entitled to its own version of them. What matters is that each version is written down. Where a location works a step differently, that difference belongs in the written rules, in plain English, where the operations lead can read it, rather than in the head of whoever has worked that queue longest. We covered why the rules should belong to the pharmacy rather than to a vendor, and across a chain that argument gets stronger: written rules are the first time most operations have seen their own sites' differences on one page.

The conduct should not vary. Four things should be identical at every location, whatever the local rules say.

How it behaves at the edge. When the automation meets a prescription its rules do not cover, it should do the same thing at every site: skip that one, keep the rest of the queue moving, and send the reason for review. A tool that improvises at one location and stops at another is two tools.

Who decides. Every clinical decision stays with the pharmacist at that location, by design. The automation works ahead of pharmacist verification, never around it, and that is true at the first site and the tenth.

What the record looks like. Every action logged, with the rule it applied, in the same format everywhere. We wrote about why that log is a trust feature in What Did Your Pharmacy Automation Do Last Night?. For an operations lead, its value doubles when every site's morning review reads the same way.

What it remembers. Nothing. Software that learns from one location's patients and carries that into the next location's queue is running a slightly different process at each site by design, and nobody can say exactly how. Software that starts every run from the written rules runs the same task the same way, at nine in the morning and at nine at night, at every door. We explained the privacy side of that in What Does Pharmacy Automation Remember?. The consistency side is the same mechanism seen from the operations chair.

How PAT Runs Across a Multi-Location Pharmacy

PAT (Pharmacy AI Technician) is a governed AI Technician that drives the pharmacy management system each location already uses, through the screen, over an encrypted tunnel, with no API required and nothing new installed at any pharmacy. Four things about how it is built answer the multi-location question directly.

The rules are written once, in plain English, and the pharmacy holds the pen. The first task starts with how your staff work it today, written down as the instructions you would give a new technician, and your team reads and edits that page before anything runs. Where sites differ, the difference goes on the page. Changes to task logic are included, at no additional charge, so bringing a second location's habits into the rules is a conversation rather than a project.

It is stateless, so the conduct cannot drift. PAT carries no memory between runs and retains no patient data. Every task starts from the written rules and runs the same way at every location. When a prescription falls outside the rules, it is skipped, the queue keeps moving, and the reason is sent for review with no patient information in the notification. The pharmacist at that site makes the call in the pharmacy management system, and the rules expand to cover the case, for every site.

The log reads the same everywhere. Every action PAT takes is recorded with the logic it applied, so an operations lead can review three locations' overnight runs in the same sitting and the same format. When the queue is long at one site, more than one AI Technician can work it at once; the record does not change shape.

One deployment covers the chain. For a group of pharmacies under common ownership, PAT is set up as one deployment, and the monthly minimum applies per deployment rather than per location. The model is per completed task, so a quiet site costs what ran at that site. Current figures are on the pricing page; the point for an operations lead is that adding a location is an operating decision, not a new contract.

A Practical Way to Prepare a Multi-Location Pilot

Three steps, in order, before any pilot.

Pick one workflow and ask every site to describe it. E-prescription entry or refills are the usual starting points. Have the technician who works that queue best at each location write down, in plain sentences, how they decide what to do with each prescription. Lay the pages side by side. The differences you find are the content of the work, and they are allowed.

Circle the parts that are about conduct rather than content. What happens on the prescription that does not fit, who signs off, and what gets recorded. Those should already read identically across the pages. If they do not, that is the inconsistency worth fixing first, with or without automation.

Start at the site whose page was shortest. The location with the most written-down, least improvised version of the workflow is the easiest first pilot, and its page becomes the baseline the other sites edit from. We wrote about running that pilot in its own queue, next to the team, in Run It Alongside First.

Where independent pharmacy automation stands this year, and how to evaluate any tool before committing a chain to it, is laid out in The State of Pharmacy Automation 2026.

Frequently Asked Questions

Does PAT run the same way at every pharmacy location?

Yes, in the ways that matter for control. PAT is stateless, so every task starts from the same written rules and runs the same way at every site, with the same behavior when a prescription falls outside the rules and the same log format everywhere. The local routing decisions in those rules can differ by location, and the differences are written down in plain English.

Do all my locations have to work their refill queue the same way before we start?

No. The task logic starts with how each site's staff work the queue today, written in plain English and edited by your team. Where a location does a step differently, that difference goes into the written rules rather than being forced out before a pilot.

Is PAT priced per location?

For pharmacies under common ownership, PAT is set up as one deployment and the monthly minimum applies per deployment, not per location. Pricing is per completed task, so each site costs what ran there. Current figures are on the pricing page at pharmacy.sonet.io/pricing.

Does the pharmacist at each location still make every clinical decision?

Yes. PAT works ahead of pharmacist verification, never around it, at every site. When it meets a prescription its rules do not cover, it skips that one, keeps the queue moving, and sends the reason for review with no patient information in the notification. The pharmacist at that location decides in the pharmacy management system.

‍