Building a chatbot for your pharmacy

Building a chatbot is the easy part: a few lines and a key. The hard part — and what decides whether it helps you or lands you in trouble — is what it talks about, what it does not, and who answers for what it says. This lesson is mostly about that.

A pharmacy chatbot cannot do three things. These are not technical nuances: they are the boundary of what can be published with a pharmacy's name on it.

Diagnose. Not even sideways: "that sounds like…" is a written diagnosis.
Recommend a prescription medicine, or compare one with another for the public.
Replace a referral. If the right answer is "see your doctor", it has to say so and stop there.

So what is it for?

For what people ask twenty times a day that is not clinical. Which is far more than it sounds:

Yes	No
Opening hours, on-call rota, where to park	"What should I take for this?"
What you need for an electronic prescription	"Can I swap ibuprofen for…?"
Whether you stock something and if it has to be ordered	"Is this serious?"
How to book a service	Interpreting a blood test
Taking the person to the tool or to the counter	Stating a dose

A good pharmacy chatbot does not answer everything: it refers well. Its job is to handle the admin and take everything else to the right person, saying clearly that this is a counter conversation. One that tries to answer everything is a liability; one that refers well saves you thirty phone calls a week.

And three things have to be said, always visible

That it is a bot. Not as a formality: somebody who thinks they are talking to the pharmacist trusts it differently, and nobody gave you that trust.
That it does not replace pharmacist advice, on the first screen and not in a footer.
That the conversation travels to a third party. What gets typed there leaves your pharmacy and reaches the model provider. That is data processing and it has to be disclosed — and it is why the bot must never ask for anyone's name, ID number or medication.

The architecture, in one line

browser → your server → the model

That middle piece is not optional. Without it the API key has to go in the browser — where it is visible in the page source — and anyone can spend it. The bill would be yours and the usage somebody else's.

On Vercel that piece is a server function: a file in api/ that takes the question, adds your instructions, calls the model with the key that lives in the environment variables, and returns the answer. It is about forty lines.

The five pieces of one that works

The system prompt: what it is and what it does NOT answer

This is the fixed text that goes ahead of every question. What actually makes it safe is not telling it what it knows: it is telling it what to do when asked something that is not its business.

You are the assistant for [Pharmacy X]. You answer ONLY about:
opening hours and on-call rota, services, whether we stock
something, and how to book.

If you are asked anything clinical — symptoms, what to take,
doses, whether a medicine is right for something, interpreting
a blood test — do NOT answer. Say exactly:
"That is one for the counter, or call us on [phone]."

Never state a dose. Never recommend a medicine. Never give an
opinion on what somebody might have. If you do not know
something about the pharmacy, say so and give the phone number.

That exit sentence — the one saying what to answer when it is not its business — is the most important line in the file. Without it the model improvises something friendly… and clinical.

A spending cap, from day one

Not because it will be expensive: because you do not control it. A link shared in a group chat, or somebody poking at it, and the bill jumps in an afternoon.

Three brakes, all of them simple:
- Per-person limit (by IP or by session): so many questions an hour.
- Global daily limit. Once hit, the bot says come back tomorrow. Better than a bill.
- Short answers. The cost is in what it writes, not in what it reads.
Cache what repeats

"What time do you open?" is always the same question. Storing the answer and serving it without calling the model removes most of a pharmacy bot's cost at a stroke, because almost everything it gets asked repeats.

And cache the failure too, with a short window. Writing to the cache only on success is what turns a bad day into one call per visit: if the model fails and you store nothing, every visitor retries and you burn the whole quota. It happened here — 166 calls and zero rows in the cache.
Store the question AND the answer

Almost everyone who builds a bot stores the question and the cost. That tells you how much you spend and what people ask, but not whether it answers well — which is the only thing that decides whether you keep it.

Here the text had been stored from the start and was displayed nowhere. Storing it and never looking is nearly the same as not storing it.
Read it all, the first month

Fifty real conversations teach you more about your pharmacy than any analysis: you will see questions you did not expect — which probably ought to be answered on the site — and you will see where your prompt falls short.

It is also where you will find out whether somebody has tried to get clinical advice out of it, and what the bot did. Nobody else can run that check.

