- Product Design Lead
- Live · 5 properties
- PMS · Channel Manager · Booking Engine
Designing the rules, then making sure the product kept them.
PMS, channel manager and booking engine in one system, now live with five properties on a free trial. I led design with one other designer, working with our PMs and engineers on the configuration logic where one wrong setting misprices a room on every OTA.
- Product
- Hotel PMS, channel manager and booking engine. Live, five properties on a free trial.
- My role
- Design lead with one other designer. Product decisions made jointly with our PM; built with our engineers.
- The hard part
- One setting cascades: room type → rate plan → restrictions → inventory → OTAs → front desk → billing.
- What I did
- Turned business rules into interface constraints, and questioned Channex logic instead of mirroring it.
- How I validated
- Tested every module end to end on desktop and mobile. Logged 129 findings across three rounds; our developers fixed every one.
- Research
- Owner interviews by our PMs and founders. I sat in on competitor product demos.
What I owned
The problem
Hotel operations aren't broken. They're fragmented.
Hotels rely on multiple disconnected systems: manual work, operational mistakes, lost revenue.
- 01Disconnected systemsNo shared data.
- 02Manual operationsOne booking. Entered multiple times.
- 03Inventory sync issuesOne delayed update. One double booking.
- 04Revenue leakageSmall inefficiencies. Big losses.
- 05Every bookingan OTA brings in costs the owner a commission.
I started with a wall of notes, not a solution.
Our PMs and founders interviewed hotel owners; I sat in on competitor demos. Everything from both went up on one board, and the same two systems kept separating out.
Our PMs’ owner interviews and the competitor demos I sat in on kept surfacing the same two systems. A PMS runs everything inside the building: front desk, guests, housekeeping, reservations, reports. A channel manager runs distribution outside it: inventory, availability, rates, OTA, pricing. Neither talks to the other, so hotels are forced to run both. ClearHost connects them into one operating system.
Understanding the industry.
Before designing anything
I sat in on competitor demos and mapped how existing platforms think.
To learn the mental model an owner is asked to adopt, and where each one gives up.
- Sat in on competitor product demo calls
- Watched their workflows end to end
- Studied the Channex API documentation
- Learned the hospitality vocabulary
Key learnings
- Room types & rate plans
Hotels sell room categories, each carrying multiple pricing strategies.
- Inventory & OTA distribution
Availability has to stay in sync across every booking channel, in real time.
- Hotel operations
Reservations, front desk, housekeeping and guest stays are connected, but serve different jobs.
- Multi-property management
Hotel groups need centralized control, alongside property-specific teams and permissions.
- Revenue management
Pricing, occupancy and booking source directly decide how the business performs.
From our PMs' owner interviews
Two things that shaped every screen.
- 01
They didn't lack software. They were drowning in it.
Every property already had a PMS, channel manager, spreadsheets and messaging tools. The problem was that every workflow lived somewhere different.
- 02
In hospitality, simplicity survives churn.
Staff changes constantly, so complex workflows have to be relearned again and again. Hotel software needs to make everyday work easy for whoever joins next.
How ClearHost got built
From what we found to what we shipped.
Nine artifacts, from the PMs’ findings to my testing and the live product.
How ClearHost got built, in nine artifacts: an opportunity note from the PMs’ interviews, the competitor demos I sat in on, jobs to be done synthesized with the PM, the business rules we settled before any screen, the system flow tracing each setting downstream, design-to-dev handoff, my testing of every module with 129 findings, fixing all of them with engineering, and the live product with five properties on a free trial.
Decisions between steps: Jobs to be done to Rules first, With the PM; System flow to Design → dev, Specced; Test the build to Fix with engineering, 129 findings; Fix with engineering to Live, All fixed.
From what I saw to what we'd build.
Problem statement
India's independent hosts don't need more software. They need their software to stop fighting them, and to help them win back the guest the OTAs took.
Context set by our founders and PMs
hover to spread the decktap a card to browseNot another PMS. The operating system that runs the property.
Owner-operated stays need one place to manage the whole business.
PMS vendors stop at the front desk. Channel managers stop at the OTA.
01 Not another PMS. The operating system that runs the property.
PositioningHow we say it02 Owner-operated stays need one place to manage the whole business.
ICPWho we build for03 PMS vendors stop at the front desk. Channel managers stop at the OTA.
BenchmarkingWho we’re up against
Designing the rules, not just the screens.
Rate plans are where hospitality software usually asks the host to already think like the software. We decided these rules with our PM; I designed how the interface enforces them, then tested whether the shipped product actually did. An invalid configuration is hard to reach, and obvious when you are near one.
Where one setting travels
Change a room type and it reaches the guest’s bill. Every step below was designed, then tested.
- 01Room type01
Dorm or private, occupancy. A room can’t be linked to a room type until it has a rate plan, so no room becomes sellable without a price.
- 02Rate plan02
Standalone first, derived only once a base exists.
- 03Pricing03T2
Per-person rows bounded by occupancy.
- 04Restrictions04T1
Min and max stay. Stop-sell and closed-to-arrival / departure moved out of rate-plan setup into the date grid, where setting them twice was confusing inventory.
- 05InventoryT1
Availability per date, capped at the real number of rooms.
- 06Channels
Pushed to OTAs through Channex.
- 07Booking engineT2T5
Direct bookings, coupons.
- 08Front desk
Check-in, ID verification, room assignment.
- 09BillingT3
Advance, cancellation policy, balance.
- 10HousekeepingT4
Room status after check-out.
Who gets to change it
Every setting above lives inside a property, and every property has its own people.
- Organisation
Created at sign-up, with the first property onboarded straight after.
- Property
Added one at a time. Each has its own billing, configuration, settings and team.
- Role
Set per property, so the same person can run one hotel and only see reports for another.
- Owner
- Created the organisation. Every module, across every property.
- Admin
- Promoted by the owner for a property, and runs it.
- Manager
- Only the modules an owner or admin grants: one manager on reports, another on PMS.
- Front desk
- PMS only: reservations, check-in and check-out, housekeeping.
Tested Module 0 testing caught an invited user who signed up directly without being told about their invite, and members who couldn’t see the organisations they belonged to. Both fixed.
A shared dorm is sold per bed, so “per room” pricing switches itself off instead of erroring later.
Instead of an error on save, or hiding the option. Per-room pricing is valid for the same host’s private rooms, so a missing option reads like a bug. Greyed out with the reason inline, it reads like a rule.
A derived plan needs a base plan to exist first, so the first plan is always standalone: locked, not asked.
Instead of Channex’s up-front Standalone / Derived choice, which lets a host pick Derived with nothing to derive from. Derived appears once a base plan exists.
Choose the occupancy first; the pricing modes that cannot apply are never offered.
Instead of listing every mode and checking on save, as Channex does. An increase can never apply below the primary occupancy, so it isn’t greyed out, it’s gone: there is no other state of that row where it would be valid.
The system never rewrites what the host typed; it flags what is wrong, says why, and leaves the fix to them.
The pattern, in hindsight
Correct what’s physically impossible. Flag what’s contradictory intent.
And when an option can’t apply: disable it if it’s valid elsewhere, remove it if it never is.
I didn’t start with these rules. Looking back across the decisions and the testing, they’re the lines everything falls on.
- CorrectedA dorm can’t be sold per room, so per-room pricing switches itself off.
- CorrectedYou can’t sell 100 of 5 rooms, so availability is capped, with a note saying why.
- FlaggedMin-stay above max-stay is the host’s own conflicting intent, so it is flagged and never rewritten.
- DisabledPer-room pricing stays visible for a dorm, greyed out, because it is valid for private rooms.
- RemovedIncrease modes never apply below the primary occupancy, so those rows never offer them.
Then I checked the product kept them.
I tested every module end to end, on desktop and on phones, and wrote up what I found with annotated screenshots for engineering. Some were gaps in my own designs, others were in the build; our developers fixed every one. These are product testing rounds, not user research.
- 129findings logged
- 3testing rounds, one per module group
- Allmodules, desktop and mobile
- Module 0 · 30
Organisation, properties, members, onboarding
- Module 1 · 61
Rooms & rates, inventory, taxes, booking engine, channels
- Module 2 · 38
Guest operations, front desk, housekeeping, room management
Not every finding was a one-line fix. Tax-set branching was built wrong: the arrows did not group taxes the way they should. I walked the developer through how tax groups branch, again, and we corrected the interaction together.
Five findings that changed the product
- T1Module 1 · tests Decision 04
One stay rule, three surfaces
Found
Minimum stay could be set above maximum stay, max stay had no way to say “no limit”, and the help text described fields instead of what a guest would experience.
Changed
The rule now holds in rate plans, the per-date inventory grid and bulk update. Max stay became “No limit / Add a limit”, and the help text reads as a consequence: “Guests checking in with this rate plan must stay at least 2 nights.”
- T2Module 1 · tests Decision 03
Occupancy pricing, followed end to end
Found
Per-person pricing offered rows that could not exist: “fewer than 1 guest” when the primary occupancy was one, and “more than n guests” when n was already the room’s adult capacity. Channex also needed restrictions per occupancy (Half Board for 1 guest, for 2 guests).
Changed
Impossible rows are removed, the inventory grid carries restrictions per occupancy, and the booking engine now charges what the plan says (it had been skipping the −10% for a second guest).
- T3Module 2
Checkout money and the cancellation policy
Found
A ₹12,000 advance showed as ₹24,000 paid, leaving a balance due of −₹17,000. Separately, a checkout completed without its final confirmation.
Changed
Balance follows the cancellation policy: if the advance is non-refundable the balance is ₹0, otherwise the difference (₹5,000 here) is owed back. Checkout only commits on confirmation, and moving a reservation asks first.
- T4Module 2
Housekeeping as a state machine
Found
Rooms turned Dirty at check-in instead of check-out, and a cleaning task in progress offered “Mark dirty”.
Changed
Adding a task sets the room Dirty (Inspecting for inspections), in-progress tasks offer “Mark clean”, and Do Not Disturb became its own room status. Urgent tasks on a DND room are allowed with a warning, not blocked.
- T5Module 1
Booking engine setup: from tabs to steps
Found
Switching tabs in the booking-engine page editor silently lost what you had typed, Save / Discard on every tab was confusing, and publishing with empty details threw an unexplained error. Coupon fields accepted negative numbers.
Changed
The editor became a stepper, saving became one “Publish changes” action with a “new changes made” cue, and publish says what is missing. Coupon fields block negatives, and an empty “max uses” means unlimited.
T3, up close
A ₹12,000 advance, counted twiceOwner appears to owe the guest ₹17,000After · the rule it follows now
- Total
- ₹7,000
- Advance paid
- ₹12,000
- Advance non-refundable under the cancellation policyBalance due ₹0
- Advance refundableRefund ₹5,000 to the guest
Also caught
all fixed- Derived plans showed a link to their parent, but parent edits weren’t reaching the child plans.
- Coupons with a minimum stay now account for a shorter search instead of failing at checkout.
- An ID was marked verified at check-in without any verification.
- A raw validation error (“occupancy.infants is required”) surfaced to front-desk staff.
Three modules, one system.
The three surfaces an owner actually lives in: the PMS at the front desk, the channel manager for distribution, the booking engine for direct bookings. Scroll to move through each.
Live, with five properties.
The properties are on a free trial, so there are no usage numbers yet. Here is what I can verify.
- ShippedPMS, channel manager and booking engine are live. Five properties are onboarded on a free trial, with every module available to them.
- Prevented by designPer-room dorm pricing, derived plans with no base, impossible occupancy rows, min-stay above max-stay, and availability above real rooms can no longer be set from the interface.
- Caught in my testing, fixedCheckout balances that ignored the cancellation policy, an ID marked verified without verification, and housekeeping status flipping at check-in.
- Every finding fixedAll 129 findings from my three testing rounds were worked through with our developers and resolved.
What building this changed in me.
Not tidy takeaways: the two places my thinking changed most between the first rate-plan screen and the live product.
I assumed the API would define how the product should work.
While working through Channex, I found gaps and confusing logic around taxes, dormitory pricing and cancellation policies. I learned to question the integration instead of designing around it blindly.
I thought simplifying a workflow meant removing options.
The dormitory pricing work changed my thinking. The better solution was to understand the underlying rules, remove unnecessary choices and make the system handle the complexity for the user.
ClearHost is live with five properties.
On a free trial today, with every module available to them.