Joel Sinnott — Senior Product Designer

I design web and mobile products end to end, from strategy and research to polished UI, somewhere between ruthless pragmatism and relentless tinkering.

Download CV
2026

Product strategy and redesign for AI-assisted hotel booking software

Lobby AI

Product strategy and redesign for AI-assisted hotel booking software

Lobby AI
My involvement
Product design, Strategy, Research
Client type
Startup
Agency
Freelance
Status
In development
Image showing the work done on the project
Image showing the work done on the project
Image showing the work done on the project
Image showing the work done on the project
Image showing the work done on the project
Image showing the work done on the project
Image showing the work done on the project
Image showing the work done on the project

When corporate customers request a hotel booking, much more happens behind the scenes than confirming a room. Reservation teams check availability, handle special requests, allocate guests across rooms, resolve conflicts, enter the details into the property management system (PMS), and manage later amendments or cancellations. Today, much of this work is manual, repetitive, and error-prone. Lobby AI aims to automate this.

The challenge

Lobby has invested significant effort into fine tuning its booking request processing, yet the usability of the tool was lagging behind. The product surface currently consists of a browser extension which can be opened in a side-panel alongside the customer’s email inbox. As new booking requests come in, Lobby runs the raw text through its AI as well as rules set manually together with the customer. Ideally, the result is a fully prepared booking, ready to be approved and written to the PMS.

A booking prepared by Lobby

However, the unstructured nature of Lobby’s input presents a number of challenges:

  • Reservation agents need to be able to verify Lobby’s work
  • Incorrectly parsed information has to be easy to amend
  • Judgement calls made by Lobby should be reversible
  • Every parsed detail should be traceable back to its source
  • Lobby has to know when to act on its own judgement and when to ask for help

In essence, the core challenge is one of trust.Agents should be able to approve Lobby’s work with confidence, and do so without spending more time verifying than they would have spent simply entering the data by hand.

Setting the product direction

The first phase of the project aimed to build a better understanding of how users currently use Lobby. To get my footing, I held extensive discussions with the team about the challenges they face and the pivotal product decisions that influenced the current state of the product. I also used AI to synthesise insights from months’ worth of customer calls and conducted interviews with active and prospective customers.

All the gathered insights were subsequently discussed and workshopped with the team, eventually resulting in a vision that set the direction for the upcoming work.

Vision board: four principles for Lobby, moving it from working like a tool to working like an assistant
Vision board

Design exploration

With the product direction set, I began exploring possible directions for the interface. Users need to be able to review, amend, approve, or decline booking requests. They need a clear view of the booking’s overall status, as well as any individual details that Lobby has adjusted or that require their attention. The narrow form factor naturally constrained how much information could be shown at any given time, making strong prioritisation essential.

Iterate, iterate, iterate

A core challenge was balancing clarity with the complexity of the underlying PMS data. Booking records are complex and contain interdependent information, but exposing that complexity up front would make for a less than optimal review experience. Furthermore, Lobby needs to work across different PMSs, so a bespoke solution for one system would not work for another. Rather than rebuilding each PMS interface inside Lobby, we aimed to create a generic yet truthful abstraction that captures the information agents need to review and act on, while preserving a clear link to the underlying PMS records.

A topic of much discussion was when Lobby should autonomously apply alternatives for a booking that can’t be fulfilled exactly, versus suggesting options for the user to choose from. We went back and forth, but ultimately agreed that the loss of trust from repeated erroneous changes, and the work of undoing them, outweighs the extra effort of choosing manually from a set of suggestions.

Where we ended up

Despite setting a fairly tight scope at the start of the project, this project was characterised by broad exploration, frequent pivots and rabbit holes. Until the very end I was making adjustments and refining the interface as mine and the team’s intuition grew stronger. The final version of Lobby took shape in the last week of the project.

Below is a working model of what I delivered. Switch between the three states a booking can arrive in, and hover over parts of the panel to see what each one is for.

These are the defining features of the solution we landed on:

  • Lobby status barThis element sits directly below the booking title and shows how closely the prepared booking matches the original request. A green Lobby logo means a 100% match. Purple means the booking can be approved, but Lobby made adjustments, such as changing the room type because the requested one was unavailable. Orange means an item needs attention before the booking can be approved. Besides acting as a status indicator, it’s also the entry point to Lobby’s “brain,” where its reasoning can be inspected and issues resolved.
  • OverviewTo ensure scalability, we opted to show all booking details in a simple two-column list. Initially only the most important details are shown, while the rest are collapsed. Which details count as important varies between customers, and it isn’t for us to decide what those are. This is therefore configured with the customer during the initial setup.
  • Record viewAs mentioned earlier, we wanted to optimise for an easy review experience, since it is the most common task in Lobby. In the rare case that Lobby parses a piece of information incorrectly, or an experienced user wants to make a complex amendment across multiple booking records, users can access the raw records in a familiar table view. Like lifting the hood on a car, clicking the “Records” button in the top right reveals a table of all the individual booking records that will be written to the PMS upon approval.

Conclusion

The project comprised 14 billed days spread over a little more than a month, during which I was in the office every week, working side by side with the founders and engineers. The pace was fast and many questions remain open, but together we defined a strategic direction and took the first steps. From here, the ideas need to be built, tested in real life, and refined through feedback and Lobby’s own growing product intuition.