Skip to content
H-Studio
ENID
Start a project
Bali · Services · Booking & Guest Platforms

Booking and guest platforms built for direct relationships.

Direct booking journeys, guest portals, pre-arrival workflows and PMS-connected booking layers — built for villas, boutique hotels, retreats and multi-property hospitality operators across Bali and APAC.

Built around the systems you already use — not as a forced PMS replacement.

Discuss a booking platform →WhatsApp the team →Start with System Mapping →
01 · Why a stronger booking layer matters

OTAs remain useful. A stronger direct booking journey is an additional owned channel.

OTAs are valuable acquisition channels for many hospitality operators. A stronger direct-booking journey gives the business an additional owned channel, a clearer booking experience, better attribution and more control over repeat-guest relationships.

  • Actual commission exposure and direct-channel opportunity depend on each operator's channel mix, agreements, occupancy and marketing strategy. Platform fees and commission structures vary by OTA, agreement and participation programme — we review the operator's real channel mix during System Mapping rather than relying on generic estimates.
  • We build the booking layer that connects to the systems already running your operation — PMS, channel manager, payment provider, communication channels — without forcing a replacement of what already works.
  • This page covers the booking and guest-journey layer.
  • For deeper systems, see Custom Websites & Lead Systems, CRM & Sales Operations, Internal Tools & Analytics, and Custom Platforms & Backend Engineering.
02 · Operational scenarios that bring operators to us

Typical booking-platform problems we solve.

01 · Weak direct journey

The direct website journey is weak

Visitors arrive from search, social or referrals but rarely complete a booking on your own site — slow mobile, unclear pricing, contact-form-only flow, or a generic widget that does not match the brand. We rebuild the customer-facing booking journey with mobile-first UX, clearer availability and pricing display, structured booking steps and analytics on the actual conversion path.

→Discuss the booking journey
02 · Generic PMS widget

The PMS widget does not match the brand

Cloudbeds, Guesty, Lodgify, Mews or similar tools work for operations, but their booking widgets are often hard to brand and limited from a guest-experience perspective. We build a custom booking front-end connected to the existing PMS where API access allows it, so the operational stack stays in place while the guest-facing journey is rebuilt.

→Discuss a PMS-connected layer
03 · Multi-property fragmented

Multi-property booking is fragmented

Multi-villa operators and small hospitality groups often end up with separate pages, separate widgets, inconsistent pricing and no unified booking experience. We build portfolio-level booking with shared inventory presentation, consistent UX, role-based operator access and property-level reporting inputs where required.

→Discuss multi-property scope
04 · Retreats don't fit nightly logic

Retreat programmes do not fit nightly-stay logic

Multi-day programmes, group enquiries, deposit stages, pre-arrival workflows and accommodation coordination do not map cleanly onto a standard room-night booking flow. We design a programme-based booking journey alongside or instead of the standard nightly flow, with the right intake, payment and pre-arrival steps for retreats and longer-format hospitality.

→Discuss retreat scope
05 · Manual post-booking journey

The post-booking guest journey is manual

After a booking is confirmed, the rest of the guest journey runs in WhatsApp threads, Google Sheets and email — pre-arrival information, add-on requests, communication preferences, special arrangements. We build a guest portal and pre-arrival workflow around the confirmed booking, so the team is not rebuilding the same handover for every reservation.

→Discuss the guest workflow
03 · Platform modules

Six core modules.

Most operators start with three or four modules, then expand as direct revenue and operational complexity grow.

01 · MODULE

Direct booking journey

  • Mobile-first search and selection flow
  • Property, room or programme presentation
  • Availability and pricing display where supported
  • Booking or reservation submission
  • Confirmation journey
  • Conversion analytics
02 · MODULE

PMS-connected booking layer

  • PMS or booking-tool connection where API access allows
  • Rates and availability retrieval
  • Reservation submission or handoff where supported
  • Booking-status updates
  • Error handling and fallback logic
  • Integration capability depends on the client's PMS, subscription level and API access
03 · MODULE

