부동산 쇼잉 이메일을 하나의 시트로,
일정 변경까지 포함

쇼잉 확인 이메일에는 시간뿐 아니라 출입 정보도 담깁니다

팀에 필요한 필드는 예약이 확정되는 순간 매물 워크시트에서 생성되어 이미 이메일 본문에 들어 있습니다. 플랫폼마다 달라지는 것은 필드 구성보다 문구, 순서, 그리고 특정 필드가 이번 메시지에 포함되었는지 여부입니다.

ShowingTime은 확인 이메일에 안내 텍스트를 포함하지만, 에이전트가 요청을 확정하는 순간 그 텍스트를 수정할 수는 없습니다. 정정 사항은 별도 메시지로 발송해야 하며, 이는 쇼잉 에이전트의 받은편지함에서 다르게 보입니다(ShowingTime 안내). 각 메시지는 스냅샷이며, 정정은 첫 번째와 똑같이 보이지 않는 두 번째 스냅샷입니다.

확인 이메일은 한 건의 예약에 대한 출입 기록입니다. 이를 단순한 일정 알림으로 취급하면 키박스 위치, 안내, 코드가 받은편지함에 묻혀 버립니다.

쇼잉 하나가 여러 이메일을 만들고, 그중 확인 이메일은 하나뿐입니다

약속 하나가 누구도 매물에 발을 들이기 전에 다섯 개의 메시지를 만들어낼 수 있습니다. 요청, 확인, 알림, 일정이 바뀌면 일정 변경이나 취소, 그리고 이후의 피드백 요청입니다. 이들은 같은 플랫폼에서 비슷한 제목으로 오며, ShowingTime에서는 확인 이메일의 발신자가 플랫폼이 아니라 매도인 측 에이전트의 이름으로 표시될 수 있습니다.

토요일 투어를 운영해 본 사람이라면 이 양이 익숙할 것입니다. 한 매수인 측 에이전트는 r/realtors에서 이 경험을 "에이전트가 요청을 받았다, 요청을 봤다, 요청에 대해 생각했다, 요청 근처에서 샌드위치를 먹었다고 알려주는 이메일의 폭격"이라고 표현했습니다. 파이프라인이 "새 이메일이 들어오면 새 행을 만든다"는 식으로 구축되어 있다면, 그 메시지 하나하나가 행 후보가 됩니다.

NAR의 2025 세대별 트렌드 보고서는 매수자 측을 이렇게 보여줍니다. 매수자는 중간값으로 10주 동안 검색했고 중간값으로 일곱 채의 집을 살펴봤습니다(NAR, 2025). 일곱 채의 집이라면 최소 일곱 번의 약속이 있고, 그 집들이 사용하는 매도인 측과 플랫폼의 수만큼이나 다양합니다. 따라서 매물 하나의 시트에는 서로 다른 명명 습관과 서로 다른 플랫폼 템플릿을 가진 여러 에이전트의 메시지가 들어옵니다.

리드 이메일은 연락처 기록이 되어야 하는 문의입니다. 쇼잉 확인 이메일은 이미 존재하는 약속이며, 시트는 그것을 그대로 반영하려고 합니다. 그래서 부동산 리드 이메일 워크플로는 다른 문제를 해결합니다. 확인 이메일의 역할은 특정 시간대의 출입을 입증하는 것이며, 다섯 개의 메시지 중 이것만이 그 일을 합니다.

모든 이메일이 행이 되면, 시트는 나중에 거절된 요청, 나중에 옮겨진 확인, 출입 정보가 전혀 없는 피드백 요청으로 가득 찹니다. 남겨둘 가치가 있는 행은 확인 이메일입니다. 진실을 바꾸는 행은 취소입니다. 상태 열이 있으면 둘을 같은 사건인 척하지 않고 모두 유지할 수 있습니다.

시트와 쇼잉 시스템이 서로 어긋나기 시작하는 지점

