Airbnb 예약 하나, 여러 이메일,
행 하나

예약 이메일에 담기는 것과 빠지는 것

예약 이메일은 발송된 그 순간에는 완전한 예약 문서지만, 그 이후의 모든 순간에는 불완전한 문서입니다. 확인 메일에는 확인 코드, 게스트 이름, 숙소, 체크인 및 체크아웃 날짜, 숙박일수, 인원, 게스트가 결제한 총액, 해당 숙박에 대한 호스트 수익, 그리고 예약 시 게스트가 남긴 메모가 담깁니다.

데이터는 메시지 본문에 있습니다. 확인 메일과 함께 캘린더 파일이 도착하더라도 그 안에는 날짜와 요약 한 줄만 있을 뿐, 확인 코드나 게스트, 금액은 없습니다. 전달 규칙을 정하기 전에 먼저 정리해야 할 점이 바로 이것입니다. 본문이 곧 문서입니다.

Airbnb는 여러 주소에서 메일을 보내기도 합니다. 알림 누락에 관한 Airbnb 자체 도움말 페이지에서는 연락처에 추가할 주소로 [email protected], [email protected], [email protected]을 명시하고 있는데, 이는 발신자 허용 목록을 만들 때 유용한 힌트입니다. 추측한 주소 하나가 아니라 Airbnb가 실제로 사용하는 주소를 허용하세요.

이메일에서 빠지는 것도 그만큼 중요합니다. 여기에는 게스트의 이메일 주소가 없습니다. 게스트의 전화번호는 예약이 확정된 후에야 확인할 수 있고, 취소가 처리되면 예약에서 사라집니다. 이 메시지에는 정산금 지급일, 예약의 현재 상태, 변경 이력이 담기지 않습니다. 이런 공백 때문에 확인 메일은 기록을 시작할 수는 있어도 기록 그 자체가 될 수는 없습니다.

확인 메일은 예약이 존재한다는 사실을 알려줍니다. 하지만 그 예약이 이메일이 발송된 당시와 여전히 같은 모습인지는 알려주지 못합니다.

하나의 예약을 바꾸는 세 가지 메시지

변경되지 않는 예약도 확인 메시지와 정산금을 생성합니다. 변경되는 예약은 첫 번째 문서와 모순되는 두 번째 문서를 생성하며, 시트가 해결해야 하는 것은 바로 그 모순입니다.

변경은 요청으로 시작됩니다. 호스트를 위한 Airbnb 도움말 페이지에서는 게스트가 여행 변경 요청을 보낼 수 있으며 확인 이메일의 링크를 통해 예약을 수정할 수도 있다고 설명합니다. 변경은 Airbnb 내에서 협의되고 적용됩니다. 더 시사적인 내용은 소프트웨어로 변경 사항을 관리하는 방법에 대한 Airbnb의 자체 안내에 있습니다. 예약 변경은 소프트웨어를 통해 수락하거나 거절할 수 없으며 Airbnb 계정에서 처리해야 합니다. PMS가 해당 이벤트를 자체적으로 흡수할 수 없다면, 변경 이메일이 캡처되지 않는 한 그 하위의 스프레드시트는 가능성이 없습니다.

취소는 세 가지 결과를 동시에 초래하는 별도의 메시지입니다. 호스트를 위한 Airbnb 도움말 페이지에 따르면 게스트가 취소하면 호스트에게 즉시 알림이 전송되고, 날짜가 차단 해제되며, 정산금과 환불이 조정됩니다. 이 중 어느 것도 새로운 예약이 아니며, 원래 확인 메시지에서 추론할 수 있는 것도 아닙니다.

정산금은 다른 주기로 운영됩니다. Airbnb의 결제 약관에 따르면 각 정산금이 개시될 때 호스트에게 이메일로 알림이 전송됩니다. 하나의 정산금이 여러 예약을 포괄할 수 있기 때문에 정산금 행과 예약 행이 일대일로 일치하는 경우는 드뭅니다.

변경 메시지는 확인 메시지보다 짧은 경우가 많습니다. 무엇이 바뀌었는지만 전달하도록 작성되며, 예약 전체를 반복하지 않습니다. 따라서 확인 메시지에서 채워지는 열이 변경 메시지에서는 비어 있을 수 있습니다. 이는 정상입니다. 변경 메시지가 반드시 전달해야 하는 필드는 확인 코드와 이벤트 유형입니다.

시트가 변경 사항을 놓치는 이유

시트가 변경 사항을 놓치는 이유는 변경이 Airbnb에서 완료되지만, 시트는 받은편지함에 도달한 내용만 알기 때문입니다.