A warning about the empty answer

A technically successful response can come back with no text inside. The server returns "fine" and the content is empty — it happens, for instance, when the model uses up its writing budget. If your code only checks whether the call failed, it will log that as a success.

Here that left one model showing 91 calls and zero failures without having produced a single sentence. A failure logged as a success never gets fixed, because nobody goes looking for it. Check that there is text, not that there was no error.

Where a message actually goes, and why the order matters

The piece that matters is the middle one, and it is not the model. Between the visitor and the AI there is a function of yours deciding three things — whether it already knows the answer, whether there is budget left, and whether that question may be answered — and only then does it call the model. Without that function in the middle, the browser would talk to the model directly: with your key in plain sight and no caps at all.

A chatbot where the browser calls the model directly is broken in two ways at once. The key travels to the browser — so it is public — and there is absolutely nothing stopping somebody sending ten thousand messages on your account. Both are fixed by the same piece: a function of yours in the middle. It is not architecture for its own sake; it is the only thing that makes this viable.

The system prompt, line by line

The system prompt is the fixed text that goes in front of every conversation. It is where you decide what the bot talks about, what it does not, and what it does when it does not know. In a pharmacy, half the work is in the prohibitions, not the capabilities.

A complete system prompt, annotated

You are the assistant for [NAME] Pharmacy, in [TOWN].

# What you DO
- Opening hours, address, phone and how to get here.
- Whether we stock a health and beauty product, and its price.
- Explaining services: dosette boxes, blood pressure checks, booking a
  consultation with a pharmacist.
- How prescriptions work in general terms.

# What you NEVER do
- No personalised health advice, no assessing symptoms, no suggesting
  what to take. If asked, refer: "that is something we look at at the
  counter with a pharmacist, or call [PHONE]".
- No discussing prescription medicines, doses, or whether something can
  be taken with something else.
- No booking, no taking payment, no confirming medicine stock.
- Do not request or accept health data. If somebody types it, do not
  repeat it and tell them not to write it here.

# How you answer
- Short: two or three sentences.
- In the language you are written to in.
- If you do not know, say so and give the phone number. Do NOT make it up.
- After anything health related: "this does not replace advice from your
  pharmacist".

Notice the prohibitions list is longer than the capabilities list, and that every prohibition comes with an EXIT. "Do not give health advice" on its own leaves the model with nothing to do, and what it does then is improvise. "Do not give it, and say exactly this instead" gives it a route — and that route happens to be the one you want: the person comes to the counter or calls.

The last line of each block is the most forgotten and the most protective. "If you do not know, say so and give the phone number. Do NOT make it up" is one sentence, and it is the difference between a bot that says "I don't know, call 0XX" and one that invents Sunday opening hours that do not exist. A model with no instruction for not knowing always answers something, because answering is what it does.

The caps: three layers, and all three are needed

A public chatbot is an API open to the internet that costs money per call. With no caps, one person with a script burns a month's quota in an afternoon — and it does not take malice: a badly written loop will do.

Layer	What it limits	What it protects you from
Per message	Length of the input and of the answer	Somebody pasting an entire book, which is billed by tokens
Per session	Messages per conversation and per minute	The looping script, which is the realistic case
Per day	A global counter for your whole site	The strange day. It is the only cap that guarantees the bill cannot run away

All three, at the top of your function

const MAX_INPUT = 800;        // characters
const MAX_PER_SESSION = 20;   // messages
const MAX_PER_DAY = 400;      // model calls, across the whole site

if (message.length > MAX_INPUT) {
  return reply('Could you ask that more briefly, please.');
}
if (await messagesInSession(sessionId) >= MAX_PER_SESSION) {
  return reply('That is plenty for today. Give us a ring on [PHONE].');
}
if (await callsToday() >= MAX_PER_DAY) {
  // ⚠️ NOT an error: a useful answer. And it tells you.
  await notifyAdmin('Chatbot daily cap reached');
  return reply('I cannot help right now. Please call us on [PHONE].');
}

All three cap messages give the phone number. That is not politeness: a bot saying "limit reached" leaves the visitor in a dead end; one that gives the number turns the cap into a referral. Hitting a cap should not cost you a customer, and there is one sentence of difference between the two.

