Bahay Liwanag — engineering a booking operation on GoHighLevel

Small hospitality operations usually fail not because the business lacks demand, but because the booking process is scattered across forms, messages, calls, and spreadsheets. A guest inquiry arrives in one place, details get copied elsewhere, and follow-up depends on someone remembering who was contacted, what dates were discussed, and what the next step was.

This is especially problematic for a boutique property with multiple room types and a human-led availability review. The project needed to create one intake path that captured the right data once, kept it visible to the team, and preserved the hospitality touch without letting the coordination work consume the whole operation.

The work covered the full decision path rather than a single surface area. My responsibilities included:

• Defining the guest journey and the operational flow behind it.
• Designing the booking funnel so each page had a clear purpose and a single destination.
• Structuring the GoHighLevel form and custom field schema to match the actual business use case.
• Mapping the handoff between the booking intake and the operational layer, including how the response is logged and reviewed.
• Choosing the stack and tooling based on the operational constraints rather than a generic “automation” preference.

The system architecture keeps the guest-facing experience simple while pushing the operational complexity behind the scenes. The design makes the booking funnel public, stores the lead in GoHighLevel, and then moves the inquiry into a workflow and logging layer that supports the human review stage.

This is the foundation that makes the rest of the operating model viable: the public experience is intentionally light, while the internal process is structured enough to keep the business coherent.

The booking flow is intentionally simple for the guest and disciplined behind the scenes. The public intake captures the enquiry, the CRM stores the structured record, and the workflow handles acknowledgement and routing before a human checks availability and confirms the next step.

This is the same operating model introduced in the system architecture above, applied to the day-to-day booking process the business depends on.

The project faced a few practical constraints that shaped the design. These are not abstract problems; they are real product and operational trade-offs that had to be resolved in the booking model.

• Operational complexity without overbuilding the platform. The business needed a transaction path that handled enquiries, timing, and review without creating a full custom application.
• Human review required before final confirmation. Because the property manages limited villa inventory, an automated booking decision would create unnecessary risk and reduce trust in the process.
• Limited surface area on the form. The guest-facing booking experience needed to be simple, and the public form reflects that by keeping the intake clear without forcing a full payment or trip-planning flow.
• Need for a clean operational record. A CRM contact alone was not enough; the team needed a working reservations log where the enquiry could be followed and reviewed in context.
• Platform constraints within GoHighLevel. The project had to work inside the constraints of the platform while still designing a defensible business process rather than a purely aesthetic funnel.

The project improved the business by creating a more structured reservation process without turning the guest experience into a heavy operational interface. The core value was operational clarity: the intake path, CRM record, and follow-up workflow all align around the same booking decision.

Qualitatively, the system reduces manual duplication, makes the booking process easier to review, and gives the operation a clearer internal path from enquiry to confirmation. It also improves maintainability by separating the customer-facing experience from the internal process, and it makes the customer journey easier to follow because the next step is always explicit.

This gallery packages the live-system evidence that supports the narrative. It is intentionally explicit about what is already verified and what still needs a final capture pass before publication. Nothing here is presented as a screenshot or workflow artifact that has not been documented as part of the evidence checklist.