Hotel Management System
Multi-Department Operational System
Four departments, no shared source of truth
A 42-key hotel running on paper registers, WhatsApp threads and three third-party portals, with every handover done by voice.
The hotel coordinated through a mix of manual processes and disconnected platforms: booking portals, internal registers, spreadsheets, and a lot of shouting across the lobby.
Reception did not reliably know which rooms were ready. Housekeeping learned about a checkout when someone walked over to tell them. Kitchen orders moved by memory. Admin saw the day only after it had finished.
This was not a UI project. It was a workflow system redesign.
What that actually cost
Room readiness was a guess
Reception could not see cleaning status without asking, so guests were either made to wait or sent to rooms that were not ready.
Every handover was verbal
Nothing between departments was recorded, so nothing could be checked later. A missed instruction and a disputed instruction looked identical.
Three portals, one inventory
Availability lived in several third-party dashboards at once, and staff reconciled them by hand. Double bookings were a matter of timing, not of if.
Admin saw yesterday
Occupancy and revenue arrived as an end-of-day reconstruction, which meant operational problems could only be discussed after they had already cost something.
What I had to design around
Staff who had never used an operations tool, a hotel that could not pause, and a client identity I cannot show.
The users were not software users
Housekeeping and kitchen staff had no prior operations software. Anything that assumed familiarity with dashboards, filters or modal dialogs would simply not get used.
The hotel never stops
There is no maintenance window in hospitality. The system had to be adoptable department by department while the property kept running.
Long shifts, low light, real fatigue
Staff live in this interface for eight to twelve hours. Accessibility here is not compliance, it is whether someone can still read a room number at the end of a shift.
Fatigue reduction is a workflow requirement, not a nicety.
Client identity under NDA
The property cannot be named and its branding cannot be shown. The prototype in this case study is a neutral reconstruction of the same system.
Map the operation before drawing a screen
Roles, then flows, then dashboards. Screens came last because they were the easiest part to get wrong first.
Role-based access as the spine
I defined Admin, Reception, Housekeeping, Kitchen and Guest as distinct roles with their own navigation, task surface and data visibility, rather than one interface with things hidden in it.
The permission model came first because it decides what every later screen is allowed to say.
The dependencies that mattered
- Housekeeping to Reception: room readiness
- Reception to Admin: occupancy and revenue
- Kitchen to Reception: room-service state
- Reception to Guest: the only outward-facing edge
What I chose, and what it cost
Three calls that shaped the system, and the honest limits of where it stands.
Separate role interfaces over one configurable view
Each department gets its own navigation and task surface instead of a shared interface with permissions hiding parts of it.
More screens to design and maintain, and more work whenever a shared concept changes. In exchange, no staff member is ever looking at controls that are not theirs.
Workflow modelling before interface design
I mapped roles, states and transitions before opening a design tool, so the interface expressed a system that already made sense.
Weeks with nothing visual to show. Stakeholders had to trust flow diagrams while it looked like no design was happening.
Accessibility built in, not audited later
Contrast, target sizing and non-colour status encoding were requirements from the first screen rather than a pass at the end.
It constrained the visual language early, and ruled out some denser layouts that would have fit more on a screen.
What I'd fix
The system is pre-launch, so every outcome below is an expectation, not a measurement. I have written them as such rather than dressing projections up as results.
I designed the guest-facing edge last and thinnest. Reception carries almost all guest communication, which means the one relationship the hotel actually sells is the least supported surface in the product.
Where it stands
In development, pre-launch. These are the outcomes the system is built to produce, stated as expectations.
no launch numbers yet, on purposeNo launch metrics exist yet. When the property goes live the numbers worth watching are room turnaround time and the count of cross-department follow-ups, because those are the two things the system was built to remove.