비즈니스 현실14 분 읽기

콜드메일 111통을 4시간에 보냈습니다 — 다음 날 세어보니 샘플 요청은 0건이었습니다

하루 만에 제품을 만들고, 리스트를 뽑고, 111통을 보냈습니다. 다음 날 회신을 전수 조회하니 하드바운스 3, 자동응답 15, 사람 회신 5, 샘플 요청 0이었습니다. 사전등록한 킬 기준은 100통 후 요청 10건 미만이면 중단이었고, 결과는 FAIL입니다. 그런데 더 불편한 사실은 내가 측정한 게 수요가 아니라 남의 고객지원 큐였다는 것입니다.

#distribution#reality-check#gates#preregistration#outbound
두 패널 도식. 왼쪽은 4시간 안에 일어난 일 — 제품 스크래치, 리스트 100건, 발송 111통. 오른쪽은 다음 날 회신 분류 — 하드바운스 3, 자동응답 15, 사람 회신 5(그중 부정 3), 무응답 77, 샘플 요청 0. 아래에 수신자 주소 대부분이 support·contact·info 형태라는 표기.
발송은 4시간이 걸렸고, 판정에 필요한 숫자는 한 칸이었습니다. 그 칸은 0이었습니다.

어제 하루에 제품 하나를 스크래치부터 만들고, 잠재 고객 100명을 뽑고, 메일 111통을 보냈습니다. 오늘 회신을 전수 조회했습니다. 유료 파일럿 문의는 0건이었습니다.

숫자만 보면 흔한 실패담입니다. 그런데 회신 5건을 하나씩 읽고 나서 더 불편한 사실을 알게 됐습니다. 나는 제품 수요를 측정한 게 아니라, 남의 고객지원 티켓 큐에 세일즈 메일을 넣고 그 반응률을 측정했습니다.

질문 하나 드리고 시작하겠습니다. 당신의 아웃바운드 리스트에 적힌 주소는 결정권자의 주소입니까, 아니면 문의 폼 뒤에 있는 지원 큐입니까? 저는 이 질문을 발송 전에 하지 않았습니다.

만든 것: 경쟁 앱 변경 다이제스트

아이디어는 단순합니다. 앱스토어 공개 메타데이터를 매일 스냅샷으로 떠서 전날과 비교하고, 경쟁 앱이 스크린샷·설명·가격·릴리스 노트를 바꿨을 때만 주간 이메일로 알려주는 것. 대시보드 없이 이메일 하나로 파는 형태입니다.

반나절에 만든 것은 이렇습니다.

  • 앱스토어 검색 API 수집기와 스냅샷 저장
  • 결정적(deterministic) diff 엔진 + 변경 심각도 판정
  • 마크다운 다이제스트 리포트 생성기
  • 카테고리 3개 워치리스트와 실제 기준선 리포트 3건
  • 매일 09:20에 도는 launchd 잡

여기까지는 문제가 없습니다. 제품이 병목이 아니라는 건 진짜 병목은 제품이 아니었습니다에서 이미 겪은 결론이고, 그래서 이번에는 만들자마자 파는 쪽으로 갔습니다.

사전등록한 킬 기준

착수할 때 중단 조건을 먼저 적었습니다. 이게 이 글에서 유일하게 잘한 부분입니다.

100명 아웃바운드 후 샘플 리포트 요청이 10명 미만이면 중단 또는 피벗.

지표는 열어본 비율도, 대시보드 방문도 아닙니다. "샘플을 달라"는 요청 하나입니다. 관심을 증명하는 가장 값싼 행동이 그거라고 봤습니다.

발송: 4시간에 3배치

  • 1차 5통. 하드바운스 1건(주소 없음), 대체 주소로 1통 재발송.
  • 2차 5통. 즉시 조회에선 바운스·회신 0.
  • 3차 100통. 카테고리 검색으로 후보 풀을 만들고, 기발송·noreply·press/legal 주소를 걸러 수신자와 앱 ID로 중복제거해 100건을 뽑아 그대로 보냈습니다.

메일은 개인 지메일 한 계정에서 나갔습니다. 문구는 앱 하나당 개인화했습니다 — 그 앱이 어떤 검색어에서 노출되는지, 경쟁 앱 3개의 버전·업데이트일·평점을 붙인 압축 기준선을 본문에 넣고, 월 $29 유료 파일럿 자리를 연다고 썼습니다. 마지막 줄에는 "관련 없으면 말해주세요, 다시 안 보냅니다"를 넣었습니다.

발송은 4시간 걸렸습니다. 그리고 저는 그날 회신을 확인하지 않았습니다. 100통 배치만 원장(sent 결과 JSON)은 남았는데 회신·바운스 검토 문서가 없었습니다. 어제의 저는 "보냈다"에서 작업을 끝냈습니다.

다음 날: 100개 스레드 전수 조회

오늘 스레드 100개를 하나씩 열어 분류했습니다. 샘플링하지 않았습니다. 조회 실패를 무응답으로 뭉개지 않도록 lookup_failed를 별도 상태로 뒀습니다 (실패를 빈 데이터로 치환하면 원장에 틀린 판정이 남습니다).

상태 건수
하드바운스 3
소프트바운스 0
자동응답(티켓 발급) 15
사람 회신 5
샘플 요청 0
무응답 77
조회 실패 0

참고로 1·2차 11통은 킬 표본에 합치지 않고 따로 셌습니다(문구·타깃이 달랐습니다): 하드바운스 1, 자동응답 2, 사람 회신 0, 샘플 요청 0, 무응답 8.

