Export your CSV and ask it what happened last month

1. Strip what must not leave the pharmacy

   This is the part you never skip, and you do it by looking at the file, not by trusting that the export was clean. Open the CSV and go column by column:

   What has to go

   • Customer name and surname, in any column.
   • ID number, health card number, prescription number.
   • Phone, address, email.
   • Customer or loyalty number. It looks anonymous and is not: it is an identifier that lets you get back to the person.
   • Prescriber name or clinic.
   • The "notes" column, which is where somebody typed "the lady with the hip" two years ago.

   If you are unsure about a column, delete it. Answering "what sold less in May" needs none of those six.

2. Upload it and ask the way you would ask a person

   Drag the file into the chat window. The model reads it. And now comes the part your software does not do: you ask in plain language.

   The prompt below does three things at once, and all three matter: it tells the model what the file is (otherwise it guesses what each column means), it tells it what it does not know — the bank holidays, the campaign you ran, somebody being off sick — and it asks it to separate what it sees from what it assumes. That last instruction is what turns a pretty answer into a usable one.

   Attached are the sales for May 2026 of a community pharmacy in
   Spain. Columns: date, product code, description, units, amount in euros.
   One row per sale line.
   
   CONTEXT YOU CANNOT KNOW:
   - That month had 2 local bank holidays, on the 15th and the 30th
   - We were one person short for 10 days
   - We ran no campaign
   
   WHAT I WANT:
   1. The 10 products with the highest revenue and the 10 with most units.
   2. Which weekdays sell most and which least.
   3. Products that appear early in the month and then disappear.
   4. Anything that strikes you that I did not ask about.
   
   RULES:
   - Clearly separate WHAT YOU SEE IN THE DATA from WHAT YOU ASSUME. Tag every
     statement [DATA] or [HYPOTHESIS].
   - If a number looks odd to you, say so instead of explaining it away.
   - No management advice yet. Facts first.

3. Check TWO numbers by hand before believing the rest

   You do not need to check everything — that would defeat the point. You need two, chosen like this: one easy and one hard.

   The easy one is the month total: sum the amount column in Excel and compare. If it does not match to the cent, the model misread the file or dropped rows, and everything else is worthless.

   The hard one is one of the ten products in the ranking: filter that code in Excel and sum its units. If that matches and the total matches, the rest holds up reasonably.

   This is not distrust: a model adding thousands of rows can get it wrong, and the difference between a useful report and a dangerous one is these two minutes.

4. Now let it think — and push back

   With the facts checked, the second question is the one worth money. And the best way to ask it is not "what do you recommend?", which gives a generic list, but asking it to argue two opposite explanations.

   From the above, take the finding you think matters most.
   
   Give me TWO possible and opposing explanations of why it happened.
   For each one:
   - what else would have to be true if that explanation were the right one
   - which specific piece of data from my software would confirm or rule it out
   
   Do not pick one. Tell me what I need to look at to decide.

   The answer to this is no longer a report: it is a list of two or three things you can look up tomorrow in your own software. That is what you were after.

A full example, and what is wrong with it

A real month from a neighbourhood pharmacy, with the step 3 prompt and its context in place. This is the part of the report that matters.

And now, what is wrong with that reply:

1. The [DATA] tag on the holidays is wrong. That takings fall on those days is data, yes. But that the fall is "expected" is a judgement, and it is tagged as a hypothesis below — correct. What fails is the line above: €190 on a holiday when the pharmacy was closed is not a dip, it is an on-call shift. The model does not know whether you opened, and has treated it as an ordinary slow day.
2. The 34 items that "disappear" are the real finding. And it is correctly split: the fact is data and the explanation is a hypothesis. That is exactly what the prompt bought you, and here you see why — you can act on the finding without buying the explanation. Tomorrow you filter those 34 in your software and find out whether it was a stock-out or simply nothing due.
3. And Saturdays versus Tuesdays is not a like-for-like. The gap looks enormous until you remember Saturday is four and a half hours and Tuesday is eleven. Per hour open, Saturday takes more. The model does not have your opening hours and compared whole days; the conclusion you would draw is exactly the opposite of the truth.
4. That is the pattern of the whole case: what you do not give it, it treats as uniform. Opening hours, holidays, summer closure, the week you were a person down. The "context you cannot know" block in the prompt exists for this, and here you see that whatever you forget to put there comes back as a false finding — complete with its [DATA] tag.

Two of the five findings are useless, and both for the same reason: missing context only you have. Neither is a calculation error.

Add your hours by day and whether you opened on the holidays, and ask again. It takes ten seconds and changes the whole report — which is the difference between this case and uploading a CSV to see what comes out.

And if your pharmacy is not like that

When it does not work first time