Drafting a hotel shift plan with AI: what to give it and what to recount yourself

AI shift scheduling means asking a chat tool to draft a rota from coverage needs and written rules, then checking every hour yourself. The tool is good at first drafts and swap options; it is unreliable at arithmetic. Give it coverage per day, staff codes and plain-word rules, then recount weekly hours, daily rest and night limits in a spreadsheet.

It is Thursday afternoon, two people are on approved leave, one swap request is sitting in your messages, and the rota for next week is still an empty grid. A chat window is open beside it. The question is not whether the tool can fill the grid, because it can, but which parts of the result you are willing to sign. After reading this you will know exactly what to paste into the tool, what to keep out of it, and how to check the draft before it reaches your team.

What can AI actually do in shift scheduling?#

It writes first drafts and swap options quickly, and it is unreliable at the arithmetic a rota depends on. Use it for the parts where a wrong answer is easy to see.

The good uses are all drafting work. The tool turns a coverage table into a full grid, proposes three different ways to cover a Saturday gap, rewrites the finished plan as a short message for the team channel, and drafts the note that explains a change to a person who lost a preferred shift. These are text tasks, and text is what a language model does.

The bad uses are all counting work. Do not ask it to add one person's hours across seven days, count nights per person, keep a running total while it edits the grid, or hold two constraints at the same time, such as weekly hours and rest gaps. It will produce an answer for each of these. The answer will look like a computed result. It is not.

The reason is mechanical. A language model predicts the next likely word, so a total it states is a plausible number rather than a computed one, and a plausible total in a rota looks exactly like a correct one. This gives you a decision rule for the whole task: give the tool work where you can spot an error in seconds, and keep the work where an error stays invisible until payday.

There is a second limit worth naming. The tool has no memory of last month's nights and weekends unless you paste them in, so fairness has to be supplied as data, not requested as a quality. And remember what the rota is: it sets hours that must stay inside legal limits, so it is closer to a record than to a suggestion. The person who signs it owns it, not the tool.

What should you give the tool? The input sheet#

Give it a coverage number per day, staff as codes with skills, and the rules in plain words. Nothing else goes in.

Coverage per day is derived from the workload, not from habit. Work out arrivals, departures, rooms occupied, restaurant covers and any event in the building that week, then decide how many people you need per shift. If you have not done this step, read how to cover the desk, the floors and the nights fairly before you open the chat window; the tool cannot fix a coverage number you guessed.

Staff appear as codes, for example P1 to P12, each with a short skills tag: front desk, night audit, languages spoken at the desk, driver, trainee who cannot close alone. Names, health notes, pay, performance comments and disciplinary history stay out. A public chat tool keeps what you paste, and personal data plus health data is the worst combination to leave in a text box.

The grid itself is days across and roles down, with one number per cell: how many people are needed on early, late and night. Beside it sit two blocks. A constraints block lists what cannot move: approved leave, fixed days off, the person on light duties, the two staff who must not be scheduled alone together. A rules block lists what must hold, written as sentences the tool can quote back at the end of its draft. Ask for the output in one fixed shape, a table with one row per person per day, so the recount later is mechanical rather than interpretive.

How do you write the rules in plain words?#

Write each rule as one sentence with a number and a consequence, so the draft can be checked against it line by line.

Good rule sentences are short and countable: no one works more than five days in a row; after a night shift there are at least 11 hours off before the next start; night shift runs 23:00 to 07:30; two people on the desk between 15:00 and 19:00. Each one can be checked against a row of the draft without interpretation.

Separate the legal floor from the hotel's own preferences. The law sets the minimum, your house sets the rest, and the tool should be told which is which, so that when a rule is broken you can see whether it is a legal problem or a preference problem. Tell it what to do when a rule cannot be met: mark the cell GAP and list the broken rule at the end, rather than quietly filling the cell by bending something else.

Do not ask for a fair plan. Ask for a plan where nights and weekend days are counted per person and the counts are shown, because fairness is a number, not an adjective. Ask for the arithmetic in a visible column, hours per person per day, so an error has somewhere to show itself. And keep the rules block in a document you reuse every week. The tool changes, the rules do not, and a stable brief produces drafts you can compare across weeks.

Why are language models poor at counting?#