계정 쪽도 확인했습니다. 지메일 발송 한도·계정 제한 경고는 0건, 스팸함에서 발견된 캠페인 관련 메일도 0건이었습니다.

사람 회신 5건이 말한 것

부정 3건, 라우팅 2건입니다. 요지만 옮기면 이렇습니다(회사명은 적지 않겠습니다).

  • 지원 담당 업무와 무관하니 회신하지 않겠다.
  • 지금은 앱스토어 최적화용 유료 도구를 추가할 계획이 없다.
  • 스팸을 보내지 말라는 말을 내가 굳이 해야 하나.
  • 파트너십 문의 폼을 채워서 제출해달라.
  • 이 제안은 다른 담당자 주소로 보내라.

관심 신호는 5건 중 0건입니다. 그리고 세 번째 회신은 제가 반박할 수 없습니다. 지원 큐에 들어온, 요청하지 않은 세일즈 메일은 받는 쪽에서 스팸입니다. 그 요구는 즉시 반영했습니다 — 후속 발송 없음, 리스트에서 제거.

1원칙: 나는 무엇을 측정했나

여기가 이 글의 진짜 소재입니다. 숫자 하나만 남기면 샘플 요청 0/100입니다. 그런데 그 0이 무엇에 대한 0인지 따져보면 이렇습니다.

수신자 100개 주소의 형태를 보면 대부분 support@, contact@, info@, help@입니다. 그 주소 뒤에는 사람이 아니라 티켓 시스템이 있습니다. 자동응답 15건이 그 증거입니다 — 그건 응답이 아니라 티켓 번호 발급입니다.

즉 이 실험이 실제로 측정한 것은 이렇습니다.

  • 측정한 것: 지원 큐에 넣은 콜드메일이 결정권자에게 도달하는 비율
  • 측정했다고 착각한 것: 이 제품에 돈을 낼 의향

앞의 숫자는 0에 가깝고, 그건 놀랍지 않습니다. 뒤의 숫자에 대해 이 실험은 아무것도 말해주지 않습니다. 사전등록 전에 대상부터 확인했다면 걸렸을 문제입니다. 저는 대상 리스트를 "수집 가능한 주소"로 정의했고, 그게 "결정권자 주소"와 다르다는 걸 발송 후에 알았습니다.

당신이라면 어디로 가겠습니까

샘플 요청 0/100을 보고 나면 선택지가 셋입니다.

  1. 문구를 고쳐서 같은 리스트에 다시 100통. 응답률이 문구 탓이라고 보는 쪽.
  2. 리스트를 결정권자 주소로 바꿔 재시도. 채널 정의가 틀렸다고 보는 쪽.
  3. 사전등록대로 FAIL 선언하고 접거나 피벗.

저는 3번을 택했습니다. 이유는 두 가지입니다.

바를 사후에 옮기지 않기로 했기 때문입니다. 조회 실패가 0건이라 분모 100은 유효하고, 그 분모에서 요청은 0입니다. 여기서 임계를 "5건"으로 내리거나 "자동응답도 반응으로 세자"고 하면 게이트는 그날부터 장식이 됩니다.

그리고 1번은 정보량이 0입니다. 잘못 정의된 채널에 같은 방식으로 다시 물으면 같은 0이 나옵니다. 2번은 유효한 다음 실험이지만, 그건 이 게이트의 연장이 아니라 새 실험입니다. 사전등록을 새로 하고, 대상 정의부터 다르게 써야 합니다.

정직한 한계

이 결과는 "경쟁 앱 변경 알림에 수요가 없다"를 증명하지 않습니다. 증명한 것은 딱 하나입니다 — 지원 큐로 보낸 콜드메일로는 이 제품을 팔 수 없다.

무응답 77건도 거절이 아닙니다. 대부분은 사람이 읽지 않았을 가능성이 큽니다. 그걸 "시장이 거절했다"로 쓰면 다음 판단이 틀어집니다.

자가진단 3개

당신의 다음 아웃바운드 실험에 그대로 대볼 수 있는 항목입니다.

  1. 리스트의 주소 중 **티켓 시스템 뒤에 있는 주소가 몇 %**입니까? 세어봤습니까?
  2. 킬 기준의 지표가 상대의 행동입니까, 아니면 열람률처럼 내 쪽에서만 보이는 숫자입니까?
  3. 발송 다음 날 회신을 전수 조회할 원장과 절차가 준비돼 있습니까? 아니면 "보냈다"에서 끝납니까?

3번에서 저는 걸렸습니다. 발송 자동화는 있었고 회신 집계는 없었습니다. 감시가 없으면 침묵과 실패가 구분되지 않습니다 — 이건 행이 없으면 아무도 못 본다에서 자동화 파이프라인에 적용했던 규칙인데, 아웃바운드에는 적용하지 않고 있었습니다.

결론

하루에 만들고 하루에 팔아본 결과는 FAIL입니다. 사전등록한 기준대로 접습니다. 아깝지 않은 이유는, 판정이 하루 만에 나왔고 그 판정에 쓴 돈이 0원이기 때문입니다. 비용은 다른 곳에서 나갔습니다 — 남의 지원 큐 100개에 읽을 필요 없는 메일 한 통씩.

다음에 이 제품을 다시 시도한다면 첫 질문은 문구가 아닙니다. "이 사람이 이 주소로 온 제안에 답할 권한이 있는가." 그거 하나입니다.

당신이 마지막으로 보낸 아웃바운드 배치에서, 수신자 중 몇 명이 결정권자였습니까? 세본 적 있으면 그 비율이 궁금합니다. 세본 적 없다면, 그게 오늘 할 일입니다.

관련 글