호텔 예약 웹사이트 만드는 법: 객실, 요금, 재고, 결제

호텔 예약 웹사이트를 쓰면 게스트가 날짜를 고르고, 숙박 기간의 모든 밤에 어떤 객실이 비어 있는지 보고, 총액을 확인한 뒤 결제하거나 보증금을 낼 수 있습니다. 누군가와 이메일을 주고받을 필요가 없습니다. 만들려면 객실 수가 있는 객실 유형, 밤 단위 재고 모델, 날짜에 따라 바뀔 수 있는 요금, 저장할 때 재고를 다시 확인하는 예약 흐름, 프런트 데스크용 관리 화면이 필요합니다. 어려운 부분은 예쁜 페이지가 아닙니다. 특히 예약 플랫폼에서도 판매한다면, 한 객실이 두 번 팔리지 않도록 보장하는 것입니다.

사이트에 필요한 것

페이지

• 공개 화면: 홈, 객실(사진, 침대, 크기, 편의시설, 최대 인원), 날짜와 인원 검색, 객실 유형별 총액이 보이는 결과, 예약 양식, 결제, 예약 관리 링크가 있는 확인 페이지.
• 보조 페이지: 위치와 길 안내, 정책(체크인 시간, 취소, 어린이, 반려동물), 자주 묻는 질문, 문의.
• 비공개(직원): 오늘의 도착과 출발, 밤 단위 객실 격자 캘린더, 예약 목록, 날짜 차단, 요금과 객실 설정.

데이터

체크인과 체크아웃은 시각이 아니라 날짜로 저장하고, 체크아웃은 제외 기준으로 다루세요. 10일부터 12일까지의 숙박은 10일과 11일의 밤을 씁니다. 이것을 잘못하면 가장 흔한 재고 버그가 생깁니다.

권한

게스트는 가격과 객실 유형이 예약 가능한지 볼 수 있지만, 같이 묵는 다른 사람은 절대 볼 수 없습니다. 프런트 데스크 직원은 예약과 게스트 정보를 봅니다. 요금과 정책은 소유주만 바꿀 수 있습니다. 따라서 최소 두 가지 역할이 있는 직원 로그인이 필요합니다.

결정과 트레이드오프

예약 요청 또는 즉시 예약

예약 요청(게스트가 날짜와 정보를 보내고 숙소가 이메일로 확정)은 훨씬 간단하며, 작은 게스트하우스에는 충분합니다. 즉시 예약은 재고 확인과 결제 처리가 빈틈없어야 하지만 전환율이 더 높습니다. 많은 숙소가 요청으로 시작했다가 나중에 전환합니다.

객실 유형 판매 또는 특정 객실 판매

게스트는 보통 객실 「유형」(「바다 전망 더블」)을 예약하고, 직원이 나중에 실제 객실을 배정합니다. 특정 객실을 판매하는 방식은 만들기 더 쉽지만 캘린더를 채우기 어렵게 합니다.

요금

객실 유형별 1박 가격 하나로 시작하고, 날짜 범위(성수기, 휴일)에 대한 예외 요금과 최소 숙박일을 선택적으로 두세요. 동적 가격, 프로모션 코드, 패키지는 나중으로 미루세요.

결제

선택지는 복잡도가 높아지는 순서로 다음과 같습니다. 도착 시 결제. Stripe Checkout 같은 호스팅 결제창을 통한 보증금. 환불 불가 요금의 전액 선결제. 카드를 저장해 두고 나중에 청구. 결제 규칙, 세금, 관광세는 나라마다 다르니 현지 규정을 확인하거나 전문가에게 물어보세요. 결제 가이드에서 메커니즘을 다룹니다.

기타 채널

객실을 온라인 여행사나 단기 임대 플랫폼에도 올린다면 캘린더를 계속 맞춰야 합니다. 많은 플랫폼이 캘린더를 iCal 링크로 내보내고 가져올 수 있습니다. 이 방식으로 동기화하는 것은 소규모 숙소에 흔하지만 즉시가 아니라 지연이 있습니다. 전문적인 해결책은 채널 매니저입니다.

효과가 있었던 첫 프롬프트

스코틀랜드 Tobermory에 있는 9실 규모 게스트하우스 Harbour House를 위한 직접 예약 웹사이트를 만들어 줘. 객실 유형: 더블(4실, 2명, 1박 £120), 트윈(3실, 2명, £115), 패밀리(2실, 성인 2명 + 어린이 2명, £165). 게스트는 체크인 날짜, 체크아웃 날짜, 인원으로 검색하고, 숙박 기간의 모든 밤에 빈 객실이 있는 객실 유형만 총액과 함께 본다. 체크아웃은 제외 기준이다. 7월과 8월의 최소 숙박은 2박. 예약 양식은 이름, 이메일, 전화번호, 도착 시간을 받고, 「대기」 상태로 저장하며, 저장 전에 서버에서 재고를 다시 확인한다. 로그인이 있는 직원 화면에는 오늘의 도착과 출발, 밤 단위 객실 격자 캘린더, 상태가 있는 예약 목록, 날짜를 차단하는 기능이 있다. 모든 예약 페이지에 체크인 15:00~20:00, 체크아웃 10:00, 취소 정책(7일 전까지 무료)을 표시해 줘. 차분한 해안 분위기의 디자인으로, 모바일 우선으로 만들어 줘.

