자신의 이메일 주소를 소유하는 영업 아웃리치 에이전트

계정당 하루 200개의 메시지입니다. 이것이 Nylas의 Agent Account 무료 플랜 발송 상한선이며, 이는 아웃리치 에이전트를 설계하는 데 놀라울 정도로 유용한 수치입니다. 이 숫자는 콜드 메일이 스팸이 되는 것을 방지하는 종류의 페이싱을 강제하며, 유료 플랜은 이를 초과할 경우 기본적으로 일일 제한을 낮춥니다.

더 큰 아이디어는 다음과 같습니다: 담당자의 사서함이나 전용 API를 통해 캠페인을 보내는 대신, 에이전트가 자체 주소를 갖게 된다는 것입니다. sales-agent@yourcompany.com은 실제 사서함이며, 메시지를 보내고, 답장을 받고, 캘린더를 소유합니다. Agent Accounts는 베타 버전이지만 모델은 간단합니다: 각 계정은 또 다른 grant일 뿐이므로, 연결된 Gmail 계정에 사용할 Messages, Threads, Events, Webhooks 엔드포인트가 변경 없이 작동합니다.

루프의 모습

제품 문서를 기반으로 한 영업 아웃리치 패턴은 하나의 grant_id로 세 단계에서 실행됩니다:

표준 전송 엔드포인트를 통해 캠페인을 전송합니다.
미팅 예약 — 잠재 고객이 긍정적으로 응답하면, 동일한 grant가 에이전트 자체 캘린더에 이벤트를 생성하고 초대장을 보냅니다.

세 가지 도구 간의 CRM 핸드오프(hand-offs)도 없고, 담당자 사서함에 순차적인 노이즈로 가득 차는 일도 없습니다.

답장은 웹훅으로 도착합니다

수신 메일은 message.created를 발생시키고, 페이로드(payload)는 다른 모든 grant의 경우와 정확히 동일하게 보입니다. 하나의 구독으로 전체 애플리케이션을 커버할 수 있습니다:

curl --request POST \
  --url 'https://api.us.nylas.com/v3/webhooks/' \
  --header 'Content-Type: application/json' \
...

사용자의 엔드포인트는 먼저 challenge 쿼리 매개변수가 포함된 GET 요청을 받게 되며, 이를 200으로 반향(echo)하면 POST 형태로 전달이 흐르기 시작합니다. 페이로드의 data.object에는 발신자, 수신자, 제목, 스니펫과 여기서 가장 중요한 필드인 thread_id가 포함되며, 이 thread_id는 전체 주고받은 내용을 하나의 대화로 묶어 분류기(classifier)와 CRM이 추론할 수 있도록 합니다.

파이프라인 레시피에 있는 두 가지 핸들러 습관은 그대로 복사할 가치가 있습니다. 첫째, 즉시 200으로 응답하고 실제 작업은 나중에 수행하세요. 느린 핸들러는 Nylas 재시도(retries)를 유발하며, 이는 더 많은 중복 데이터를 제거해야 함을 의미합니다. 둘째, 본문의 어떤 내용도 신뢰하기 전에 서명을 확인하세요:

const crypto = require("crypto");

