Web design · Hospitality
Hotel sites thathand off the dates.
Arrival, departure, and the right property. The booking engine is the one on your contract, not one we invented a badge for.
The short answer
What the site has to hand off.
A guest has dates, a party size, and a property or a neighborhood in mind. The site has to take those dates and hand them to the booking engine you already use, with the right property selected. Event space is a different path from a leisure room. Rates change by season, so a price on a marketing page needs its conditions. We do not sell a booking engine, and we do not imply a partnership with one.
Buying cycle
Dates first, then the property, then the rate.
Leisure guests compare a rate and the photos, often on a phone, and they finish wherever the dates are easier. If your site hides the calendar, they finish on a travel agency. A wedding or a meeting needs the room, a capacity, and a person. Those should not share a book button that only understands guest rooms.
The guest has to pick a building before a rate means anything. One calendar for several addresses is how someone books the wrong hotel.
Constraints
Their engine, seasonal rates, and the group sheet.
We hand dates, guests, and a property id to the engine you already pay for, in the form that engine accepts. If you have not chosen an engine, the project waits, the same way a store waits on a platform. We will not recommend a vendor as if we had a partnership, and we will not badge an engine we have no agreement with.
A from-rate needs its conditions, or it stays off the page. Seasonal offers have an end date a revenue manager can edit. A ski package that is still the hero in July is a broken module. Photos are of rooms you actually sell.
We control our templates. The engine's screens are a third-party interface. Date entry and the book button on our side have to work with a thumb and a keyboard. We do not certify the vendor's checkout.
- Property pages with address, what is on site, and a book link that passes the property.
- Date fields that a person can use on a phone.
- Group, wedding, and event inquiries separate from leisure booking.
- Offers with an end date, edited by the people who own the rate.
- No custom booking engine built as part of a marketing site.
Channels and KPIs
Handoffs that include the dates.
We measure book clicks that leave with dates and a property, and completed reservations when the engine can report them. Group inquiries are a separate line. Revenue on a travel agency is not a website KPI this template gets credit for.
- Handoffs with arrival, departure, and property populated.
- Group-form completions, not mixed into leisure book clicks.
- Rate modules checked for expired offers.
- Mobile completion of the date step, because that is where tiny calendars fail.
Mistakes
A custom engine and a rate with no conditions.
The expensive mistake is building a booking engine because the current one feels old. You recreate availability and taxes the engine already has, and you still need the engine. The cheap mistake is a from-price with no dates, a photo of a room you no longer sell, and one page for every property.
- No invented booking-engine partnership or badge.
- No 'best rate' promise without a policy you will honor.
- No date picker that only works with a precise mouse click.
- No single calendar that cannot tell your properties apart.
Example engagement
Four properties, one engine they already had.
A small hotel group, four properties. The site had a phone number, a PDF rate card, and photography that mixed renovated rooms with rooms still on the old finish. Leisure and group requests went to the same inbox. They already paid for a booking engine. The site never passed it a date.
We built a property template and a date step that handed arrival, departure, and the property id to that existing engine. We did not sell a new engine, and we did not put a partner badge on the page. Event inquiries got their own form. The rate module required an end date. If the handoff is not documented, that discovery happens before design.
4
Properties with their own book path
Dates
Arrival and departure passed to their engine
The example uses anonymized results from a Quorum engagement. It is one account, not a benchmark you should budget against.
Questions
Hospitality questions.
Will you build a booking engine?
No. We hand the dates and the property to the engine you already use. A custom engine is a different product, and it duplicates availability rules you are already paying someone else to maintain.
Which booking engines do you partner with?
We do not have a booking-engine partnership to offer. If your contract already names an engine, we scope the handoff that engine documents. If you have not picked one, choose it before we design the book path.
Can we show a starting rate?
Yes, with the conditions: dates, room type, and the fact that the rate changes. A bare 'from' price with no context is how a guest arrives angry. Seasonal offers need an end date a revenue manager can edit.
How should weddings and group business work?
As an inquiry with a date, a headcount, and the space, sent to the person who actually holds the calendar. Do not send a ballroom request through a leisure room search that cannot see event inventory. The form must not tell the guest the date is confirmed if nobody has checked it.
What about the engine's own screens?
Those belong to the vendor. We make our date fields, property pages, and book button usable on a phone and with a keyboard. We do not certify the engine's interface, and we will not claim we do.
How long does a property group site take?
Property templates most often ship in 8 to 12 weeks when photography is honest and the engine handoff is documented. An undocumented engine, or a request to build our own, is a different timeline and usually a different project.
More in this lane
Other Web Design industries.
Talk through hospitality.
One conversation. A diagnostic. A plan you can kill if it is not the work.