And the admin alert on the daily cap is not optional. Without it, one strange day — or one silly attack — leaves the bot mute for hours and you find out when somebody tells you. With it, you find out the same day and can decide whether to raise the cap or look at what happened.

Caching: the difference between pennies and a bill

The questions a pharmacy bot gets repeat enormously: opening hours, bank holidays, whether you stock something, where to park. Each of those, uncached, is a paid model call. Cached, the second and every one after it is free and instant.

Cache by normalised question

function key(text) {
  return text
    .toLowerCase()
    .normalize('NFD').replace(/[\u0300-\u036f]/g, '')  // strip accents
    .replace(/[^a-z0-9 ]/g, ' ')                       // and punctuation
    .replace(/\s+/g, ' ').trim();
}

// "What time do you open?" and "what time do you open" are the SAME key.
const k = key(message);
const stored = await cache.get(k);
if (stored) return reply(stored, { from_cache: true });

const text = await callTheModel(message);
await cache.set(k, text, { hours: 24 });
return reply(text);

And two things are never cached. First, anything that depends on the moment: if the answer says "we close at 9:30 today", storing it for 24 hours is publishing false hours tomorrow. Second, any answer to a question that carried somebody's data: caching it means it could be served to somebody else. The simple rule is to cache only what would be equally true said to anybody.

Store the failures too, with a short window. If the model does not answer and you store nothing, the next visitor tries again, and the next, and on a bad afternoon that multiplies calls exactly when the service is at its worst. Storing "this failed, do not retry for twenty minutes" turns a bad afternoon into a handful of calls instead of one per visit.

What gets stored from each conversation

Stored	What for
The question and the answer	It is the only thing that says whether the bot answers well. Without the answer stored, the dashboard only counts calls
Whether it came from cache	To know whether the cache is doing anything
Model, tokens and milliseconds	Cost and speed, which is what you check weekly
A session identifier	So you can read whole conversations, not loose sentences
The IP or the email	No. None of the above needs it

Storing the answer is what almost nobody does and the only thing that lets you improve. A dashboard saying "342 conversations" does not tell you once whether the bot answers well. With answers stored, reading twenty at random each week is half an hour that tells you exactly which sentence to add to the system prompt.

And what people type can be health data without you having asked for it. "I'm diabetic, do you have test strips?" is an ordinary pharmacy sentence and it is health information sitting in a table. Hence: a written retention period, restricted access, and the bot itself saying not to type personal details. All three, not one.

Quick questions: the detail that decides whether it gets used

A chat that opens empty with a blinking cursor does not get used: nobody knows what to ask it. Three or four buttons with the real questions change usage completely — and they protect you as well, because they steer towards what the bot can actually answer.

Good	Bad
"What are today's opening hours?"	"Ask me a question"
"Do you do dosette boxes?"	"How can I help you?"
"Where can I park?"	"Ask me anything"

And they come from your data, not your intuition. Two weeks after the log exists you know what people actually ask, and it is almost never what you would have written. Swapping the buttons for the three most frequent questions is ten minutes of work and is usually the most noticeable improvement you make.

The four numbers that say whether it works

Number	What it tells you
Conversations going past one message	Whether the first answer was worth anything. A one-message conversation is somebody who left
% served from cache	How much it is saving you. If it is low, everybody asks differently — interesting in itself
Times it said "I don't know"	It is the list of what to add to the prompt, handed to you
Times it referred to the counter	The bot doing this is a SUCCESS, not a failure. It is its job

The third row is what turns this into something that improves itself. Every "I don't know" is a real question your bot could not answer and that you can teach it in one line. Half an hour a month reading that list is worth more than any model change — and it is, literally, letting your customers write the prompt.

Before you publish it

The key lives on the server and does not appear in the page source.
The prompt says what to answer when asked something clinical, with the sentence written out.
There is a per-person cap and a daily cap.
It says it is a bot, that it does not replace advice, and that the conversation goes to a third party.
I store question and answer, and I have committed to reading them the first month.
I have tried myself to get clinical advice out of it, and seen what it says.

← Previous: Analytics and Search Console Next: an app with AI Studio →