function verifyWebhookSignature(req, webhookSecret) {
...

아웃리치 에이전트는 웹훅(webhooks)이 알려주는 것에 따라 행동합니다. 검증을 건너뛴 위조된 message.created는 당신의 에이전트에게 보내는 위조 지침입니다.

작동 여부를 결정하는 평범한 부분들

세일즈 파이프라인 자동화 레시피는 이러한 시스템이 어디서 실패하는지 명확하게 보여주며, 모든 교훈은 아웃리치 에이전트에게 직접 적용됩니다:

웹훅은 최소 한 번(at-least-once) 전송됩니다. 같은 message.created 알림이라도 핸들러가 느렸을 경우 두 번 도착할 수 있습니다. Redis나 데이터베이스 테이블에 처리된 웹훅 ID를 TTL(Time To Live)과 함께 추적하세요. 인메모리 Set은 재시작 시 유지되지 않습니다. 답장을 이중으로 처리하는 아웃리치 에이전트는 두 번 답장하는 에이전트입니다.

부재 중 자동 응답(Out-of-office replies)도 실제 답장처럼 message.created를 발생시킵니다. 제목 패턴(out of office, automatic reply, auto-reply)으로 이를 감지하고 건너뛰세요.

이것은 send-only 인프라만으로는 재현할 수 없는 부분입니다. 분류기(classifier)가 interested를 반환하고 잠재 고객(prospect)이 시간을 확정하면, 에이전트는 자체 주(primary calendar)에 이벤트를 생성하며 이때 notify_participants=true로 설정합니다. 초대장은 에이전트의 주소에서 일반적인 캘린더 초대장으로 발송되며, 위 구독(subscription)의 event.created 및 event.updated 웹훅은 잠재 고객이 수락했을 때 알려줍니다. 동일한 방식이 여기에도 적용됩니다: 회의는 끊임없이 재조정되므로 이벤트 id에 대한 주요 CRM 기록을 유지해야 하며, 이 경우 모든 변경 사항마다 event.updated가 발생합니다.

딜 사이클(deal cycle)이 길어지면 답장이 마지막 접촉일로부터 며칠 후에 도착할 수 있습니다. 다중 턴 대화 패턴 — 보내기, 받기, 스레드에서 컨텍스트 복원, 응답하기 — 은 바로 그러한 상황을 위해 구축되었으며, 이 스레드 기록은 에이전트가 잠재 고객에게 전달했던 모든 것의 기록 역할을 합니다.

영업 담당자(rep)의 받은 편지함만 사용하면 안 되나요?

OAuth를 통해 영업 담당자의 메일함을 연결하고, 사람 활동을 CRM에 로깅하는 것은 올바른 선택입니다. 파이프라인 레시피는 연결된 모든 권한(connected grants)에 걸쳐 message.created 및 event.created를 사용하여 정확히 이 작업을 수행합니다. 하지만 영업 담당자의 주소에서 발송되는 캠페인 메시지는 영업 담당자의 발신자 평판(sender reputation)이 캠페인의 반송률을 흡수하고, 영업 담당자의 받은 편지함이 답장을 흡수하며, 영업 담당자를 퇴사시키면 통합 자체가 깨집니다. 전용 에이전트 ID는 이 세 가지를 모두 격리합니다. 심지어 고객 도메인별로 하나의 에이전트를 프로비저닝할 수도 있습니다 — sales-agent@customer-a.com, sales-agent@customer-b.com — 각각 고유한 할당량(quota)과 평판을 가지며, 이 모든 것이 단일 애플리케이션 내에서 이루어집니다.

빠른 답변

에이전트마다 웹훅이 필요한가요? 아닙니다. 단일 구독으로 Nylas 애플리케이션의 모든 권한(agent와 연결된 영업 담당자 계정 모두)을 포괄할 수 있습니다. 권한의 제공자(`

연락처 데이터는요? 답장 분류 기능은 의도를 파악하고, 이 파이프라인 레시피는 Contacts API에서 연락처를 가져오는 야간 작업과 연결됩니다 (50개 단위로 페이지네이션되며 next_cursor 사용). 그리고 신선한 전화번호, 직책, 회사 정보를 CRM에 패치합니다. 활동에 대한 실시간 웹훅(webhook)과 서서히 변하는 데이터를 위한 주기적 동기화가 가능합니다.

이 기능을 커밋하지 않고 테스트하고 싶다면, 트라이얼 *.nylas.email 도메인으로 계정을 프로비저닝하고, 웹훅을 터널에 연결한 다음, 자체 테스트 주소들을 대상으로 5명의 잠재 고객 대상 캠페인을 실행해 보세요. 분류 단계에서 흥미로운 조정(tuning)이 이루어집니다—답장 의도를 위해 어떤 레이블 세트를 사용하시겠어요? 댓글에서 어떤 분류 체계(taxonomies)가 사람들에게 효과적인지 정말 듣고 싶습니다.