시트와 쇼잉 시스템이 어긋나는 이유는 필드를 잘못 읽었기 때문인 경우가 드뭅니다. 두 플랫폼이 쇼잉 확인 이메일을 발행하고 수정하는 방식 때문에 어긋나며, 각 구조는 특정한 유형의 오래된 행을 만들어냅니다.

일정 변경이 새 요청으로 도착하므로 기존 행은 절대 바뀌지 않습니다

ShowingTime에서 약속 일정을 변경하면 일정 변경 정보가 담긴 새 약속 요청이 매도인 측 에이전트에게 확인용으로 전송됩니다(ShowingTime 일정 변경). 원래 행은 아무도 수정하지 않습니다. 더 이상 존재하지 않는 시간을 가진 채 시트에 남아 있으며, 완료된 것처럼 보이기 때문에 그대로 남습니다.

오래된 행은 오래되어 보이지 않습니다. 주소와 시간, 에이전트가 있으며, 이는 올바른 행이 가진 것과 정확히 같습니다.

업데이트는 토요일의 다른 모든 일과 경쟁하며, 완료된 것처럼 보이는 행은 자신이 오래되었다고 알려주지 않습니다. 이전 시간이 대체되지 않았다고 알려주는 오류 메시지도 나타나지 않습니다.

공동 담당 에이전트와 쇼잉 안내는 MLS에서 한 번만 가져오고 이후에는 갱신되지 않습니다

ShowingTime은 매물 데이터를 최초 1회만 가져오며, 여기에는 공동 매도 담당 에이전트와 쇼잉 안내가 포함됩니다. 이후 MLS에서 이루어진 변경 사항은 자동으로 반영되지 않습니다(공동 매도 담당 에이전트; 안내). 게시 후 공동 담당 에이전트를 추가한 매물은 공동 담당 에이전트 필드가 비어 있는 상태로 쇼잉 확인 이메일을 계속 발송할 수 있으며, 안내가 변경된 매물은 이전 안내를 계속 보내거나 아예 보내지 않을 수 있습니다.

어떤 추출 설정으로도 이메일에 포함되지 않은 필드를 복구할 수는 없습니다. 시트의 빈 공동 담당 에이전트 필드는 읽기 결과가 아니라 매물 워크시트에 관한 신호입니다. 유용한 대응은 빈 필드를 표시하고 쇼잉 플랫폼에서 수정하는 것이지, 추출을 다시 실행해 다른 결과가 나오기를 기대하는 것이 아닙니다.

출입 코드는 발급된 예약과 함께 만료됩니다

Master Lock의 BrokerBay 잠금 상자 가이드는 쇼잉 확인 이메일의 코드가 확정된 예약에만 유효하다고 명시합니다(Master Lock Vault 가이드, 2022). 이로 인해 중복 행은 실제 현장 실패로 이어집니다. 쇼잉 에이전트가 시트를 열고 이전 행에서 코드를 읽은 뒤 매물 현장으로 이동하지만, 잠금 상자가 열리지 않습니다.

중복 행은 정리에 1분이면 충분합니다. 오래된 코드는 이동, 지연된 쇼잉, 그리고 현관에 서 있는 매수인을 초래합니다. 이것이 바로 시트에 로그뿐 아니라 최신 보기가 필요한 이유입니다.

쇼잉에 관여하는 사람과 각 역할이 소유하는 필드

약속 하나에 여섯 명이 관여할 수 있으며, 각자 기록의 서로 다른 부분을 소유합니다. 한 사람이 모든 것을 관리한다고 가정하고 시트를 작성하면 인계가 누락됩니다.

소유권이 명확해지면 열 구성이 따라옵니다. 매도인 측 코디네이터는 상태와 일정 변경을 소유합니다. 매도인 측 에이전트는 안내와 출입을 소유하므로, 그곳이 비어 있다면 상류에서 해결할 문제입니다. 쇼잉 에이전트는 쇼잉 확인 이메일에 전혀 나타나지 않는 현장 메모를 소유합니다.

ShowingTime, SentriLock, BrokerBay 전반에 통하는 열 세트