대부분의 전달 규칙은 첫 번째 메시지를 기준으로 작성됩니다. "예약 확정"이라는 단어를 중심으로 만든 필터는 이후의 취소 관련 메시지를 잡지 못하며, 하나의 제목 줄로 만든 규칙은 하나의 이벤트만 잡습니다. 가장 중요한 메시지는 규칙을 작성한 후에 도착하는 메시지입니다.

두 번째 원인은 추가 전용 추출입니다. 처리된 각 이메일이 하나의 행이 되는데, 이는 감사 추적에는 올바른 동작이지만 상태 필드에는 잘못된 동작입니다. 이전 행을 덮어쓰지 않으므로 확인 메시지는 이전 날짜를 그대로 유지하면서도 완전해 보입니다.

세 번째는 조인 키입니다. 제목 줄은 보통 확인 코드가 아니라 게스트 이름을 나타냅니다. 코드가 없거나 다른 템플릿의 다른 위치에 있으면, 두 행이 스프레드시트에서 서로를 매칭할 공통 값을 갖지 못합니다. 결국 그럴듯한 두 개의 행만 남고 어느 것이 최신인지 판단할 규칙이 없습니다.

모든 것을 전달하면 네 번째 문제가 나타납니다. 문의, 예약 요청, 알림이 같은 게스트와 같은 날짜를 언급하므로 예약처럼 읽힙니다. 나중에 거절된 요청도 이미 행을 만들어 놓습니다. 취소된 숙박에 대한 알림은 로그에서 이전 날짜를 계속 살려둡니다.

그 결과는 특정한 유형의 오류입니다. 게스트가 2박 숙박을 이틀 미룹니다. 확인 행에는 여전히 화요일이라고 적혀 있습니다. 청소 담당자는 시트를 기준으로 청소 전환을 준비하고, 회계 담당자는 원래 숙박일수를 계산하며, 행은 완성된 것처럼 보이기 때문에 아무도 다시 확인하지 않습니다. 데이터가 잘못 입력된 적은 없습니다. 단지 이후 이벤트가 이전 행에 적용되지 않았을 뿐입니다.

예약 이메일은 이벤트입니다. 예약 시트는 기록입니다. 그 사이의 간극에 잘못된 체크인 날짜가 존재합니다.

같은 스냅샷 문제는 이커머스 주문 확인 이메일에서도 나타나며, 주소 변경이나 취소가 있어도 행은 올바르게 보이지만 배송은 잘못될 수 있습니다. 여기서의 차이는 양입니다. 쇼핑몰은 주문당 하나의 확인 메시지를 보내지만, 단기 임대는 확인, 변경, 취소, 정산금 메시지를 보내며, 각각이 같은 예약을 다른 각도에서 설명합니다.

이메일을 본문을 읽는 받은편지함으로 보내세요

진입점은 Airbnb 연동이 아니라 받은편지함 주소입니다. Email Inbox는 계정에 Airbnb 예약 이메일 전용 주소를 부여합니다. 여기로 전송되거나 전달된 모든 메일은 처리 대기열에 들어가며, 발신자 허용 목록이 관련 없는 메일을 차단합니다. Airbnb에 중요한 설정은 어디에서 읽을지 지정하는 설정입니다.

하나의 템플릿이 네 가지 메시지 형태를 모두 처리하는 이유는 매칭이 의미 기반이기 때문입니다. 따라서 확인, 변경, 취소, 정산금 메시지 각각에 파서를 두지 않고도 Airbnb 예약 데이터를 추출할 수 있습니다. 체크인 날짜를 다시 언급하지 않는 변경 메시지는 해당 셀을 추측으로 채우지 않고 비워 두는데, 이는 장부에서 원하는 동작입니다. 예약이 이메일이 아니라 스크린샷으로 도착하는 경우, 예약 스크린샷에서 확인 코드와 날짜 추출하기의 필드별 가이드가 그 입력을 처리합니다. 동일한 본문 전용 설정 덕분에 이메일 본문에 작성된 인보이스도 추출할 수 있으며, 이 라우팅 패턴의 일반적인 버전은 이메일 파서 워크플로에서 다룹니다.

모든 이벤트는 유지하고, 예약당 한 행만 표시

받은편지함에서 넘어온 테이블은 이벤트 로그이며, 그대로 유지해야 합니다. 취소 메시지가 예약이 취소되었다는 유일한 증거이기 때문입니다. 작업할 화면용으로 두 번째 탭을 추가하고, 확인 코드가 어떤 행이 해당 예약을 나타내는지 결정하게 하세요.

원본 탭에서는 처리된 모든 메시지를 도착 순서대로 유지하고 =ROW()로 순번 열을 추가합니다. 행 번호가 클수록 더 나중 메시지이며, 내보내기에 수신 타임스탬프가 없을 때 필요한 유일한 시계입니다. Google Sheets의 작업 탭에서는 수식을 원본 탭으로 지정하고, 코드 기준으로 정렬한 다음 순번 기준 최신순으로 정렬하고, 각 코드의 첫 번째 행을 유지합니다:

