What Does a Pharmacy Automation Pilot Commit You To? Judge It by What It Costs to Stop

After the demo, the question independent pharmacy owners ask about a pharmacy automation pilot is rarely about the technology. It is some version of: what am I signing up for? The demo answered what the software does. It did not answer how long you are on the hook, what gets installed, what happens to your data, and what it takes to walk away if the first weeks do not go the way the demo did. Most owners have signed something in the past that was easy to start and expensive to leave, and they are not going to do it again for a queue of refills.

So here is a different way to judge a pilot: by what it costs to stop. A pilot that is cheap to end is one you can start without a committee. Here is what that means in practice and how a PAT (Pharmacy AI Technician) pilot is set up against that test.

Why the Pharmacy Automation Pilot Question Comes Before the Workflow Question

Owners tend to ask about the commitment before they ask about the workflow. They are right to. The workflow question has a clean answer that we have written about more than once: start with the work that repeats, run it in its own queue next to the team, and expand on evidence. We covered the mechanics in Run It Alongside First and the expansion decision in After the Pilot.

The commitment question is harder because the answer is usually spread across a proposal, a contract, and a conversation, and the pieces do not always agree. An owner is trying to size one risk: if this does not work for my pharmacy, what have I lost? Time, money, a system that now has something installed in it, patient data that now sits somewhere new, and a set of rules that belong to somebody else. Each of those is a separate cost to stop, and a pilot should be judged on all five.

The Exit Test: Five Things a Pharmacy Automation Pilot Should Cost Nothing to Stop

Time. The first weeks of any pilot are the team's time: reading a log, correcting a rule, answering a question about a prescription the automation set aside. That cost is real and worth paying once. What a pilot should not cost is a long runway before you are allowed to decide. If the terms require months before you can judge, the vendor is asking you to carry the risk of the evaluation.

Money. A pilot should be free for long enough to see the work run, and after that it should be priced for the work that ran. Per completed task means a quiet week costs what ran that week. We wrote about how that model works month to month in What Pharmacy Automation Actually Costs Per Month. The commitment question is simpler: when the free period ends, are you signing for a year or for a month?

Your systems. The most expensive pilots to leave are the ones that put something inside the pharmacy: a server, an installed client, a change to the pharmacy management system itself. Removing it is a project. The project is a reason not to start. A pilot that installs nothing costs nothing to uninstall.

Your data. If the automation learns from your patients and keeps what it learned, then stopping means asking for it back. If it retains nothing between runs, there is nothing to ask for. We explained the mechanism in What Does Pharmacy Automation Remember?. For the exit test, the point is that stateless automation has no exit cost on the data side.

Your rules. The task logic is the pharmacy's own process, written down. If it is written in plain English and your team can read and edit it, then it is yours whether the pilot continues or not, and you have a better-documented workflow than you started with. If it lives in a vendor's configuration, you leave it behind. We made the case for the pharmacy holding the pen in Who Owns the Rules?.

How a PAT Pilot Is Set Up

PAT (Pharmacy AI Technician) is a governed AI Technician that drives your existing pharmacy management system through the screen, over an encrypted tunnel, with no API required and nothing installed at the pharmacy. The pilot is built to pass the exit test on every line.

The first two weeks are free, with no contractual obligation. A pilot typically covers one location and one or two workflows, usually e-prescription entry or refills. That is long enough to see the work run in its own queue, read the log each morning, and let your most skeptical technician look for mistakes.

After the free period, the agreement is month to month, with thirty days' notice. Pricing is per completed task. You pay the greater of your per-task total or the monthly minimum, never both. The current figures are on the pricing page, in one place, so there is never a second version of the price.

Nothing is installed at the pharmacy. Sonet deploys PAT over a secure connection to the pharmacy management system you already use. No new hardware, no change to the system, no IT project on your side. Stopping means the connection ends.

Nothing is retained. PAT carries no memory between runs and keeps no patient data. Every task starts from the written rules and runs the same way each time.

The rules are yours. The task logic is written in plain English from how your staff work the queue today, your team reads and edits it before anything runs, and changes to it are included at no charge. If the pilot ends, the page is still yours.

The pharmacist stays in the loop. Every clinical decision stays with the pharmacist, by design, from the first test script onward. When PAT meets a prescription its rules do not cover, it skips that one, keeps the queue moving, and sends the reason for review. Every action is logged with the logic it applied.

Three Decisions to Make Before the Pilot Starts

Decide what "stop" looks like. Write down, before anything runs, the result that would make you end the pilot and the result that would make you continue. Most owners find this harder than it sounds. It is the single most useful thing to have on paper when the two weeks are up.

Name the person who reads the log. One person, every morning, for the length of the pilot. The most skeptical technician on staff is the right choice, for the reasons we gave in Run It Alongside First. If nobody owns the reading, the pilot produces a record nobody evaluates.

Pick the workflow you would least mind losing to a bad week. The first workflow should be one where a skipped prescription is an inconvenience, never a risk. That is usually refills or e-prescription entry, which is why PAT pilots start there.

A side-by-side of pharmacy automation approaches, and what to weigh before committing to any of them, is in the Pharmacy Automation Comparison Guide.

Frequently Asked Questions

How long does a PAT pilot last, and what does it cost?

The first two weeks are free, with no contractual obligation. After that, the agreement is month to month with thirty days' notice. Pricing is per completed task. Current figures are on the pricing page at pharmacy.sonet.io/pricing.

What does a pharmacy automation pilot usually cover?

Typically one location and one or two workflows, most often e-prescription entry or refills. PAT works those in its own queue inside your pharmacy management system, so your team can judge it on its own record.

What has to be installed at the pharmacy for the pilot?

Nothing. PAT drives your existing pharmacy management system through the screen over an encrypted tunnel, deployed by Sonet. There is no new hardware, no change to the system, and no IT project on your side.

If we stop the pilot, what happens to our data and our rules?

PAT retains no patient data between runs, so there is nothing to return. The task logic is written in plain English and belongs to the pharmacy, so you keep a documented workflow whether the pilot continues or not.