Zapier 및 CRM 자동화

MailInApp에는 아직 공식 Zapier 앱이 없지만, 굳이 필요하지도 않습니다. 프로젝트 웹훅은 이미 HTTPS를 통한 평범한 서명된 JSON이며, 이는 Zapier의 범용 Webhooks by Zapier 트리거가 정확히 기대하는 형태입니다. 이를 아무 Zap에나 연결하면 모든 인터랙션 — 투표, 폼 제출, 퀴즈 결과, 상품 구매 — 이 코드 한 줄 없이 CRM, 스프레드시트, Slack, 또는 Zapier가 닿을 수 있는 어디로든 전달됩니다.

동일한 방식이 Make, n8n, Pipedream, 또는 인바운드 웹훅을 받을 수 있는 다른 어떤 자동화 도구에도 적용됩니다 — 이 가이드는 가장 많이 요청받는 도구인 Zapier를 예로 사용합니다.

설정하기

1. Zapier에서 새 Zap을 만들고 트리거 앱으로 Webhooks by Zapier를 선택한 뒤, 이벤트로 Catch Hook을 선택합니다.
2. Zapier가 고유한 Catch Hook URL을 제공합니다 — 이를 복사하세요.
3. MailInApp에서 대시보드 → 해당 이메일 → 응답을 열고, 그 URL을 웹훅 필드에 붙여넣은 다음 활성화를 클릭합니다.
4. MailInApp이 보여주는 서명 시크릿(whsec_…)을 복사하세요 — 딱 한 번만 표시됩니다. 가장 단순한 형태의 Zap이라면 필요하지 않지만, 나중에 서명을 검증할 계획이라면 안전한 곳에 보관해 두세요.
5. 실제 인터랙션을 발생시킵니다 — 투표에 참여하거나, 폼을 제출하거나, 프로젝트의 테스트 발송을 사용하세요 — 그런 다음 Zapier로 돌아가 Test trigger를 클릭합니다. MailInApp이 방금 보낸 페이로드가 event.action, event.value, recipient.row 같은 필드와 함께 표시되어야 합니다.
6. 원하는 액션 단계를 추가합니다 — "Create row in Google Sheets", "Create record in HubSpot/Salesforce/Airtable", "Send Slack message" 등 — 그리고 캡처된 페이로드에서 필요한 필드를 매핑합니다.
7. Zap을 켭니다.

이걸로 끝입니다 — 그 프로젝트에서 이후에 발생하는 모든 인터랙션이 자동으로 흘러 들어옵니다. 매핑에 사용할 수 있는 모든 필드는 웹훅 페이로드 레퍼런스에 문서화되어 있습니다.

중요한 것만 필터링하기

대부분의 CRM 사용 사례는 일부 인터랙션에만 관심이 있습니다 — 예를 들어 모든 열람이 아니라 완료된 폼 제출만요. 트리거 바로 뒤에 Filter by Zapier 단계를 추가하세요.

• event.action이 정확히 submit(또는 vote, rate, purchase 등)과 일치할 때만 계속 진행하도록 하여 특정 액션 하나에만 반응하게 합니다.
• event.blockId가 특정 블록의 id(스튜디오의 블록 인스펙터에서 확인 가능)와 정확히 일치할 때만 계속 진행하도록 하여, 같은 프로젝트의 다른 블록은 무시하고 특정 블록 하나에만 반응하게 합니다.
• lowScore가 true일 때만 계속 진행하도록 하여, 나쁜 CSAT/NPS 응답에 대해 관리자에게 알리는 Zap을 만들 수 있습니다 — 이는 MailInApp 자체의 앱 내 저평점 알림이 사용하는 것과 동일한 신호를, 여러분의 자동화를 통해 라우팅하는 것입니다.

반대 방향으로 연락처 밀어넣기

자동화는 보통 양방향으로 작동합니다: 헬프데스크 티켓이 해결되면, 사람이 직접 CSV를 다시 내보내지 않고도 후속 발송을 위해 그 사람을 MailInApp 연락처 목록에 추가하거나(또는 갱신하고) 싶을 것입니다. "티켓 해결됨", "거래 성사", "다른 곳에서 폼 제출됨"과 같은 어떤 Zap의 마지막 단계로든 Webhooks by Zapier → POST 액션 단계를 사용해, 연락처 목록의 행 업서트 엔드포인트를 가리키게 하면 MailInApp 발송 목록을 자동으로 최신 상태로 유지할 수 있습니다. 해당 엔드포인트는 호출당 최대 500개의 행을 받아들이며, API 키당 분당 30회의 요청으로 속도 제한이 걸려 있습니다. 개별 이벤트마다 실행되는 Zap이라면 이 정도로도 충분히 여유롭지만, 대신 대량의 백필을 한 번에 밀어 넣을 계획이라면 알아 둘 가치가 있습니다.

전달이 실패하는 경우

죽은 Zap URL, 일시 중지된 Zap, 또는 일시적인 Zapier 장애는 모두 MailInApp 쪽에서는 전달 실패로 간주됩니다. 정상 응답 대신 리다이렉트로 응답하는 수신 URL도 마찬가지입니다 — MailInApp은 웹훅 전달에서 리다이렉트를 따라가지 않습니다. 단순히 너무 느린 전달도 실패로 처리됩니다: 응답할 수 있는 시간은 5초이며, 그 안에 응답하지 않으면 MailInApp은 이를 실패로 처리합니다. 전달은 백오프와 함께 자동으로 재시도되며, 여전히 실패 중인 전달은 응답 페이지의 실패한 전달 항목에 수동 재전달 버튼과 함께 표시됩니다 — 전체 재시도 일정은 전달 방식을 참고하세요. 아무것도 조용히 사라지지 않습니다: 웹훅 전달 여부와 무관하게 인터랙션 자체는 항상 먼저 MailInApp에 저장됩니다.