=UNIQUE(SORT(Emails!A2:L, 1, TRUE, 2, FALSE))

이렇게 하면 확인 코드당 한 행이 반환되며, 정렬이 최신 이벤트를 맨 위에 두므로 살아남는 행이 최신 행입니다. 변경은 날짜를 대체합니다. 취소는 상태를 대체합니다. 이전 행들은 여전히 원본 탭에 남아 있으며, 회계 담당자가 정산금이 왜 이동했는지 물을 때 필요한 것이 바로 이것입니다.

수식은 확인 코드가 A열, 순번이 B열이라고 가정하므로 열 문자를 자신의 레이아웃에 맞게 조정하세요. 작업 보기에서는 취소된 행을 유지하고, 현재 점유율 목록이 필요할 때 필터로 제외하세요. 취소 행을 삭제하면 환불에 대한 설명이 사라지고, 다음 달에는 아무도 돈이 왜 부족한지 기억하지 못합니다.

한 가지 경우는 자동으로 해결되지 않습니다. 확인 코드가 실제로 없는 메시지는 코드로 조인할 수 없으므로 원본 탭에 그대로 표시되고 수동으로 매칭됩니다. 이런 경우는 드물어야 하며, 수식이 조용히 해당 행을 버리는 것보다 고아 행을 확인하는 편이 낫습니다.

누가 어떤 열을 보는가

하나의 테이블로 호스트, 공동 호스트, 청소 담당자, 회계 담당자를 모두 지원할 수 있습니다. 단, 각자가 자신의 업무에 맞게 만든 보기를 열 때만 그렇습니다.

호스트는 중복 제거 탭에서 작업합니다. 이 탭은 점유율 기록이자 수입 기록입니다. 예약당 한 줄에 날짜, 숙박일수, 인원, 정산금, 상태가 들어갑니다. 원본 탭은 청구 내용을 확인할 때 쓰는 것이지 한 달을 계획할 때 쓰는 것이 아닙니다.

공동 호스트에게는 게스트 이름, 날짜, 인원, 그리고 게스트가 예약 시 남긴 메모가 필요합니다. 공유 시트 보기를 사용하면 Airbnb 로그인을 넘겨주지 않고도 이를 제공할 수 있습니다. 이는 공동 호스트가 일부 숙소에만 추가된 경우에 중요합니다.

청소 담당자나 운영 책임자에게는 세 가지가 필요합니다. 체크아웃 날짜, 숙소, 그리고 같은 날 다른 게스트가 체크인하는지 여부입니다. 이 사람에게는 중복 제거 탭을 안내하고, 원본 탭은 절대 안내하지 마세요. 청소 담당자가 원본 탭을 보는 것이 수정된 날짜가 다시 잘못되는 가장 흔한 경로입니다.

회계 담당자에게는 게스트 합계, 청소비, 정산금, 월이 필요하며, 취소된 행은 그대로 남아 있어야 합니다. 정산금 메시지는 별도 탭에 있어야 합니다. 하나의 정산금이 여러 예약을 포함할 수 있고, 대사는 두 가지 단위, 즉 예약과 은행 거래를 비교하는 작업이기 때문입니다. 목적지가 시트가 아니라 CRM이라면 동일한 필드 세트가 CSV 가져오기를 통해 이동합니다. 이메일을 CRM 연락처로 전환하는 패턴이 게스트 기록에 적용되며, 예약 코드가 중복을 방지하는 식별자 역할을 합니다.

이 설정이 할 수 없는 것

경계는 받은편지함입니다. 이는 Airbnb가 보내는 메일을 읽을 뿐 그 외에는 아무것도 하지 않으며, 시트를 만들기 전에 몇 가지 한계를 짚어둘 가치가 있습니다.

뒤에 Airbnb API가 없습니다. Airbnb는 호스트에게 공개 예약 API를 제공하지 않습니다. 접근 권한은 소프트웨어 파트너에게 있으며, 2025 Preferred Software Partner 목록은 Guesty, Hostaway, Hospitable, OwnerRez, Lodgify, Beds24, Uplisting, Hostfully 같은 숙소 관리 및 채널 관리 시스템으로 구성되어 있습니다. 양방향 동기화가 필요하다면 그 범주에서 구매해야 하며, 이는 스프레드시트 워크플로와는 다른 구매입니다.

캘린더나 PMS 동기화가 없습니다. Airbnb의 캘린더 내보내기는 다른 캘린더에서 날짜를 차단하는 데 사용되는 .ics 피드입니다. 이는 날짜만 담고 게스트, 코드, 정산금은 담지 않으므로 예약 기록을 대신할 수 없습니다.