Guest portal & pre-arrival workflow

  • Booking and confirmation details
  • Arrival information
  • Guest forms approved for the operation
  • Add-on requests
  • Communication preferences
  • Post-booking journey
  • AI-assisted inquiry triage and multilingual guest replies (EN/ID + APAC), held for human review
  • WhatsApp inquiry routing into the guest workflow — UU PDP-aware data handling
04 · MODULE

Multi-property booking administration

  • Portfolio-level availability presentation
  • Property comparison
  • Unified booking experience
  • Role-based operator access
  • Booking overview
  • Property-level reporting inputs
05 · MODULE

Payments and international guest journey

  • Supported payment-provider connection
  • Currency display where relevant for international audiences
  • Payment-status workflow
  • Refund-state visibility
  • Multilingual booking structure
  • Communication-channel integration where scoped
06 · MODULE

Analytics and distribution readiness

  • Conversion events
  • Booking-source attribution
  • Direct-channel reporting
  • Eligible Google travel integration assessment
  • Repeat-guest journey reporting where consent and data rules allow
  • Operational records and booking audit trail

Relevant hospitality use cases

  • Villa portfolioSingle villa or small portfolio — consistent presentation, direct booking journey and PMS-connected reservations across the properties.
  • Boutique hotelBranded booking layer on top of an existing PMS, with room-type structure, multilingual journey and clean post-booking guest handoff.
  • Retreat programmeProgramme-based booking — multi-day programmes, group booking enquiries, pre-arrival workflows, accommodation coordination and payment stages alongside or instead of nightly logic.
  • Multi-property operatorPortfolio-level booking platform with shared inventory presentation, role-based operator access, property-level reporting inputs and consistent guest experience across properties.
04 · Where we fit in your existing stack

Your PMS stays. We build the booking layer on top.

The tools running your operation usually stay with their vendors. We build the booking and guest-journey layer that connects to them where API access allows. Integration capability depends on the client's PMS, channel manager, subscription level, API access, supported booking flow and provider approval requirements — these dependencies are verified during System Mapping before build scope is confirmed.

↻ STAYS WITH VENDORS

What stays with your vendors

  • PMS
  • Channel manager
  • Payment processor
  • OTA and aggregator channels
  • Existing CRM
  • Marketing tools
  • Communication channels
+ WE BUILD

What we build

  • Direct booking journey
  • PMS-connected booking layer
  • Guest portal and pre-arrival workflow
  • Multi-property booking administration
  • Payment-status and refund workflows
  • Multilingual booking structure
  • Eligibility-based Google travel readiness
  • Operational records and booking audit trail
⌗ COMMON STACK

Common delivery foundation

  • Next.js · TypeScript · Node.js · PostgreSQL
  • Cloudbeds / Guesty / Lodgify / Mews / SiteMinder booking-engine APIs where available
  • Stripe / Xendit / Midtrans where payments are in scope
  • Headless CMS for marketing and content surfaces
  • Analytics and attribution
  • Vercel / Cloudflare hosting under client account
  • Sentry / Better Stack for observability
  • PMS, channel-manager, payment and integration tools are selected around project scope, client ownership and existing systems.
05 · Architecture principles

Five principles for booking platform design.

Direct booking is a customer journey, not a button

A booking platform is not a 'Book Now' button. Mobile speed, content clarity, availability honesty, confirmation flow and post-booking handoff are all part of the journey — and what determines whether direct traffic actually completes a reservation. And increasingly, direct booking has to be legible to AI travel assistants too: as guests plan through ChatGPT, Perplexity and AI Overviews, we structure availability, pricing and property data so your direct channel can surface in those answers — instead of bookings quietly routing back through the OTAs at the AI-planning stage.

Existing PMS can stay

Cloudbeds, Guesty, Lodgify, Mews and similar tools can stay where they are working operationally. We build the customer-facing booking layer on top of the existing operational stack rather than forcing a PMS replacement.

Integrations are validated before build

PMS, channel-manager and payment-provider capabilities differ by subscription level, API access and provider approval requirements. We verify integration scope during System Mapping so the build is grounded in what is actually possible, not in vendor marketing claims.