열 세트는 이메일이 아니라 예약을 설명해야 합니다. 이 이름들을 한 번 입력해 두면 값이 고정 템플릿의 위치가 아니라 의미로 찾아지므로 동일한 세트로 세 플랫폼을 모두 읽어냅니다.

잠금 상자 코드를 시트에 넣을지 여부는 신중하게 결정해야 합니다. 팀, 가상 비서 또는 CRM 동기화와 공유되는 시트는 쇼잉 확인 이메일보다 훨씬 넓은 범위로 배포됩니다. 팀이 상자가 어디에 있는지와 코드가 확인 이메일에 있다는 사실만 알면 된다면, 출입 메모 열에 "코드 있음(확인 이메일)"이라고 적는 것으로 충분합니다. 코드를 반드시 저장해야 한다면 시트 접근을 제한하고 약속 시간이 지나면 오래된 행을 삭제해야 합니다. 플랫폼이 당일 코드를 발급하는 경우 약속과 함께 만료되므로 이를 계속 보관해도 운영상 가치가 없습니다. 고정 조합 코드는 다른 문제이며, 이를 공유 시트에 저장하는 것은 더 신중하게 검토할 필요가 있습니다.

각 메시지를 전달하지 않고 이메일이 시트에 도달하는 방법

사람들이 ShowingTime to Google Sheets 설정이라고 부르는 것은 실제로 이메일 경로입니다. 플랫폼이 확인 이메일을 보내고, 받은편지함이 이를 읽고, 시트가 행을 받습니다. 세 플랫폼 중 어느 것도 쇼잉을 스프레드시트에 직접 기록하지 않으므로 연결 고리는 받은편지함입니다. 전용 이메일 주소와 하나의 전달 규칙이 수동 전달을 대체하며, 추출은 출입 세부 정보가 이미 들어 있는 메시지 본문을 읽습니다.

ImageToTable.ai의 Email Inbox는 모든 계정에 고유 주소를 제공합니다. 그곳으로 전송된 메일은 누구도 로그인하지 않고 처리 대기열에 들어가며, 여기서 중요한 두 가지 설정은 무엇을 읽는지와 누구의 메일을 허용하는지입니다. 기본값은 실제 첨부 파일을 읽고 본문은 무시하는데, 유용한 첨부 파일이 없는 확인 이메일에는 잘못된 기본값입니다. 이 기본값은 실제 파일이 포함된 메일에 대한 것으로, 첨부 파일 우선 이메일 데이터 추출 워크플로가 구축된 사례에 해당하며, 쇼잉 확인 이메일은 그 반대 사례입니다. 본문만 또는 첨부 파일 및 본문으로 전환하면 메시지 자체가 입력이 됩니다. 본문 전용 추출 워크플로에서 이 모드를 더 자세히 설명합니다.

여기서 Custom Column Extraction이 플랫폼별 템플릿을 제거합니다. Property Address, Showing Date, Start Time, Status, Showing Agent 등 원하는 열 이름을 입력하면 AI가 페이지에서 위치가 아니라 의미를 이해하여 각 값을 찾습니다. 입력한 이름이 출력의 헤더가 됩니다. 동일한 열 집합으로 ShowingTime 확인 이메일, BrokerBay 확인 이메일, SentriLock 약속 알림을 각 형식에 대한 별도 규칙 없이 읽을 수 있습니다.

동일한 파이프라인 구조는 단일 매물이나 여러 매물 배치에도 적용됩니다. 행은 하나의 테이블에 누적되고, 플랫폼 열이 출처를 구분합니다. 공급자가 본문과 첨부파일을 모두 보낼 때의 처리 방법을 포함한 이메일-스프레드시트 전환의 작동 방식은 이메일-시트 파이프라인 분석에서 다룹니다.

일정 변경 후에도 쇼잉당 한 행 유지하기

쇼잉당 한 행을 유지하려면 두 계층이 필요합니다. 추가 전용 로그와 최신 보기입니다. 추출은 읽은 각 메시지마다 행을 추가합니다. 이전 행을 편집하거나 삭제하지 않으므로, 조정 작업은 추출이 아니라 스프레드시트에서 이루어져야 합니다.