Airbnb에 다시 쓰여지는 것은 없습니다. 시트는 가격을 바꾸거나, 날짜를 열거나 닫거나, 게스트에게 메시지를 보내거나, 취소를 처리할 수 없습니다. 시트는 일어난 일을 기록할 뿐 숙소를 관리하지는 않습니다.

게스트 메시징 자동화는 다른 작업입니다. "Airbnb email automation"에 대한 대부분의 결과는 예약된 답장과 메시지 템플릿에 관한 것입니다. 이는 같은 받은편지함의 데이터 측면을 다루며, 둘은 서로 간섭하지 않고 나란히 있을 수 있습니다.

이메일로 도착하지 않는 이벤트는 보이지 않습니다. 예약 알림이 꺼져 있거나, 게스트가 글 대신 전화를 하거나, 앱 스레드에서 변경이 합의된 경우 시트는 알 수 없습니다. 이메일은 플랫폼 이벤트의 사본이지 플랫폼 자체가 아닙니다.

연락처 데이터는 의도적으로 최소한입니다. 게스트 이메일 주소는 없고, 전화번호는 확인 이후에만 제공되며, 취소 후에는 전화번호가 전혀 없습니다. 이 시트를 마케팅 목록이 아닌 운영 기록으로 취급하세요.

FAQ

Airbnb와 직접 연결되나요?

아닙니다. 전용 받은편지함으로 전달한 이메일을 읽습니다. Airbnb 로그인도, API 연결도, 캘린더 동기화도 없습니다. 장점은 Airbnb가 이미 보내는 메시지에서 작동한다는 것이며, 예고 없이 변경되는 주소와 템플릿에서 온 메시지도 포함됩니다.

어떤 Airbnb 이메일을 전달해야 하나요?

확인, 변경, 취소, 정산금입니다. 문의, 예약 요청, 알림도 전체 로그를 원한다면 포함할 수 있지만 행이 추가되므로, 누군가에게 시트를 넘기기 전에 이벤트 유형으로 필터링하세요. 거절된 요청은 예약이 아닙니다.

변경 이메일과 신규 예약을 구분할 수 있나요?

네. 신규 예약은 새 확인 코드를 가지는 반면, 변경은 수정하는 예약의 코드를 재사용하며, 추론 열인 이벤트 유형 열이 어떤 종류의 메시지가 도착했는지 기록합니다. 변경 메시지에 코드가 없어도 이벤트 유형이 여전히 표시하므로, 해당 행은 직접 조인하세요.

취소하면 행이 삭제되나요?

아닙니다. 취소는 다른 상태의 행을 추가하며, 작업 탭은 해당 코드의 최신 상태를 보여줍니다. 행을 유지하세요. 누락된 정산금과 다시 열린 날짜를 설명해 주며, 예약이 단순히 사라지지 않았다는 유일한 기록입니다.

Vrbo, Booking.com 및 직접 예약에도 작동하나요?

네. 받은편지함은 어느 플랫폼이 메시지를 보냈는지 상관하지 않습니다. 다른 발신자를 허용 목록에 추가하고 동일한 열을 유지하면, 여러 채널에서 예약을 받는 포트폴리오가 하나의 테이블에 모입니다. 자체 사이트의 직접 예약 확인도 같은 방식으로 작동합니다.

완성된 테이블은 어디로 가나요?

XLSX 또는 CSV로 내보내 Google Sheets에서 열거나 가져오거나, CSV를 CRM으로 가져오세요. Google Sheets 추가 기능은 사이드바에서 업로드한 파일을 기준으로 작동하므로, 받은편지함 메시지는 대신 내보내기 경로를 따릅니다. Airbnb 예약을 Google Sheets로 가져오는 방법을 검색하셨다면, 내보내기가 마지막 단계이며, 시트가 올바른지 결정하는 작업은 그보다 앞서 열과 이벤트 유형을 정의할 때 이미 이루어집니다.

행은 어떤 메시지가 기준인지에 대한 결정입니다

Airbnb 예약은 하나의 문서가 아닙니다. 짧은 메시지의 연속이며, 시트의 행은 그중 어떤 것이 기준이 될지에 대한 결정입니다. 확인 코드가 키가 되고 최신 메시지가 살아남으면, 시트는 더 이상 받은편지함의 복사본이 아니라 어떤 날짜를 신뢰할지 경고를 덧붙이지 않고도 청소 담당자, 공동 호스트 또는 회계 담당자에게 넘길 수 있는 것이 됩니다.

변경된 예약 하나로 시도해 보세요. 확인 메일과 변경 메일을 전달하고, 열을 한 번 설정한 뒤, 뷰가 어떤 행을 유지하는지 확인하세요. 행의 날짜가 마지막 이메일의 날짜와 일치한다면, 수동 방식에서 놓치기 쉬웠던 작업을 이 설정이 제대로 해내고 있는 것입니다.