빌드 단계

1. 객실과 밤 단위를 먼저 모델링. 객실 유형, 객실, 요금, 재고 확인. 디자인 작업 전에 테스트하세요.
2. 검색과 결과. 날짜 선택기, 인원 수, 숙박 전체 총액, 명확한 「매진」 상태.
3. 예약 흐름. 양식 → 서버에서 재고 재확인 → 대기 예약 → 관리 링크가 있는 확인 페이지.
4. 로그인이 있는 직원 화면: 도착, 출발, 격자 캘린더, 날짜 차단.
5. 자체 제공업체를 통한 확인 이메일: 날짜, 총액, 주소, 정책 포함. 이메일 보내기를 참고하세요.
6. Stripe 테스트 모드에서 보증금, 결제가 성공했을 때만 예약을 확정합니다. 결제 웹훅을 쓰려면 앱이 공개 URL에 게시되어 있어야 합니다.
7. 다른 채널을 쓴다면 캘린더 동기화를 하고, 처음에는 하루에 한 번 수동으로 확인하세요.
8. 경계 사례를 테스트: 두 브라우저가 마지막 객실을 동시에 예약하는 경우, 요금 변경을 가로지르는 숙박, 예약 취소로 밤이 풀리는 경우, 최소 숙박 기간 중의 1박 숙박.
9. 게시하고 기존 방식을 끄기 전에 직접 실제 예약을 해 보세요.

자주 하는 실수

• 브라우저에서만 재고 확인. 두 게스트가 결국 마지막 객실을 같은 순간 예약하게 됩니다.
• 체크아웃 날 밤을 사용 중으로 세거나(또는 체크인 날 밤을 세지 않기). 이틀 숙박에 대한 테스트를 작성하세요.
• 하나의 고정 가격. 대부분의 숙소는 최소한 계절별 예외 요금이 필요합니다.
• 결과 화면에서 총액을 마지막 단계까지 숨기기. 아는 수수료를 포함한 숙박 전체 가격을 결과에 보여 주세요.
• 정책을 바닥글에 묻어 두기. 취소 조건은 결제 버튼 옆에 보여 주세요.
• iCal 동기화를 즉시라고 여기기. 그렇지 않습니다. 거의 찼을 때는 날짜를 직접 마감하세요.

기성 제품이 더 나은 경우

객실을 여러 개 운영하거나, 여러 온라인 여행사를 통해 판매하거나, 객실 정리, 청구서, 보고서가 필요하다면 예약 엔진과 채널 매니저를 갖춘 숙소 관리 시스템이 대개 맞는 선택입니다. 이런 제품은 채널 간 이중 예약 문제를 해결하도록 만들어졌으며, 그것을 잘 재현하는 데는 비용이 많이 듭니다.

맞춤형 사이트는 주로 직접 예약을 받는 소규모 숙소, 특이한 재고(글램핑 자리, 공용 시설이 있는 오두막, 액티비티와 함께 판매하는 객실), 또는 객실당 월 요금 없이 자신만의 디자인과 게스트 경험을 원할 때 적합합니다. 맞춤형 웹사이트에 호스팅 예약 엔진을 임베드하는 숙소도 많으며, 이것이 두 가지 장점을 모두 가진 경우가 많습니다.

Mythex로 만들기

Mythex에서는 채팅으로 숙소를 설명하고, 휴대폰 크기 프레임을 포함한 실시간 미리보기에서 사이트를 검토한 뒤, 잘 작동하면 게시할 수 있습니다. 예약, 객실, 요금은 앱이 데이터를 저장해야 할 때 에이전트가 추가하는 Postgres 데이터베이스에 저장되며, 유휴 상태에서는 잠들었다가 다음 요청에서 깨어납니다. 직원 로그인, 이메일 확인, 보증금은 직접 가진 제공업체와 키에 연결됩니다. Mythex에는 최종 사용자용 로그인, 이메일, 결제 제품이 내장되어 있지 않기 때문입니다. 보증금을 추가하기 전에 Stripe 레시피를 읽어 보세요. /test로 에이전트가 검색과 예약 과정을 직접 진행하게 하고, 재고를 망가뜨리는 변경이 생기면 체크포인트로 되돌릴 수 있습니다.

시작 프롬프트가 필요하다면 호텔 예약 시스템 빌더, 게스트하우스 예약 시스템 빌더, 또는 글램핑 예약 사이트 템플릿을 보세요. 숙박 단위가 아니라 시간이나 예약 단위라면 예약 앱 가이드를 참고하세요.

자주 묻는 질문