객실이 세 개인 숙소를 운영한다고 하자. 월요일 저녁, 2호실에 오늘 하루만 묵는 손님의 예약이 들어온다. 몇 시간 뒤, 다른 예약 사이트에서 또 하나가 들어온다. 수요일부터 2박. 2호실은 월요일 밤만 비어 있고 3호실은 이번 주 내내 비어 있다. 수요일 2박짜리를 2호실에 넣으면 화요일 하루가 통째로 비어버린다. 3호실에 넣으면 비는 날 없이 그대로 이어진다.
위 그림은 이해를 돕는 단순화한 예시다. 실제로는 훨씬 다양한 경우를 맞춰야 한다.
이 둘뿐이면 머릿속으로 그려도 맞다. 그런데 목요일 저녁에 금요일 1박짜리가 또 들어오고, 토요일에는 다음 주 3박짜리가 들어온다. 예약 사이트 창을 두세 개 띄워놓고 캘린더를 번갈아 보며 어느 방이 비어 있는지, 어느 방에 넣으면 하루가 비는지 손으로 맞추는 일이 매번 반복된다.
이 판단을 예약이 들어올 때마다, 예약 사이트 두세 개를 오가며 손으로 하고 있다면, 지금 머릿속에서 하는 그 일을 대신 해주는 장치가 있다. 이름은 채널 매니저, 줄여서 CMS다.
CMS가 뭔지, 매표소에 비유하면
공연장 매표소를 떠올려보자. 같은 좌석을 온라인 창구, 전화 창구, 현장 창구에서 동시에 판다고 하면, 한 창구에서 팔린 자리를 다른 창구가 모르는 순간 같은 자리가 두 번 팔린다. 그래서 매표소는 창구마다 같은 좌석표를 실시간으로 공유한다. 에어비앤비, 야놀자, 부킹닷컴 같은 예약 사이트를 동시에 쓰는 숙소도 구조가 같다. 방 하나를 여러 창구에서 동시에 팔고 있는 셈이다.
용어: 채널 매니저(CMS)는 여러 예약 사이트의 요금과 빈 객실 정보를 하나로 모아 실시간으로 맞춰주는 시스템이다.
창구가 둘뿐이면 전화 한 통으로 맞추지만, 다섯·열로 늘어나면 전화로는 못 맞춘다. 숙소도 똑같다. 쓰는 예약 사이트가 늘어날수록, 어딘가에서 하나를 놓칠 확률이 같이 늘어난다.
손으로 맞추면 생기는 손해 세 가지
예약 사이트가 하나뿐이면 손으로도 맞출 수 있다. 두 개를 넘는 순간부터 손해가 눈에 보이게 쌓인다. 바쁜 날 하루 깜빡한 것뿐인데, 그 하루의 손해가 몇 달 뒤 정산할 때 몰아서 드러난다.
- 오버부킹. 한 사이트에서 방이 나갔는데 다른 사이트 캘린더를 아직 못 지웠을 때, 같은 날 같은 방에 또 다른 예약이 들어온다. 손님 둘을 한 방에 넣을 수는 없으니 한쪽은 급하게 다른 방이나 다른 숙소를 구해야 한다.
- 빈 구간 손해. 방과 방 사이에 하루가 뜨면 그날은 1박 손님만 받을 수 있고, 연박 손님은 아예 못 들어온다. 방 하나가 한 달에 하루씩만 더 비어도 일 년이면 꽤 쌓인다.
- 요금 불일치 손해. 주말이라 한 사이트에서 요금을 올리고 다른 사이트는 깜빡하면, 더 받을 수 있었던 요금을 놓치거나 반대로 손님이 가격 차이를 보고 항의한다. 사이트마다 수수료가 달라 체감 요금이 또 달라진다는 것은 OTA 수수료 비교에서 따로 다뤘다.
오버부킹이 실제로 어떤 경로로 생기고 CMS가 그걸 어떻게 막는지는 채널 매니저가 오버부킹을 막는 원리에 더 자세히 풀어놨다.
내 숙소에 지금 CMS가 필요한지, 체크리스트
객실 수나 매출 규모로 판단할 일이 아니다. 예약 사이트를 몇 개 쓰는지, 그걸 손으로 맞추다가 실제로 손해를 본 적이 있는지로 판단한다. 아래 중 두 개 이상에 그렇다면, CMS를 알아볼 때다.
- 손님을 받는 예약 사이트가 두 개를 넘는다.
- 하루에도 몇 번씩 다른 사이트 캘린더를 손으로 맞춘다.
- 최근 몇 달 안에 같은 날 같은 방에 오버부킹이 나서 당황한 적이 있다.
- 방과 방 사이에 하루씩 비는 날이 자꾸 보인다.
- 한 사이트 요금을 바꾸고 다른 사이트는 깜빡한 적이 있다.
CMS를 고를 때 확인할 기준
연동되는 예약 사이트의 개수와 범위, 요금과 재고가 맞춰지는 속도가 가장 먼저 볼 지점이다. 확인하는 가장 확실한 방법은 직접 테스트다. 한 사이트에서 날짜 하나를 막아보고 다른 사이트 캘린더에 몇 분 안에 반영되는지 재본다. 설명에 적힌 "실시간"과 실제 속도는 다를 수 있다. 내가 쓰는 예약 사이트가 연동 목록에 실제로 있는지도 확인해야 한다. 목록에 없으면 여전히 손으로 맞춰야 한다. 계약서 조항까지 하나씩 짚고 싶다면 계약 전 확인할 체크리스트를 같이 보면 된다.
실제 화면으로 보면, 팬지의 CMS
이 글을 쓰는 팬지픽은 Saladsoft라는 회사가 운영한다. 팬지 역시 같은 회사가 만든 숙소 운영 서비스다.
방이 하나나 둘이면 어느 방에 넣을지 머릿속으로도 어느 정도 맞춰진다. 그런데 예약 사이트는 방 하나하나가 아니라 "같은 방 종류 중 하나"로 개수만 판다. 실제 호실은 호스트가 정해야 하는데, 예약이 쌓일수록 방마다 빈 날이 조각조각 흩어진다. 전체로 보면 자리가 남는데도 날짜별로 꽉 찬 방이 하나도 없는 일이 생긴다. 같은 조건의 방을 여럿 굴리는 호스텔이라면 특히 그렇다.
팬지는 예약이 들어오면 자동으로 방을 배정한다. 비어 있는 첫 방이 아니라, 넣었을 때 다른 예약 사이에 뜨는 날이 최대한 안 생기는 방을 찾는다. 팬지는 이 기능을 스마트베스트핏이라고 부른다. 자체 개발한 방식이며, 예약이 들어올 때마다 다시 계산해 호스트가 따로 캘린더를 세지 않아도 된다.
스마트베스트핏으로 찾은 배치와 오버부킹을 막는 일은 다른 문제다. 오버부킹 방지는 "팔 수 있는 재고 자체"를 OTA마다 맞추는 일이고, 스마트베스트핏은 "이미 팔린 예약을 어느 방에 넣을지" 정하는 일이다. 팬지는 이 둘을 각각 다른 장치로 다룬다.
오버부킹을 막는 쪽은 에어비앤비, 부킹닷컴 같은 OTA 30여 개와 요금·빈 객실·예약을 실시간으로 맞추는 동기화다. 많은 서비스가 둘 다 느리다. 특히 iCal 방식은 예약이 들어온 것 자체를 가져오는 데도 몇 시간이 걸리고, 그걸 다른 채널에 막아주는 건 더 늦거나 아예 안 된다. 그 틈에 오버부킹이 난다. 팬지 사이트(panzy.site)에는 이런 문장이 있다. "30+ OTA와 양방향 동기화. 요금, 가용, 예약이 실시간으로 완벽히 동기화됩니다." 양방향이라는 건 예약도, 요금 변경이나 판매 중지도 모든 채널에 똑같이 곧장 반영된다는 뜻이다.
팬지는 CMS 외에 직판 예약 사이트, 예약과 매출과 점유율과 손님 메시지를 한 화면에서 보는 PMS, 도어락과 연동한 무인 체크인도 같이 제공한다. PMS 쪽은 이미 따로 글 한 편을 썼다. 궁금하면 거기서 이어 읽으면 된다.
흔한 오해: CMS와 PMS는 다른 도구
둘 다 "관리 프로그램"으로 뭉뚱그려 듣지만 하는 일이 다르다. CMS는 바깥의 예약 사이트들과 요금, 빈 객실을 맞추는 쪽이고, PMS는 안쪽에서 예약, 매출, 점유율, 손님 메시지를 관리하는 쪽이다. PMS만 들여놓고 OTA 연동까지 자동으로 되는 줄 알았다가, 정작 오버부킹은 그대로 겪는 호스트도 있다. 둘의 차이와 어느 쪽을 먼저 들여야 하는지는 PMS가 뭔지 쉽게 짚어본 글에 정리해뒀다.
다시, 그 방 배정으로
월요일 저녁 2호실에 들어온 1박 예약과 수요일부터 2박 예약, 둘을 어느 방에 넣을지는 더 이상 머릿속 계산이 아니다. 예약 사이트가 두 개를 넘고 방이 하나둘 늘어나는 순간부터, 그 계산은 손이 아니라 시스템이 맞추는 일로 넘어간다. 오늘 밤에도 캘린더 두세 개를 오가며 그 계산을 하고 있다면, 그 손 노동이 CMS가 대신해주는 바로 그 일이다.
