1. 호텔 웹사이트를 Airbnb 및 Booking.com이 사용하는 동일한 호텔 PMS 인벤토리에 연결된 또 다른 실시간 판매 채널로 취급하세요.
2. 양방향 예약, 객실 요금 및 가용성 업데이트를 위해 채널 매니저 또는 지원되는 직접 연결을 사용하세요. 별도의 웹사이트 캘린더는 수작업을 늘리고 오버부킹 위험을 초래합니다.
3. 객실 유형과 요금제를 매핑하고, 단일 진실 공급원(SSOT)을 정의하며, 모든 채널에서 예약 및 취소를 테스트하고, 출시 후 실패한 업데이트를 모니터링하세요.
직접 예약 웹사이트 OTA 동기화는 호텔 웹사이트에서 판매된 객실이 Airbnb 및 Booking.com에서 판매 가능한 객실 수에 즉각적으로 영향을 미쳐야 함을 의미합니다. 반대의 경우도 작동해야 합니다. OTA 예약이 발생하면 다른 고객이 동일한 객실을 예약하기 전에 직접 예약 페이지의 가용성이 감소해야 합니다.
세 개의 독립적인 캘린더를 유지하지 마세요. 예약 엔진, 숙소 관리 시스템(호텔 PMS) 및 채널 매니저는 요금, 제한 사항, 예약 및 예외 사항에 대한 명확한 규칙을 가진 하나의 루프를 형성해야 합니다.
이 가이드는 숙소 소유자의 운영 관점에서 해당 루프를 설명합니다.
직접 예약 웹사이트 OTA 동기화 아키텍처
호텔 PMS는 호텔의 객실 구조와 예약 기록을 보유해야 합니다. 예약 엔진은 호텔 웹사이트에 실시간 객실과 요금을 표시합니다. 채널 매니저는 Airbnb, Booking.com 및 기타 온라인 여행사(OTA)와 지원되는 데이터를 교환합니다.
일반적인 흐름은 다음과 같습니다:
고객 직접 예약 → 예약이 호텔 PMS에 입력됨 → 객실 유형 인벤토리 감소 → 채널 매니저가 Airbnb 및 Booking.com에 새로운 가용성 전송
OTA 예약은 역순을 따릅니다:
고객 OTA 예약 → 예약이 호텔 PMS에 입력됨 → 인벤토리 감소 → 호텔 웹사이트 및 기타 연결된 채널이 새로운 수량을 수신함
대부분의 설정에서 각 채널은 호텔 PMS와 채널 매니저 또는 통합 플랫폼을 통해 데이터를 교환합니다.
웹사이트와 OTA 간에 동기화해야 할 사항
공유 소스 데이터와 채널별 콘텐츠를 분리하세요.
가용성과 예약은 오류 발생 시 마지막 남은 동일한 객실이 두 번 판매될 수 있으므로 가장 강력한 제어가 필요합니다. 객실 요금과 제한 사항도 중요하지만, OTA가 자체 프로모션, 수수료, 세금 표시, 할인 또는 지원되지 않는 규칙을 적용할 경우 고객에게 보여지는 결과는 다를 수 있습니다.
Smart Order는 자사의 호텔 예약 시스템을(를) 호텔 PMS 인벤토리 및 호텔 채널 매니저와(과) 연결합니다. 직접 예약은 운영 캘린더에 입력되고, 지정된 객실 풀을 줄이며, 연결된 OTA 채널로 수정된 가용성을 전송합니다.
직접 예약 및 OTA 인벤토리를 하나의 예약 루프로 유지하세요
모든 예약이 동일한 실시간 객실 인벤토리를 업데이트하도록 호텔 웹사이트, 호텔 PMS 및 OTA 채널을 연결하세요.
단일 진실 공급원(SSOT) 선택하기
연결하기 전에 직원이 각 값을 관리할 위치를 결정하세요. 일반적인 구조는 다음과 같습니다:
- 호텔 PMS 또는 채널 매니저가 객실 유형, 기본 요금, 가용성 및 지원되는 제한 사항을 제어합니다.
- 예약 엔진은 승인된 직접 예약 특가를 읽어와 직접 예약을 호텔 PMS에 기록합니다.
- Airbnb와 Booking.com은 지원되는 업데이트를 수신하는 동시에 필요한 경우 채널별 콘텐츠, 프로모션, 수수료, 정책 또는 재정의(Override)를 유지합니다.
여러 직원이 세 개의 엑스트라넷에서 동일한 기본 가용성을 변경하게 두지 마세요. 장애 발생 시 수동 편집이 적절할 수 있지만, 이후 문서화하여 원본 소스와 대조 및 조정해야 합니다.
진실 공급원에 대한 결정에도 책임자가 필요합니다. 한 사람이 객실 매핑, 요금 로직, 의도적인 채널 할당 및 연결된 상품의 변경 사항을 승인해야 합니다.
가용성은 동일한 물리적 인벤토리를 사용해야 합니다
호텔이 물리적으로 배정할 수 있는 객실부터 시작하세요. 고객 입장에서 상호 교환이 가능한 경우에만 객실을 하나의 판매 가능한 유형으로 그룹화하세요.
숙소에 4개의 디럭스 킹 객실이 있다고 가정해 보겠습니다. 웹사이트와 OTA의 유연한 요금 및 환불 불가 특가는 서로 다른 요금제지만 여전히 동일한 4개의 객실에서 차감됩니다. 하나의 요금제로 판매되면 해당 객실 풀에 연결된 다른 모든 특가의 가용성도 줄어들어야 합니다.
직접 예약 페이지에 자체 할당량이 있거나 두 OTA 상품이 동일한 물리적 객실의 별도 복사본을 가리킬 때 문제가 발생합니다. 소프트웨어에는 성공적인 업데이트로 표시되지만 통합된 채널에서는 실제 존재하는 것보다 더 많은 객실을 판매할 수 있습니다.
예약이 적은 날짜, 매진 임박 날짜, 고장 난 객실 및 마지막 남은 가용 객실을 테스트하세요. 직접 예약 웹사이트 OTA 동기화는 각 이벤트가 올바른 공유 수량을 변경할 때만 신뢰할 수 있습니다.
요금 동기화가 항상 동일한 공개 가격을 의미하지는 않습니다
기본 요금 소스를 선택하고 채널 조정 사항을 문서화하세요. 호텔은 의도적으로 직접 예약 전용 특가를 게시하거나, OTA 마크업을 추가하거나, OTA 프로모션을 유지하거나, 다른 취소 조건을 사용할 수 있습니다.
동기화 목표는 승인된 요금 전략을 반영하는 것이지, 모든 화면에 반드시 동일한 숫자를 표시하는 것은 아닙니다. 각 객실 및 요금제에 대해 다음을 확인하세요:
- 어느 시스템이 기본 요금을 보유하는지
- 채널 요금이 고정인지, 파생인지 또는 조정되었는지
- 어떤 세금, 수수료, 식사, 투숙 인원 요금 및 할인이 표시되는 총액에 영향을 미치는지
- 연결 시 어떤 제한 사항을 지원하는지
공개 웹사이트, Airbnb 및 Booking.com에서 1박 및 다박 검색을 확인하세요. 호텔 PMS에서 전송한 요금뿐만 아니라 고객이 보는 총액과 조건을 비교하세요.
상위 요금이 변경되면 파생된 모든 직접 예약 및 OTA 요금을 확인하세요. 성공적인 기본 가격 업데이트가 하위 요금 계산이나 공개 총액이 올바르다는 것을 증명하지는 않습니다.
Airbnb와 Booking.com의 연결 방식은 다르게 작동합니다
Airbnb는 공식적으로 모든 항목 동기화와 가격 및 가용성만 동기화하는 두 가지 소프트웨어 동기화 옵션을 지원합니다. 가격 및 가용성 동기화를 사용하면 호스트는 Airbnb 내에서 숙소 콘텐츠와 예약 설정을 유지할 수 있으며 로컬 재정의(Override)가 가능할 수도 있습니다. 숙소 소유자는 어떤 필드가 호텔 PMS에서 제어되고 어떤 필드가 Airbnb 측에 남아 있는지 알아야 합니다.
Booking.com은 개별 숙소가 직접 API 연결을 구축하기보다는 일반적으로 채널 매니저를 통해 연결한다고 명시합니다. 연결 도구는 요금과 가용성을 지원하지만, 다른 기능은 제공업체의 연결 및 숙소 설정에 따라 달라집니다.
이것이 '두 채널 모두에 연결됨'이 완벽한 운영 규칙이 아닌 이유입니다. 각 플랫폼의 가용성, 객실 요금, 제한 사항, 콘텐츠, 프로모션, 세금, 결제, 예약 변경 및 취소에 대한 소스를 보여주는 간단한 제어 시트를 유지하세요.
Airbnb의 캘린더 전용 iCal 연결이 완벽한 양방향 API 연결과 동일하다고 가정하지 마세요. 캘린더 피드는 차단된 날짜에 중점을 둘 수 있으며, 동일한 범위 내에서 요금, 제한 사항, 예약 세부 정보 또는 업데이트를 교환하지 못할 수 있습니다.
인벤토리를 오픈하기 전에 객실 유형 및 요금제를 매핑하세요
매핑은 시스템에 어떤 상품이 동일한지 알려줍니다. 호텔 웹사이트의 '디럭스 킹'은 Booking.com에서 '슈페리어 더블룸'으로 불릴 수 있으며 Airbnb에서는 다른 제목을 가질 수 있습니다. 이름은 다를 수 있지만 물리적 객실의 약속은 일치해야 합니다.
활성화된 모든 상품에 대해 객실 풀, 최대 투숙 인원, 침대 구성, 전망 또는 카테고리 약속, 요금 조건, 취소 정책, 식사 및 결제 방법을 확인하세요. 그런 다음 각 요금제를 의도한 특가에 매핑하세요.
단순히 두 요금이 동일한 객실을 사용한다는 이유만으로 환불 가능한 웹사이트 요금을 환불 불가 OTA 요금에 매핑하지 마세요. 가용성 풀은 공유될 수 있지만 가격과 정책은 별도로 유지되어야 합니다.
매핑되지 않은 OTA 상품은 닫거나 해결하세요. 잊혀진 숙소 목록은 직접 예약 웹사이트 OTA 동기화 워크플로우 외부에서 계속 판매될 수 있습니다.
지연, 실패 및 수동 재정의(Overrides) 이해하기
'실시간'은 운영 목표일 뿐, 전송 상태를 무시해도 된다는 뜻은 아닙니다. 업데이트는 여러 시스템을 통해 이동하며, OTA는 매핑, 인증 정보, 속도 제한, 지원되지 않는 제한 사항 또는 채널 측 유지 관리로 인해 메시지를 거부하거나 지연시킬 수 있습니다.
호텔 PMS 또는 채널 매니저는 실패한 업데이트, 영향을 받는 날짜 및 상품, 재시도 상태, 직원이 대응할 수 있는 충분한 세부 정보를 보여주어야 합니다.
간단한 인시던트 규칙을 만드세요:
- 영향을 받는 객실, 요금, 날짜 및 채널을 식별합니다.
- 즉각적인 초과 판매(오버부킹) 위험이 있는 경우 인벤토리를 수동으로 보호합니다.
- 임시 OTA 재정의(Override)를 기록합니다.
- 소스 또는 매핑 오류를 수정합니다.
- 재전송하거나 승인된 재시도를 기다립니다.
- 모든 공개 채널을 대조 및 조정하고 임시 재정의를 제거합니다.
내부 캘린더가 변경되었다고 해서 업데이트가 성공했다고 단정하지 마세요. 공개된 예약 페이지가 최종 판매 창구입니다.
모든 경로를 통해 테스트 예약 실행하기
위험도가 낮은 미래 날짜를 사용하고 시작 가용성, 요금, 제한 사항 및 공개 총액을 기록하세요. 그런 다음 직접 예약 1건, Airbnb 예약 1건, Booking.com 예약 1건을 최소한 실행해 보세요.
모든 예약에 대해 정확한 호텔 PMS 객실 유형, 요금제, 날짜, 고객, 출처, 외부 ID, 가격, 결제 상태 및 정책을 확인하세요. 호텔 웹사이트와 두 OTA 모두에서 가용성이 떨어지는지 확인하세요.
지원되는 경우 날짜와 투숙 인원을 수정하세요. 예약을 취소하고 기존 호텔 PMS 기록이 중복 없이 변경되는지, 가용성이 정확히 한 번 복구되는지 확인하세요.
마지막 객실을 별도로 테스트하세요. 남은 객실 수를 1개로 설정하고 예약을 완료한 후, 모든 곳에서 상품이 마감되는지 확인하세요. 각각의 구별된 물리적 인벤토리 풀과 특이한 제한 사항 또는 결제 조건이 있는 요금에 대해 반복하세요.
예약 ID, 타임스탬프, 스크린샷, 예상 결과, 실제 결과 및 해결 노트를 저장하세요. 수정 후에는 전체 루프를 다시 테스트하세요.
출시 후 동기화 모니터링하기
처음 48시간 동안 새롭게 생성, 변경 및 취소된 모든 예약과 향후 30일간의 가용성을 검토하세요. 판매가 활발한 기간에는 실패 로그를 여러 번 확인하세요.
안정화된 후에는 매일 알림을 모니터링하고 공개 요금 및 객실 가용성을 정기적으로 감사합니다. 호텔이 객실을 추가하거나 이름을 바꾸고, 요금을 출시하고, 투숙 인원별 가격을 변경하고, 제한 사항을 수정하고, 새로운 OTA를 연결하거나, 채널 매니저를 교체할 때마다 다시 테스트하세요.
원인별로 인시던트를 추적하세요. 반복되는 매핑 오류, 수동 재정의, 누락된 취소, 오래된 인벤토리 또는 거부된 요금은 단순한 불운이 아니라 구성 또는 책임 소재의 문제를 나타냅니다.
자주 묻는 질문
호텔 웹사이트를 Airbnb 및 Booking.com과 직접 동기화할 수 있나요?
일반적으로 호텔 웹사이트의 예약 엔진은 호텔 PMS 및 채널 매니저에 연결되며, 채널 매니저가 지원되는 OTA 연결을 관리합니다. Booking.com은 숙소가 채널 매니저를 통해 연결하도록 안내하는 반면, Airbnb는 승인된 호텔 PMS 또는 채널 매니저 소프트웨어 연결을 지원합니다.
직접 예약 후 무엇이 업데이트되어야 하나요?
예약은 호텔 PMS에 입력되고, 정확한 객실 유형의 인벤토리를 줄이고, 운영 캘린더를 업데이트하며, Airbnb, Booking.com 및 기타 연결된 채널로 수정된 가용성을 전송해야 합니다.
요금이 모든 곳에서 동일해야 하나요?
아닙니다. 호텔은 직접 예약 특가, 채널 조정 또는 OTA 프로모션을 사용할 수 있습니다. 소유자는 의도한 관계를 정의하고 고객이 보는 최종 총액, 정책 및 제한 사항을 확인해야 합니다.
이중 예약(오버부킹)을 방지하는 데 iCal만으로 충분한가요?
iCal은 캘린더의 차단 일정은 교환할 수 있지만, 전체 API 연결과는 그 범위와 업데이트 동작이 다릅니다. 공급자와 함께 타이밍, 필드 및 한계를 확인하고, 요금이나 세부 제한 사항까지 동기화한다고 가정하지 마세요.
OTA 동기화는 얼마나 자주 테스트해야 하나요?
출시 전, 그리고 객실, 객실 요금, 제한 사항, 투숙 인원, 매핑 또는 통합 설정이 변경된 후에 테스트하세요. 매일 알림을 모니터링하고 주기적으로 마지막 객실 확인을 실행하세요.
단일 인벤토리 소스, 3개의 판매 채널
신뢰할 수 있는 직접 예약 웹사이트 OTA 동기화는 단일한 물리적 인벤토리 구조, 승인된 매핑, 명확한 요금 소유권, 지원되는 연결 및 눈에 띄는 실패 처리에 달려 있습니다.
직접 예약 웹사이트를 별도의 캘린더가 아닌 실제 채널로 취급하세요. 모든 예약이 동일한 호텔 PMS 기록에 입력되고 Airbnb 및 Booking.com 전체에 걸쳐 가용성 업데이트를 트리거할 때, 호텔은 수동 인벤토리 작업을 추가하거나 피할 수 있는 초과 판매 발생 구간을 만들지 않고도 직접 예약 판매를 성장시킬 수 있습니다.
