죄송합니다!양식을 제출하는 중에 문제가 발생했습니다.
Sai는 수신된 이메일을 읽고 발신자 이름, 이메일, 회사, 도메인, 제목, 의도, 그리고 언급된 전화번호나 예산을 추출합니다. 그런 다음 이메일당 한 행씩 추가하고 마지막 열에 JSON 사본을 저장합니다. 기록된 실행 결과, 119개의 메시지를 스캔하여 111개를 분류했고, 그중 조건에 부합하는 23개를 기록했습니다.
The recording is a real session. The sheet on the right is what it produced.
Sai opens each profile, pulls the signal, and writes the row, live, in a real browser.
Eight columns, sorted by score, with a source link behind every claim.
Gmail 액세스 권한과 대상 Google 시트가 필요합니다. Gmail 라벨 또는 일반 언어로 된 카테고리 설명 중 하나를 제공해 주세요.
발신자 이름, 이메일, 회사, 도메인, 제목, 의도, 명시된 전화번호나 예산이 포함된 이메일당 한 행의 데이터와 마지막 열의 일관된 키를 가진 JSON 사본이 생성됩니다. 탭 이름, 행 범위, 이전/이후 로그 개수가 보고되며, 제외된 항목과 그 이유도 함께 안내됩니다.
활성 수신 메일의 경우 매시간 실행하는 것이 좋습니다. 시간 내 응답이 필요하지 않은 경우에는 매일 실행하는 것으로 충분합니다.
이메일 데이터 추출은 수신된 이메일의 내용(발신자, 조직, 요청 사항, 본문에 포함된 수치나 날짜 등)을 다른 시스템이 읽을 수 있는 명명된 필드로 변환하는 과정입니다.
이메일은 헤더 세트와 본문이라는 두 부분으로 구성됩니다. 헤더는 표준화되어 있습니다. RFC 5322는 From 필드를 메시지 작성자로 정의하며, Reply-To 필드는 작성자가 응답을 받기 위해 지정한 주소로 정의합니다. 이 둘은 서로 다를 수 있으며, 다를 경우 운영상 회신 주소가 중요합니다. 헤더에는 메시지 식별자, 날짜, 제목도 포함됩니다.
본문은 표준화되어 있지 않습니다. 서명 블록에 있는 발신자 이름, 소속 회사, 요청 규모, 언급된 마감일 등은 발신자가 선택한 형식의 산문으로 나타납니다. 정의된 위치에서 이를 읽어오는 파서는 없습니다.
이러한 분리 구조가 이메일 추출을 양식 제출 파싱과 다르게 만드는 요소입니다. 정보의 절반은 고정된 스키마에 있고 나머지 절반은 자유 텍스트로 되어 있으며, 보통 다음 단계를 결정짓는 것은 비정형화된 절반의 정보입니다.
연락처 양식은 양식에서 정의한 대로 항상 동일한 필드를 생성합니다. 반면 수신 이메일은 발신자가 작성한 내용 그대로를 생성합니다.
동일한 사안에 대한 두 건의 문의라도 하나는 서명 블록이 포함된 세 줄짜리 메모로, 다른 하나는 문장 중간에 예산이 언급된 여덟 문단짜리 메시지로 도착할 수 있습니다. 두 경우 모두 동일한 운영상의 사실을 담고 있지만, 그 정보가 위치한 곳은 제각각입니다.
기존의 우회 방법들은 저마다 한계가 있습니다. 전달 규칙은 이메일을 이동시키지만 내용을 읽지는 못합니다. 정규 표현식은 전화번호는 확실하게 추출하지만 회사명은 불안정하게 추출합니다. Zapier의 이메일 파서는 샘플 이메일을 기반으로 한 템플릿이 필요한데, 이는 레이아웃이 고정된 기계 생성 메일에는 효과적이지만 사람이 자유롭게 작성한 메일에는 대응하지 못합니다.
결과적으로 인바운드 이메일은 보통 수작업을 통해 CRM이나 스프레드시트에 다시 입력되며, 입력되는 정보도 담당자가 시간적 여유가 있을 때 기입한 항목들로 제한됩니다.
인바운드 문의를 처리하는 영업팀. 누군가 직접 입력하기 전까지 리드는 CRM이 아닌 받은 편지함에 머물게 되며, 회사, 인원수, 명시된 예산, 일정 등 리드를 검증할 수 있는 세부 정보는 이메일 본문에 묻혀 있습니다.
지원 및 운영 부서. 이메일로 접수된 요청은 분류, 요청자, 계정 참조 정보가 있어야만 담당 부서로 전달될 수 있습니다.
직접 지원서를 받는 채용 담당자. 지원자 이름, 관심 직무, 현재 직장 정보가 본문 내용과 첨부 파일 형태로 들어옵니다.
받은 편지함의 내용을 스프레드시트로 관리하는 모든 분. 데이터 전사 작업 자체가 업무의 전부입니다.
수동 재입력 방식은 모든 내용을 정확하게 읽어냅니다. 표에 나열된 방법 중 유일하게 정확성을 보장하기 때문에 가장 먼저 언급했습니다. 이 방식의 제약은 정확도가 아닌 처리량입니다.
Sai는 사용자의 권한으로 Gmail을 열어 지정된 메시지를 읽고, 사용자가 요청한 필드 값을 JSON 형식으로 반환합니다.
필드 목록은 별도의 설정 없이 평문으로 작성하면 됩니다. 발신자 이름, 회사, 이메일 주소, 요청 유형, 명시된 예산 및 마감 기한을 요청하면 해당 6개의 키가 반환됩니다. 특정 필드가 없는 이메일의 경우 해당 키를 생략하는 대신 null 값을 반환하므로, 배치 작업 전체에서 출력 데이터의 구조가 일정하게 유지됩니다.
헤더 필드는 메시지 헤더에서 추출하고, 본문 필드는 텍스트 내용에서 읽어옵니다. 별도의 템플릿을 만들거나 샘플 이메일로 학습시킬 필요가 없습니다.
이메일에서 추출한 JSON은 보통 다른 곳으로 저장되므로 중복 데이터 처리가 중요합니다. Gmail API는 두 가지 식별자를 제공하는데, 이 둘은 서로 대체할 수 없습니다.
id 는 특정 이메일 하나를 가리키는 고유한 메시지 ID로 문서화되어 있습니다. threadId 는 해당 메시지가 속한 스레드, 즉 대화 전체의 ID이며, 그 대화에 포함된 모든 답장에 동일하게 적용됩니다.
스레드를 기준으로 레코드를 생성하면 답장이 올 때마다 기존 행이 업데이트됩니다. 반면 메시지를 기준으로 하면 답장마다 새로운 행이 생성됩니다. 무엇이 올바른지는 작업 단위가 대화인지 개별 메시지인지에 따라 다르지만, 이 차이를 모른 채 선택하면 데이터가 의도치 않게 덮어씌워지거나 리드가 중복되는 문제가 발생합니다.
출력 데이터의 유용성은 필드 목록에 달려 있으며, 흔히 하는 실수는 너무 많은 정보를 요청하는 것입니다.
이메일에 확실히 포함된 필드는 값이 채워지지만, 보통 비어 있는 필드는 대부분의 배치에서 null 값을 반환하여 정보는 없이 키만 늘어나게 됩니다.
보낸 사람, 출처, 요청 내용, 언급된 수치나 날짜 등 핵심적인 짧은 목록만으로도 대부분의 라우팅 및 자격 확인 결정을 내릴 수 있습니다. 첫 번째 배치를 통해 실제 메일 내용을 확인한 후에 필드를 추가해도 충분합니다.
인바운드 처리가 아닌 예약된 아웃바운드 처리의 경우, Gmail 이메일 예약 발송 기능이 발송 측면을 처리합니다.
추출된 레코드가 시트로 전송된 후 추가적인 회사 데이터가 필요한 경우, 리드 리스트 보강 작업이 그 지점부터 이어집니다.
메일의 내용보다 무엇에 응답해야 하는지가 중요한 받은 편지함의 경우, 이메일 관리 기능이 분류를 담당합니다.
