Skip to content
allanninal.dev/build
Collaborate

Part 1 of 7 · Housekeeping dispatcher series ~6 min read

A housekeeping dispatcher on AWS for a few dollars a month

The list is produced by priority: eleven rooms with guests arriving early, sorted by arrival time. It sends one housekeeper from the fourth floor to the first, back to the third, then the second, then the fourth again. About forty minutes of the morning disappears into a lift. This post walks through a small system that trades a little priority for a lot of walking.

A group of cranes sitting on top of a large body of water
Photo by Julia Taubitz on Unsplash

Key takeaways

  • Priority and route pull against each other; the answer is a compromise, not either one.
  • Do-not-disturb is absolute. There is no override in the system.
  • Share the difficult rooms out, or the same person gets them every week.
  • Cleaned and inspected are different states and a person sets both.
  • Designed on AWS for about $2 a month.

The whole system on one page

Before any code, here is the shape of what we are designing.

System: room priority, route and fairness combined into a work listThree boxes across the top sit outside the AWS account. On the left, Room status: occupied, checkout, do not disturb. In the middle, Arrivals and their times. On the right, Housekeepers, each with a phone. Each connects by an arrow to the AWS account container below. Statuses flow down into the account. Arrival times feed in. A list, in order, goes back out. Inside the AWS account are three components in a row. On the left, Priority: who needs it and when. In the middle, Route: a floor at a time, mostly. On the right, Fairness, measured over weeks rather than one day. A note at the bottom says three constraints that disagree, and the design is about how they are traded.AWS ACCOUNTRoom statusoccupied, checkout,do not disturbArrivalsand their timesHousekeeperswith a phonePrioritywho needs it,and whenRoutea floor at a time,mostlyFairnessover weeks,not one daystatusesarrival timesa list, in orderThree constraints that disagree. The design is about how they are traded.
Fig 1. Three things outside the account, three pieces inside it. None of the three inside boxes wins outright, and the interesting part is the trade between them.
  • Compute
  • Management
  • Analytics
  • People

Three constraints that disagree

Priority says clean the room whose guest arrives at two o’clock. Route says clean the room next door to the one you have just finished. Fairness says the person who did all the checkouts yesterday should not do them all again today.

Any system that optimises one of these produces something the housekeeping team will quietly ignore, and the version that gets used is a compromise that is explicitly a compromise: mostly route, with priority overriding it where the timing genuinely requires, and fairness applied when the day’s work is allocated rather than within it.

What runs (the inside)

  • Priority. Which rooms need to be ready and by when, which is not the same as which rooms are dirty. Part 2.
  • Route. Ordering the work so the walking is manageable. Part 3.
  • Fairness. Sharing the difficult and the easy over a period. Part 4.

One morning, end to end

One morning of housekeeping allocation in five stagesA horizontal row of five boxes joined by arrows. Thirty-four rooms, eighteen checkouts. Six early arrivals, prioritised. Three do not disturb, deferred rather than skipped. Allocated by floor, then priority. Balanced over the week. A note says the third box is not a problem to be solved but a rule with no exceptions.ONE MORNING, END TO END34 rooms18 checkouts6 early arrivalsprioritised3 do not disturbdeferred, not skippedAllocatedby floor, then priorityBalancedover the weekThe third box is not a problem to be solved. It is a rule with no exceptions.
Fig 2. The same system as one line. The do-not-disturb rooms come back later in the day rather than being escalated.
  • Compute
  • Security & identity
  • Management

In plain words

Thirty-four rooms need attention: eighteen are checkouts and need a full clean, sixteen are stayovers. Six guests are arriving before three o’clock and their rooms are prioritised over the rest.

Three rooms have do-not-disturb on. They are removed from the morning list entirely, re-offered at midday, and if they are still showing do-not-disturb at four, a person makes contact according to whatever the hotel’s policy is. The system’s involvement ends at flagging it.

The remaining rooms are allocated by floor, so each housekeeper works a contiguous block, with the early-arrival rooms pulled forward within their block. Over the week the allocation rotates, so the same person does not always get the floor with the family rooms.

Design rules that shaped every decision

  • Route first, priority second, except where a genuine deadline requires otherwise.
  • Do not disturb has no override anywhere in the system.
  • Fairness is measured over weeks and includes room difficulty, not just room count.
  • Cleaned and inspected are separate states, both set by a person.
  • Record how long rooms actually take, so the difficult ones are known.
  • Never allocate more than the day can hold; an impossible list is ignored entirely.

Why this shape

Housekeeping allocation is usually done on paper by a supervisor who knows the building, and it is generally done well. The reason to build anything is not that the supervisor is wrong; it is that the knowledge lives in one person’s head, the fairness is hard to track over weeks, and nobody has ever measured how long the rooms actually take.

So the system encodes what the good supervisor already does, makes the fairness visible over a longer period than anybody can hold, and collects timing data that turns “room 214 is a nightmare” into a number.

The next four posts walk through each piece: how rooms get prioritised, why the route matters as much as the order, how the work gets shared out fairly, and what ready actually means. One diagram per post, a cost breakdown, and an engineering reference at the end.

All posts