첫 번째 계층은 로그입니다. 모든 쇼잉 확인 이메일, 일정 변경, 취소가 각각 한 행이 되며, 어떤 행도 편집되지 않습니다. 이것이 감사 추적입니다. 플랫폼이 무엇을 언제 보냈는지 증명합니다. 추가 전용으로 유지하면 잘못된 수정이 원본을 조용히 덮어쓰는 대신 눈에 띄게 됩니다.

두 번째 계층은 최신 보기입니다. 로그를 읽고, 각 약속의 최신 라이브 행을 유지하며, 대체된 행은 숨깁니다. Google Sheets에서는 로그 사본에 도우미 열을 두면 됩니다. 약속 번호와 상태 날짜로 정렬한 다음, 같은 키를 가진 이전 행의 개수를 셉니다. =COUNTIFS($B$2:$B2,$B2)>1 같은 수식은 첫 번째 이후의 모든 행을 표시하고, 이 표시를 FALSE로 필터링하면 약속당 한 행만 남습니다.

플랫폼이 일정 변경 시 새 확인 번호를 발급하면, 이전 행과 새 행이 같은 키를 공유하지 않습니다. 대신 부동산 주소와 쇼잉 에이전트로 매칭하고, 상태가 더 늦은 행을 유지합니다. 취소가 도착하면 첫 취소가 오기 전에 정책을 정해야 합니다. 최신 보기에서 제외하고 로그에만 남기거나, 취소됨으로 표시하여 매도인 측이 해당 시간이 왜 사라졌는지 볼 수 있게 하는 것입니다.

스프레드시트 작업 15분이면 로그와 최신 보기를 분리할 수 있습니다. 이 단계를 대부분의 팀이 건너뛰기 때문에, 추출이 완벽하게 작동하는 동안에도 시트는 오래된 상태가 됩니다.

이 기능이 하지 않는 일

이 파이프라인은 이메일을 읽을 뿐 쇼잉을 진행하지 않으므로, 이를 기반으로 보고서를 만들기 전에 그 경계를 명확히 해야 합니다.

• 네이티브 플랫폼 연동 없음. ShowingTime, SentriLock, BrokerBay 커넥터가 없고, 쇼잉 플랫폼에서 API로 데이터를 가져오지 않으며, 시트에서 예약을 잡거나 확인, 일정 변경, 취소할 방법도 없습니다.
• 캘린더나 잠금 상자 제어 없음. 이 파이프라인은 Google Calendar나 Outlook에 기록하지 않고, 잠금 상자를 열거나 할당하거나 관리하지도 않습니다. 플랫폼이 보낸 내용을 기록할 뿐입니다.
• 제자리 업데이트 없음. 일정 변경은 새 행을 만듭니다. 쇼잉당 하나의 최신 행을 유지하는 것은 위에서 설명한 2계층 스프레드시트 단계이지, 자동 동작이 아닙니다.
• 플랫폼 보고서가 여전히 매물별 기록입니다. ShowingTime의 Listing Activity Report에는 쇼잉 에이전트 정보, 메모, 피드백이 포함되며, 주택 소유자용 버전은 쇼잉 에이전트 세부 정보를 의도적으로 생략합니다(Listing Activity Report). 시트는 플랫폼 보고서가 제공하지 않는 플랫폼 간, 매물 간, 팀, CRM 관점에 사용하고, 플랫폼 보고서를 대체하는 용도로 쓰지 않습니다.
• 받은편지함은 알림 설정만큼만 완전합니다. SentriKey는 이메일을 선택 해제해도 Message Center로 쇼잉 알림을 보냅니다(SentriKey guide). 매도인 측에서 이메일을 꺼 두었다면 쇼잉 확인 이메일은 존재하지만 파이프라인에 도달하지 않습니다.
• CRM이 아닙니다. 출력은 스프레드시트나 JSON입니다. Follow Up Boss, kvCORE 및 유사 시스템은 CSV를 가져오며, 직접 푸시는 내장 커넥터가 아니라 API로 처리할 작업입니다.