Because they generate the next likely word rather than the result of a sum, so a total that reads correctly can be wrong by hours.

When the tool appears to add, it is producing a number that fits the text. In prose that is harmless; in a rota it is the difference between 44 and 47 hours for one person. It also drifts while editing. Change one cell and the totals it stated three messages earlier are stale, and it may restate them from the old version without warning. Long tables make it worse: the further a number sits from the point where it is used, the more likely it is to be carried across wrongly.

Two constraints at once, rest and weekly hours, is where drafts fail most often and most silently, because the grid still looks complete. What helps is structural: have the tool output a plain table you paste into a spreadsheet and let formulas do the adding, rather than asking it to total anything itself. If you want to go further with this, formulas and pivot tables that check a result are the natural next read.

The rule of thumb for the whole task: the tool drafts, the spreadsheet counts, a person decides.

The recount: what do you check in your own sheet?#

Four numbers per person: weekly hours, the longest single day, the shortest rest gap, and nights worked. Everything else is detail on top of those.

Weekly hours come first. Sum each person's hours across the week and compare with the normal weekly limit and with the average over the balancing period. Under Labour Law No. 4857, normal working time is at most 45 hours a week, and in tourism the averaging period is four months, extendable to six by collective agreement (source: T.C. Cumhurbaşkanlığı Mevzuat Bilgi Sistemi, İş Kanunu No. 4857, consolidated text (opens in a new tab), 2 November 2026). Where weekly hours are spread unevenly across days, no day may exceed 11 hours, so check the longest day per person, not just the weekly total.

Rest is the check that catches what the weekly total hides. A worker whose shift changes may not start the next shift without at least 11 hours of uninterrupted rest. A night shift ending at 07:30 followed by a 09:00 start fails, even when the weekly total looks fine.

Night work has its own limits. Night work often has stricter hour limits and consent requirements than day work. These limits vary by contract and sector. Verify the specific night-work hour caps and consent rules for your team with your legal adviser. Overtime, hours beyond the weekly limit where no averaging applies, needs consent, is capped across the year and is not worked at night; the detail belongs in the working-hours article, not in the weekly routine.

Breaks belong in the plan, not in an assumption: check that each shift long enough to need one actually contains it. And treat all of this as a check, not legal advice. Confirm the limits, the averaging period and your own contracts with your HR lead and a legal adviser before you rely on any draft.

Every figure in this sheet is computed by formula, never typed.

How do you check fairness before you publish?#

Count what people actually notice: nights, weekends, closing shifts and days off that fall together. Then compare with last month, not with zero.

Build a small fairness table beside the rota: per person, nights, Saturdays and Sundays worked, closing shifts, total hours, and how many days off fell together. Fairness is a running balance across weeks, so keep the last four weeks next to the draft. A person who took the last two Saturdays becomes visible before you hand out a third.

Watch the second-order effects too. The only person who can close alone will collect every late shift unless the plan says otherwise, and that is a training problem disguised as a scheduling one. Ask the tool for three alternative drafts with one stated trade-off each, then choose. Asking for the fairest plan gets you an adjective; asking for alternatives gets you a decision.

The example values are hypothetical and exist only to show the shape of the check. Finally, show the counts to the team with the plan. Most arguments about a rota are arguments about a number nobody wrote down.

Who owns the plan once it is published?#

A named person, because a rota is a set of promises to staff and the record of hours worked.

Publish the counts with the grid: hours per person and nights per person, so the team reads the same numbers you checked. Changes after publication go through one channel and one approver, and the change is written into the same sheet so the recount stays true. Keep the published version and every change to it; at month end this is what payroll and any question about hours are settled against.

Swaps need a second recount. Two staff can agree a swap that keeps total hours identical and still breaks the rest gap, which is exactly the error a person catches and a draft does not. Separate the plan from the shift log: the plan says who should be there, the log says what happened, and the two are read together when the next plan is drawn. If you want to feed those logs back into planning, turning shift logs into an action list is the companion task.

What to do next#

Build two sheets this week and reuse them forever: the input sheet that briefs the tool, and the recount sheet that checks its draft. The tool will change, the model behind it will change, and the two sheets will not, because they hold your coverage numbers, your rules and your arithmetic. That is the whole method: the draft comes from the tool, the counting comes from the spreadsheet, and the signature comes from a person.