Guest workflows require clear data handling

The booking platform manages real guest information. We structure the platform around consent-based guest communication workflows, approved guest fields, and clean audit trail for booking, payment and modification history — rather than treating guest data as a free operator asset.

Ownership and documentation matter

Code lives in your GitHub, infrastructure is deployed under your accounts, and the system is documented end-to-end. Continuing with us after launch is optional, not enforced by vendor lock-in.

06 · Why H-Studio

Why hospitality operators work with us.

01

Custom booking layer, not generic widget

Generic widgets can work at the beginning. Custom booking infrastructure becomes valuable when brand, conversion, multi-property structure, multilingual journeys, payment flows or operational records need more control.

02

PMS-aware, not PMS replacement

We connect to the PMS you already use where API access and business logic allow it. The PMS remains operational. The booking layer improves the guest-facing experience and the post-booking workflow.

03

Bali-aware delivery context

We build around the actual Bali operating context: local payment providers, IDR-led settlement, international guests, multi-property portfolios, and adviser-led legal and tax responsibilities that stay with the operator.

04

Conversion- and journey-focused

We measure platforms by booking completion, direct-channel share, post-booking workflow clarity and operator dashboard usefulness — not by feature count or marketing surface area.

05

Code ownership and documentation

Code lives in your GitHub, infrastructure runs under your accounts, the system is documented. Continuing with us after launch is optional, not forced by proprietary platform lock-in.

07 · When a custom booking layer is worth it

When a custom booking layer is worth it.

Your existing setup may be enough when
Standard PMS widgets, contact forms or simple booking pages can be a reasonable fit when booking volume is low and guest journeys are simple.
A custom booking layer becomes valuable when
The booking and post-booking journey needs to do real operational work, scale across properties and connect cleanly to existing systems.
PMS booking widget
Standard booking UX works for the brand
You need stronger presentation, conversion measurement or multilingual journeys
Website enquiry form
Bookings are manually qualified and low volume
Guests should see availability or complete a structured booking journey
Separate property pages
Portfolio is small and simple
Availability, property comparison and operator visibility need consistency
Standard retreat form
Programmes are occasional
Scheduling, deposits, group bookings and pre-arrival workflows are operationally central
Manual post-booking journey
Guest handoff fits in WhatsApp and email
Pre-arrival, add-ons and guest communication need a structured guest portal
08 · FAQ
  1. 01

    Is this a replacement for our PMS or channel manager?

    No. The booking and guest platform sits on top of the operational stack you already use. PMS and channel-manager replacement is out of scope — we build the customer-facing booking layer and the post-booking workflow around them.

  2. 02

    Which PMS or booking tools can you integrate with?

    Where API access is available and the integration is supported by the provider, common candidates include Cloudbeds, Guesty, Lodgify, Mews and SiteMinder. Actual integration capability depends on the client's PMS, subscription level, API access and provider approval — confirmed during System Mapping before scope is finalised.

  3. 03

    What happens if our PMS has limited API access?

    We design around the limitation. That can mean partial integration, import/export workflows, a lighter MVP, a webhook-based handoff, or a recommendation to upgrade or change the PMS before building deeper infrastructure. We will not promise integrations the provider does not actually support.

  4. 04

    Can the platform support villas, hotels and retreat programmes?

    Yes. We design booking flows around the actual operation — nightly room or villa bookings, multi-day programme bookings, group enquiries or a mix — rather than forcing a single template across all property types.

  5. 05

    Can the booking journey support multiple languages or display currencies?

    Yes. Multilingual booking structure with separate URLs and hreflang annotations, and currency display for international guests, can be scoped around the actual source markets. Payment settlement and reporting follow the operator's approved payment-provider and accounting setup.

  6. 06

    Can you connect payments and post-booking guest workflows?

    Yes. Payment-provider integration (Stripe, Xendit, Midtrans and similar where supported), payment-status workflows, refund-state visibility, guest portals and pre-arrival workflows can be scoped on top of the booking layer.

  7. 07

    Can eligible properties connect with Google travel surfaces?

    For eligible operators, we can assess the website and data foundations required for Google Vacation Rentals or relevant hotel booking-link integrations. Eligibility, feed requirements and connectivity route are verified during System Mapping — it is not a guaranteed module on every project.

  8. 08

    What happens if we change PMS or extend the platform later?

    The booking layer is designed to reduce lock-in: code in your GitHub, hosting under your accounts, documented integration points. A PMS change still requires integration work, but the customer-facing booking journey and post-booking workflow do not have to be thrown away.

  9. 09

    Can you add AI to our guest and sales workflows?

    Yes — inside the systems you already run, not as a separate product. Common cases: WhatsApp inquiry triage, multilingual guest replies across EN/ID and APAC languages, and inquiry summaries — always with human review before anything reaches a guest.

  10. 10

    Is it safe for guest data under Indonesian law?

    Guest data is personal data under UU PDP. We build for compliant handling — lawful basis, consent, privacy notices and attention to where data is processed, since foreign AI models mean cross-border transfer. We can keep guest-data processing in-region or use models that don't export it where sensitivity requires. Legal interpretation stays with your Indonesian advisers.