또한 이 로그는 거래 파일이 시작되는 지점에서 끝납니다. 매물이 계약 단계에 들어가면 쇼잉 활동은 종결 문서 패키지의 맥락이 되며, 이는 자체적인 완전성 규칙과 자체적인 보관 위치를 가집니다.

FAQ

하나의 열 세트로 ShowingTime, SentriLock, BrokerBay 이메일을 함께 읽을 수 있습니까?

값이 메시지 본문에 존재하는 한 가능합니다. 세 플랫폼은 서로 다른 표현과 필드 순서를 사용하지만, 맞춤 열 추출은 위치가 아니라 의미로 각 값을 찾으므로 하나의 열 이름 세트로 세 플랫폼 모두를 처리합니다. "로그인하여 예약을 확인하세요"라고만 하고 세부 정보가 없는 알림은 값을 메시지에 포함하지 않으므로 필드를 생성할 수 없습니다.

쇼잉 확인 이메일에 PDF 첨부가 필요한가요?

아닙니다. 쇼잉 확인 이메일은 분리할 PDF가 아니라 메시지 내용으로 전송되므로, 첨부 파일만 읽는 기본 설정은 유용한 결과를 반환하지 않습니다. 받은 편지함을 본문만 또는 첨부 파일과 본문으로 설정하여 메시지 텍스트를 직접 읽도록 하십시오.

쇼잉이 일정 변경되거나 취소되면 행을 업데이트할 수 있습니까?

아닙니다. 각 메시지는 새 행이 됩니다. 최신 보기를 유지하려면 추가 전용 로그를 예약별 최신 유효 행으로 필터링해야 하며, 이것이 위에서 설명한 2계층 접근 방식입니다. 추출은 이전 행을 편집하거나 삭제하지 않습니다.

이메일에 공동 담당 에이전트가 없으면 어떻게 됩니까?

값이 없으므로 파이프라인은 해당 필드를 비워 둡니다. 이는 보통 쇼잉 플랫폼이 공동 담당 에이전트가 추가되기 전에 매물 정보를 가져왔다는 뜻이며, 쇼잉 플랫폼 내에서 공동 담당 에이전트가 추가될 때까지 계속 빈 값으로 전송됩니다. 빈 값을 추출 오류가 아니라 매물 측 할 일로 취급하십시오.

Follow Up Boss나 kvCORE에 직접 쓸 수 있습니까?

기본적으로는 아닙니다. 출력은 스프레드시트 또는 JSON이며, 표준 경로는 CRM으로의 CSV 가져오기입니다. 직접 전송이 필요한 팀은 REST API와 webhook을 자체 브리지로 사용합니다.

공유 시트에 잠금 상자 코드를 보관해도 안전합니까?

대체로 그렇지 않습니다. 공유 시트는 쇼잉 확인 이메일보다 더 널리 퍼집니다. 팀이 시트에 코드가 반드시 필요하지 않다면 키박스 위치와 "코드는 쇼잉 확인 이메일에 있음"이라는 안내만 저장하십시오. 정말로 필요하다면 접근을 제한하고 예약 후 행을 삭제하십시오. 당일 코드는 예약이 지나면 무효가 되기 때문입니다.

쇼잉 시트는 이메일 목록이 아니라 예약 기록입니다. 시트가 예약을 기준으로 키가 설정되면 일정 변경은 예외가 아니라 상태 변경이 됩니다.

이러한 전환이 바로 시트를 주간 매도인 보고서, 팀 대시보드, CRM 가져오기에 사용할 수 있게 만듭니다. 각 플랫폼의 쇼잉 확인 이메일 하나씩으로 테스트하여 어떤 필드가 반환되는지, 어떤 필드가 이메일에 아예 없었는지 확인하십시오. 실제 쇼잉 확인 이메일로 사용해 보기.