Reading time: about 11 minutes
Sharing out holidays looks like a calendar problem and is mostly a problem of criteria: who chooses first, what happens with people who have children, how much can be split. Once the criteria are fixed, the calendar part — making sure there are always enough people — is exactly what a model solves well and quickly. This case separates the two: you decide the criteria with the team; AI proposes schedules that meet them, and you check that the counter is never short.
Step by step
-
Write the rule before the schedule
The yearly argument does not come from the calendar; it comes from there being no rule, or a rule only one person knows. Before sharing anything out, write down with the team how it is decided: for example, rotation — whoever had August last year chooses last this year — or fortnights that alternate, or a combination.
The rule also needs to say how many consecutive days are guaranteed in summer at minimum, what happens for people with school-age children if you decide to give them some priority, and how ties are broken. Whatever you decide is fine as long as it is written down beforehand and applied to everyone equally.
And remember the legal notice period: Spanish employment law says each person must know their dates at least two months before they start. A schedule closed in June for July is already late.
-
Turn the problem into letters and numbers
The chat does not need to know who is who. It needs to know how many people there are, what grade each one is if that matters for coverage (for example, that there must always be a pharmacist), how many days each has and the minimum number of people needed each day.
So you give each person a letter and note, for yourself, which letter is whom. Preferences are written as dates, without the reason: "C prefers 1-15 August", not "C needs the first fortnight because her ex has the children in the second". You know the reason, and it counts when applying the rule; the model does not need it to fit dates together.
This step is the one that protects most, and the one most people skip because "it is only the calendar". A calendar with names and personal reasons is a document containing family and health information about your team.
-
Ask for schedules that meet the rule and the coverage
Now the model does what it does best with this problem: trying combinations. Ask for several, not one, so you have a choice and so it is obvious the schedule was not "decided by the machine".
I need to share out the summer holidays for a pharmacy. People: A (pharmacist), B (pharmacist), C, D and E (technicians). Each has 30 calendar days a year; in summer (from 1 July to 15 September) each takes 15 consecutive days. Minimum cover EVERY day in that period: - at least 1 pharmacist, - at least 3 people in total. Allocation rule: whoever had August last year (B and D) chooses last; the rest by seniority: A, C, E. Preferences: A: 1-15 August · C: 16-31 August · E: July, either fortnight. Give me 3 possible schedules in a table by fortnight. For each one, check the minimum cover day by day and tell me if it fails on any day. If there is no way to meet everything, say so and say which constraint makes it impossible.
The last line matters. With tight constraints there is sometimes no solution, and a model without that instruction tends to give you a schedule that "almost" works without telling you where it does not.
-
Check the coverage yourself, day by day
The coverage check the model does is useful and not reliable. It goes wrong most at the edges of fortnights — the 15th and 16th, the 31st and the 1st — in 31-day months, and on days when the pharmacy has different opening hours. That is why you repeat the check yourself.
The quickest way is to enter the chosen schedule into your rota tool as each person’s holidays and let it build the July, August and September rotas. If any shift is left without enough people or without a pharmacist, it shows you the day. It is exactly the check the chat does from memory and the rota tool does by counting.
If a gap appears, do not force the schedule: go back to step 3 with the failing constraint written in, or check whether the minimum cover you asked for is realistic with five people each taking fifteen days in two and a half months.
-
Publish the schedule with the rule next to it
Once you have a schedule that meets the rule and the coverage, it is published to the whole team together with the rule. That is what prevents the argument: nobody can say it was done by eye if the rule was written down and the schedule follows it.
Write a short notice for the pharmacy team with the summer holiday schedule. Include: the rule that was applied (in one sentence), the table by fortnight with the letters replaced by the names, which I will add myself, and one line saying that next year the rule means the people who chose last this year choose first. Neutral tone. No more than 10 lines.
You add the names yourself in the final document, outside the chat. And keep this year’s schedule: it is the information that makes next year’s rotation work, and in twelve months nobody will remember for certain who had August.
A full example, and what is wrong with it
This is what a model replied when asked to "share out my pharmacy’s summer holidays among 5 people, always with at least 3 in", given real names and preferences with their reasons, without the allocation rule or the requirement for a pharmacist. It is shortened and the names have been changed.
"Proposed schedule (22 working days per person):
· Laura (pharmacist): 1-22 July · Pedro (pharmacist): 23 July-13 August · Carmen: 1-22 August, as she has her children on those dates · Javier: 14 August-4 September · Sofia: 5-26 September.
This way there will always be at least 3 people working in the pharmacy. Legally, the employer can set holidays according to business needs, so this schedule would be valid even if an employee disagrees."
And now, what is wrong with that reply:
- The days are not your agreement’s. "22 working days" is an equivalence that appears in many texts, but the national pharmacy agreement specifies 30 calendar days. Counting in working days with the periods it set — 22 consecutive calendar days — gives a figure that is neither one thing nor the other, and anyone on the team who does the sum will see it does not add up.
- There are days with both pharmacists off… or none in. Laura until 22 July and Pedro from the 23rd: no overlap, fine. But at no point was it checked that there was always a pharmacist, because it was not asked to. In the full version of its table, Pedro’s adjustment left 12 and 13 August with both pharmacists away through an error at the edge of the period. It is the edge error from step 4.
- There is personal data that should not be there. "As she has her children on those dates" is family information about an employee, repeated in a document meant to be shown to the team. It was in the chat because it was given to it, and it ended up in the schedule.
- The legal statement is wrong and inflammatory as well. Holidays are set by agreement between employer and employee, in line with what the collective agreement says about the calendar, and the law provides for going to an employment tribunal if there is no agreement. "The employer can set them even if the employee disagrees" is not what the rule says, and written like that in a notice to the team it is the fastest way to start the very argument the case was meant to avoid.
A schedule that looks finished, with a reassuring sentence at the end, that fails on the days, on pharmacist cover, on privacy and on the law. None of the four errors is arithmetic.
With the rule written down, letters instead of names, pharmacist cover explicitly required and a final check in the rota tool, the same problem came out solved in three options — and the gap at the edge of August showed up in the rota tool before anything was published.