09 · How to engage

Start with the booking journey and integration reality.

Most operators begin with System Mapping, then move into the platform scope that fits their PMS access, guest journey and operational priorities. Commercial scope is prepared around integration access, booking logic, payment requirements and operational complexity rather than public fixed packages. Delivery timeline is defined after System Mapping and depends on PMS access, payment scope, content readiness and integration dependencies.

01

System Mapping

We review your current website and booking path, PMS or booking tools, channel-manager dependencies, payment setup, guest journey, integration access and direct-channel priorities.

Scoped
├1 week┤

Output: written assessment, integration dependencies and recommended delivery roadmap.

02

Direct Booking Journey

For operators who need a stronger customer-facing booking experience connected to an existing operational setup.

Scoped
├4–8 weeks┤

Output: scoped booking journey with mobile-first UX, structured booking path, analytics and approved integration points.

Most chosen scope
03

Booking & Guest Platform

For operators who need booking functionality together with guest portals, pre-arrival workflows, payment-status visibility or multilingual journeys.

Scoped
├6–12 weeks┤

Output: production-ready booking and guest platform with documentation and handover setup.

04

Multi-Property Booking Platform

For hospitality operators managing several properties, accommodation types or brands through a connected booking experience.

Scoped
├8–16 weeks┤

Output: portfolio-level booking platform with operator visibility, defined integrations and scalable content/data structure.

05

Engineering Partnership

For continuing improvements after launch: integration changes, new properties, guest-flow enhancements, analytics, performance work and platform expansion.

Scoped
├month-to-month┤

Output: ongoing senior engineering support against an agreed roadmap.

What is included

  • Senior-led engineering delivery
  • Booking UX and front-end build
  • PMS / channel manager integration where API access allows
  • Payment-provider integration where in scope
  • Analytics and attribution setup
  • Documentation
  • Code ownership
  • Deployment and handover setup

What is not included

  • PMS, channel-manager or payment-provider subscription fees
  • Google Hotel Ads or paid-media budget
  • OTA fees
  • Photography or video production
  • Brand identity unless scoped separately
  • Translation, legal review or local-language editorial approval unless scoped separately
  • Ongoing content publishing or SEO campaign management unless agreed separately
  • Legal, licensing, tax or payment-licence advice
10 · Next step

Start with a booking layer that fits the operation.

We map your current booking flow, PMS, channel-manager dependencies, payment setup, guest journey and integration access before build. You receive a written assessment with integration dependencies and a recommended delivery roadmap — usable with us or another engineering team.

Related services
Related industries
Studio
H-Studio Indonesia
Bali · APAC engineering
Office: CLN Building, Jl. Batu Bidak 88B, Kerobokan Kaja, Bali 80361
Contact
WhatsApp: +49 176 41762410
Email: hello@h-studio.id