Rebuilding Alliants’ hotel staff platform for speed.
PRODUCT DESIGN
HOSPITALITY
SAAS
AI
DESIGN SYSTEMS
Redesigned the platform luxury hotels use to run guest operations, so staff spend less time on screens and more with guests.
MY ROLE
Product Designer
TIMELINE
Jan 2025 - Present
STATUS
Live beta
SCOPE
Rebuilt every module on a new design system, from tokens to production components, and rolled them out to live hotels one at a time.
PROBLEM
Staff were spending more time with the software than with guests.
Alliants runs guest operations for luxury hotel brands across 125K+ rooms: messaging, requests, bookings, guest profiles, room keys and more. The platform had been built one module at a time, and each worked well on its own. But none of them felt connected.
So a single guest request meant reading the message in Conversations, retyping it into a request form, searching for a vendor and opening the booking somewhere else. Five screens and 10 clicks for one dinner reservation, while the guest waited.
The goal of the redesign: handle any guest task from one place, with fewer steps, so staff attention stays on the guest.
Asking took the guest 10 seconds. Logging it took staff nearly 5 minutes.
GUEST ON THE PHONE
Hi, can you book a dinner reservation at Roka Mayfair for 7:30 for 2?
What we were designing around
The hardest constraint was people. Staff are set in their routines, turnover is high, and retraining costs roughly £380 to £730 per person, in hours taken away from guests. The new platform had to feel familiar from day one and be learnable on the job.
Customer success reports, hotel visits and staff interviews kept surfacing three problems:
ISSUE 01
Constant interruptions
Let staff pause a task and pick it up again
ISSUE 02
Retyping the same details
Enter details once, reuse them everywhere
ISSUE 03
No clear view of what’s left
Show at a glance what still needs doing
“What got us here won’t get us where we need to go. We need systems that scale.”
DESIGN SYSTEM
One foundation for every module
None of these problems lived on one screen. They showed up in every module, and fixing them one screen at a time would have meant solving the same problem over and over. So I built a shared foundation first.
I used atomic design: tokens first, then base components, then the product patterns built from them. Every module was redesigned in Figma on that foundation, and every component is now live as library on Storybook.
Building with AI agents
The old loop was simple. I designed the screens, they got prioritised, and an engineer built them. With AI-assisted building, product managers and other stakeholders now ship ideas too. That only works if everyone builds from the same parts, so the system has one rule: use the library, invent nothing.
A missing component should never block anyone. When someone hits a gap, they build what they need and the workflow raises an issue in GitHub. I then build the component properly and publish it to the library, ready for anyone to reuse. People keep the freedom to build, and the system grows from real use.
“A guest walks up. The phone rings. Nothing gets finished in one go.”
ISSUE 01
The problem
Front desk and concierge staff rarely finish a task in one go. A guest walks up mid task, the phone rings, a colleague needs a room checked. In the old platform, leaving a form meant losing it. When we shadowed front desk teams during busy check-in shifts, staff were interrupted roughly every four minutes, and around six in ten tasks were paused at least once before they were finished.
How it evolved
01 · BEFORE
The old platform
Leaving a form to help a guest lost everything typed.
02 · EXPLORED
Auto-saved drafts
Nothing was lost, but finding and reopening a draft took too long with a guest waiting.
03 · ITERATION
A taskbar
One click back to any paused task, but out of sight while staff worked.
04 · SHIPPED
Four window modes
Every task stays in view, or one click away.
Four modes, one form
Each mode fits a different moment. Modal is the default for quick entries. Full screen gives long forms more screen real estate. Docked keeps any task open on the right while staff carry on with the page beside it. Minimised parks it in the taskbar until they need it.
The taskbar is more than a parking spot. It groups related tasks together and surfaces unread guest messages, so nothing slips while staff are in the middle of something else.
Multitasking
Staff can start a request, dock it to the side and open a second one without losing the first, handling a guest at the desk and a caller on the phone at the same time.
Trade-off
Multitasking is limited to one docked slot. Most front desks still run small screens, often 1366×768, and a second docked panel left too little room for the main task. We also had to enforce a limit, or open windows would pile up like browser tabs. When the slot is taken and staff try to dock another task, they choose: close the docked one, or minimise it to the taskbar. Either way, the new task takes the slot and nothing is lost. Docking and minimise has not been added to mobile due to screen size limitation.
“Everything staff need is already in the system somewhere. Finding it again is the job.”
ISSUE 02
The problem
The platform spans conversations, bookings, requests, profiles, campaigns and settings across dozens of screens. Simple jobs took a lot of clicking: retyping guest details into forms, filtering lists to find who’s arriving. Allin sits on top of every screen, so staff can ask instead.
Control, not caution
01 · EXPLORED
Auto-create and approve
Allin created and approved requests on its own. Fast, but staff couldn't see what it did or step in.
02 · INSIGHT
Control was missing
Staff weren't against AI taking action. They were against not knowing what it was doing.
03 · EXPLORED
Show the work
Agents show each step as it runs in the background, so staff can follow exactly what Allin is doing.
04 · SHIPPED
Visible steps, a stop button
Staff can stop an agent at any step, approve sensitive actions, and confirm what Allin prefills.
Already in the conversation
Allin reads the chat and prefills the request, so staff check the details instead of typing them again. When a name matches more than one guest, like Mr Webber, it lists each one with room and dates and asks which.
Handing off the bigger jobs
Some jobs need more than one form. Ask Allin for every guest arriving on 20 March, and it finds them, drafts a welcome campaign and sets up pickup reminders for concierge at the same time, then reports back when both are done. Staff stay with the guest in front of them while it works.
Find the arrivals, then hand off a campaign and reminders that run side by side.
When things don’t go to plan
Unclear requests. Ask for a booking under “Webber” and there might be four. Allin lists the matches and asks which one. If two profiles turn out to be the same guest, staff can tell Allin and it merges them, data and all.
Stopping midway. Stop halts the agent where it is and keeps the progress. If a step has already reached a third party, like an OpenTable booking, Allin flags it and asks whether to cancel it there too. Anything inside the platform can be tidied up later, by staff or by asking Allin.
A step fails. If there’s no table at 8:00, Allin tells the staff member and asks whether to suggest alternatives. It never messages the guest on its own.
Trade-offs and what’s still open
Luxury requests are rarely one step. A Michelin booking that opens a month ahead needs a reminder to call, linked transport and an owner, and a concierge knows when the usual taxi firm is closed. So beyond simple, integrated tasks like OpenTable bookings, staff confirm what Allin does. That costs speed: every confirm is a click full automation wouldn’t need. We accepted it, because one wrong request sent to the wrong department costs more trust than the time saved.
The open questions are where to draw the line between acting and asking for each type of request, and how to let staff hand over more as Allin earns their trust.
“Over a thousand requests a day, forty due at once. No single view can show that.”
ISSUE 03
The problem
Our biggest user handles around 1,500 requests a day, with up to 40 due in the same half hour. Their staff relied on the day calendar, and on a day like that it becomes a wall of text. And no two teams read the day the same way: concierge plans by time, housekeeping by status, managers by what’s overdue.
How it evolved
01 · WHERE WE STARTED
A day calendar and a basic list
V1 had both. At peak times the calendar became a wall of text, and the list couldn’t be shaped around each team’s work.
02 · IMPROVED
A list for control
We rebuilt the list with sorting, filtering, and adding, removing or reordering columns, so each team could shape it around its own work.
03 · ADDED
A board view for status
Requests grouped by status, so staff can see what’s open, waiting and done without reading every row.
04 · SHIPPED
No favourite view
Calendar, list and board view share the same requests and filters. Staff pick the one that fits their job.
Your view, not ours
Requests open as a calendar, a list or a board view, and switching is one click. The requests and filters stay the same, so concierge can plan the evening on the calendar while the front desk works through the board.
The same requests as a list, a board view and a calendar, one click apart.
Save the views you use every day
Most shifts start with the same few filters. Staff can save any mix of filters and layout as their own view, like “Concierge, due today” or “Overdue and unassigned”, so the morning check is one click instead of rebuilding it every time.
Filter once, save it as a view, and it’s a tab from then on.
Trade-offs
Not picking a favourite view meant more to build and maintain: every feature has to work in the calendar, the list and the board view. We accepted that, because retraining hundreds of staff into one way of working would have cost more. Saved views also mean two people can see the same day very differently, so All Requests stays as a shared starting point anyone can fall back to.
“The guest asks once. The platform does the rest.”
THE SOLUTION
OUTCOMES
Where it stands
The redesign is live in production beta. Every module has been rebuilt on the new design system and is being rolled out to hotels one at a time. It’s early, so rather than quote numbers, here’s what has shipped and what we’re measuring next.
12 Modules
Rebuilt and live in beta
69
Components built and published
9
Components added through AI
REFLECTION
What I learned
Fix the system before the screens. Every problem showed up in every module, so the shared foundation did more for staff than any single screen redesign could have.
AI earns trust by showing its work. We started by letting Allin create and approve requests on its own, and staff pushed back. Visible steps and a stop button turned it from something to watch into something to use. Next time I’d test for trust much earlier.
Give people choices, not a default. Not picking a favourite view meant more to build, but far less to retrain.
Disclaimer: All views expressed here are my own and do not necessarily reflect the views of the respective company or person. Some design elements and names have been changed from the original to protect privacy.
Other Projects
A banking app that helps you navigate the cost of living crisis
Solving Amazon's problem with E-commerce returns