# Hotels, rebuilt: Redesigning a 26-year-old hotel management system for 7,000+ hotels Designer: Phaneendra Sivangula Interactive version: https://hellophaneendra.com/#/work/hotel Role: Product Designer Timeline: Aug 2023 - Aug 2024 (MVP in 8 months) Team: 3 designers, 12 developers Summary: ASI PMS runs 7,000+ US hotels and 1B+ bookings a year, but it was built for small, simple properties. We researched, prioritized and redesigned it for complex, multi-role hotels, and shipped the MVP in 8 months. Problem: A 26-year-old PMS built for small hotels. Setup took 2-4 weeks and staff worked around it with spreadsheets and paper. Approach: Worked shifts in 12 hotels, picked 3 roles out of 7, and redesigned 4 core flows on a modular design system. Outcome: MVP live in 8 months. Top 3 PMS on Booking.com, an estimated +40% adoption, setup in 24 hours or less. --- HOSPITALITY / SAAS / ASI VIA FOUNTANE ## Redesigning a 26-year-old hotel management system for 7,000+ hotels ASI PMS runs 7,000+ US hotels and 1B+ bookings a year, but it was built for small, simple properties. We researched, prioritized and redesigned it for complex, multi-role hotels, and shipped the MVP in 8 months. ROLE Product Designer TIMELINE Aug 2023 - Aug 2024 (MVP in 8 months) TEAM 3 designers, 12 developers TOOLS Figma, Ant Design, SurveyMonkey Top 3 PMS, as named by Booking.com ~40% estimated adoption lift, from early outreach 24 hrs or less to set up a hotel, down from 2-4 weeks PROBLEM A 26-year-old PMS built for small hotels. Setup took 2-4 weeks and staff worked around it with spreadsheets and paper. APPROACH Worked shifts in 12 hotels, picked 3 roles out of 7, and redesigned 4 core flows on a modular design system. OUTCOME MVP live in 8 months. Top 3 PMS on Booking.com, an estimated +40% adoption, setup in 24 hours or less. 01 The brief OVERVIEW ### The product and the business need ASI PMS is a property management system that has run hotels across the US for 26 years: 7,000+ properties and 1B+ bookings a year. Front desk, housekeeping, managers and owners all work in it every day. 26 yrs in the market 7,000+ hotels 1B+ bookings a year It was built for small, simple hotels. As ASI moved into larger properties, with many departments and roles working at the same time, the product couldn't keep up. #01 #### Clients were frustrated Just getting set up took 2-4 weeks of back-and-forth with ASI support. #02 #### The interface had aged 26 years of features without a design system made a capable product hard to use and hard to trust. #03 #### A deadline was coming The AAHOA conference was the moment to show a new ASI, and any delay risked losing clients. The goal: research, strategize and redesign the end-to-end experience for complex, multi-role hotels, on a modular foundation that could grow. MY PART ### What did I do? I was the product designer on a team of 3 designers and 12 developers, from research through launch. - Field research in 12 hotels, working as front desk operator, manager, housekeeping supervisor and finance manager - Helped narrow 30+ opportunities down to 3 roles and 4 core flows - Designed setup, check-in, the performance calendar and housekeeping - Built the design system alongside the product, on Ant Design - Wrote handoff docs for every component, including a 20+ status legend - Ran live usability tests with customers at AAHOACON 02 Research RESEARCH ### We worked the front desk ourselves We came in as outsiders to hospitality, with no assumptions to protect. We knew the system was broken. We didn't know why staff kept using it anyway. 3 weeks in the field 12 hotels across California 130+ survey responses - Ethnographic studies from small independent motels to large chains - Contextual interviews with staff during real shifts - Surveys to check what we saw at scale FINDINGS ### Staff were working around the product Next to the software, in almost every hotel, we found the same three things: #01 #### The rate spreadsheet Pricing was managed outside the system, then typed back into it. #02 #### The paper checklist Housekeeping tracked rooms on clipboards, not screens. #03 #### The verbal handoff Reservation changes were passed on by word of mouth between shifts. That's not a user problem. It's a design failure that had been normalized for years. #### Underneath, the problems were architectural #01 #### Weeks before day one Setup ran through ASI support. Hotels met the product through weeks of back-and-forth. #02 #### Everything for everyone Built for no role in particular, so every role got every feature. #03 #### Always reacting No proactive intelligence. Problems were handled after they arrived. #### And then, the screen itself 26 years of features, no design system. Nothing told you what needed attention now and what was just background. At a busy front desk, that's not an aesthetic issue. It's a functional barrier. 03 Strategy STRATEGY ### 30+ opportunities. 7 roles. We picked 3. Designing for all seven roles would have diluted everything. With a hard conference date and frustrated clients, we set three principles: 1 Start with the 3 roles with the most daily use and the most workarounds: front desk, housekeeping and hotel manager 2 Use AAHOACON as a forcing function: real users, a real booth, a real date 3 Build modular, so the other roles and integrations can plug in later Prioritization was the most important decision we made, and it wasn't a design decision. IDEATION ### Mapping, sketching, then deciding - Experience maps for every scenario, including failure states - Workflows co-written with engineering before committing to a direction - 8-up sketching to stay divergent, then peer reviews before high fidelity - Borrowed mental models from tools staff already used every day #### Sketches first Every flow started on paper, so we could throw away ideas cheaply before any pixels existed. That work shaped four core flows. Here's how each one went from finding to design. 04 Design 01 SETUP ### The four-week wait A new hotel signs up, then waits two to four weeks for ASI support to configure it, with no way to see how far along it is. That wait is where people form their first picture of a product. The picture was friction and dependency. THE QUESTION How might we let hotels set themselves up, and reach first value without calling support? Experience maps showed which moments actually blocked people and which only slowed them down. That line decided the MVP. Workflows also showed pricing and plans sat at the very end of setup, which changed the design. #### Two constraints we couldn't remove #01 #### The verification wait Regulation required it. So we designed the waiting, instead of pretending it away. #02 #### The price list Pricing had to get simpler before the UI could. That was a business conversation, not a design one. Here is the new setup flow, from an empty account to the first payment. Every step saves, and the plans fill the verification wait. 01Start from an empty list Add a group or a single property, or import from Booking.com. 02Property basics Name, website, proof of identity, logo and photos. 03Contacts and address Who to reach, who owns it, and where it is. 04Pick a plan while verification runs The required wait becomes time to choose a plan. 05Add-ons and a bundle Extra modules and hardware sit right next to the plans. 06Pay, with the total in view Saved cards or a bank account, and a clear subscription summary. BEFORE 2-4 weeks, run by support, with no progress in sight. AFTER A 4-step guided flow, self-served. Every step saves, so an interruption means pausing, not starting over. 20 min - 24 hrs to set up a hotel 02 CHECK-IN ### Three screens, one guest At the front desk, operators switched between three screens, rooms, guest details and billing, while the guest waited. Check-in isn't a form. It's a conversation. THE QUESTION How might we make check-in fast and intuitive enough to finish within five minutes? We tested three information architectures instead of betting on one: Variation 1 Booking details Available rooms You're in! Less navigation, more visual complexity. Variation 2 Available rooms Booking details You're in! Matched how staff think, but broke when rooms weren't available. Variation 3 Room needs Available rooms Booking details You're in! Best completion under realistic interruptions. - Progressive disclosure: only what this moment needs - Pre-filled suggestions for repeat guests - Patterns staff already know, for a role with high turnover It should feel inevitable. Not something you learned, but something you already knew. 03 PERFORMANCE ### Pulling the spreadsheet back inside A revenue manager wants to know three things: how bookings look, which rooms are out of service, and what the next few days hold, so they can change prices without leaving the system. THE QUESTION How might we show hotel performance so it's clear, complete and quick to read? Revenue managers already knew these patterns. We didn't need a new paradigm, just a familiar one applied to hotel data. - A calendar and Gantt hybrid: overview up top, detail inline - Color-coded room status you read before you read a word - KPIs inside the chart, not on a separate report #### One legend, 20+ statuses Every status had rules for when it could be applied or overridden, and a color that had to be readable at a glance and technically exact. It took several rounds with engineering. I'd rather have those conversations at the start of a sprint than at the end. 04 HOUSEKEEPING ### Hands full, no time to tap A housekeeper moves room to room all day, hands full. A supervisor sits at a desk, planning the floor. Same data, very different days. Staff pushed back on a complex app. So we split it in two: SUPERVISOR Auto-assign, a full room status overview and oversight tools. STAFF A status-first view: a room's condition reads through color, without reading anything. One interface for both would have served neither. 05 Outcome DELIVERY ### Designing while it was being built As scope grew and time shrank, design and development ran in parallel sprints. Design kept uncovering problems the original documents had missed. Agile gave us room to act on them instead of filing them away. LAUNCH ### The booth became the usability lab Eight months in, we took the MVP to AAHOACON and ran live usability tests with real customers at the ASI booth. Their feedback landed on the exact friction points our research had found. 8 mo from research to a live MVP Top 3 PMS, named by Booking.com ~40% estimated adoption lift And Expedia made ASI a preferred partner. The real validation wasn't that we shipped something impressive. It's that we shipped something that solved the right problem. TAKEAWAYS ### What I'd bring to the next one 1 #### Prioritization is strategy. Choosing 3 roles out of 7 shaped the product more than any screen. 2 #### Design the constraint. When the wait couldn't go away, designing the wait was the answer. 3 #### Work the job. A shift behind the desk explained more than any interview. 4 #### Talk to engineering early. The legend, the flows and the setup all got better before a line of code.