Founders: Your users are telling you when they're ready to upgrade. Here's how to listen
고객이 업그레이드를 고려할 때를 사용량으로 포착하는 방법
n8n과 PostgreSQL, AI를 연결해 요금제 한도에 가까운 고객을 찾고 업그레이드 안내 이메일을 만드는 절차를 설명합니다. 사용량 기준과 마케팅 수신 동의, 발송 간격을 확인하고 테스트용 초안을 검토한 뒤 실제 발송하도록 구성합니다.
- 주제
에디터 노트
80% 사용 기준은 연락 대상을 좁히는 운영 규칙이지 업그레이드 의도를 입증하는 지표는 아닙니다. 원문은 실제 구매 여부를 검증하는 기준이나 대조군을 제시하지 않습니다. Bullpicks가 제안한 홀드아웃 그룹은 이메일 발송과 업그레이드 사이의 인과를 구분하는 데 필요한 보완입니다. 댓글에서 제시한 결제 장벽 이벤트는 사용자가 특정 기능이나 좌석을 원한다는 구체적인 맥락을 보탭니다. 반면 가격 계산을 이메일에 넣자는 BillingHub의 제안은 원문 범위와 다릅니다. 원문은 가격과 할인 언급을 금지하므로 가격 정확성 문제를 직접 다루지 않습니다. 자동화의 실효성은 사용량 기준과 결제 장벽 신호를 어떻게 검증하느냐에 달려 있습니다.
AI 요약
정해진 시점에 모든 고객에게 업그레이드 이메일을 보내기보다 제품 사용량을 살펴 구매 가능성이 높은 고객에게 연락하자는 제안입니다. 예시에서는 Starter 요금제 고객 중 월간 크레딧을 80% 이상 사용했고 최근 30일 동안 10일 이상 활동한 계정을 찾습니다. 이메일 주소가 있고 마케팅 수신에 동의했는지 확인하며, 이전 업그레이드 이메일 발송 후 30일이 지나지 않은 고객은 제외합니다.
n8n 워크플로 구성
매일 실행하는 Schedule Trigger 뒤에 PostgreSQL 노드를 연결하고, 위 조건으로 계정을 조회합니다. 데이터베이스 계정에는 필요한 권한만 부여하고 사용량 데이터가 최신 상태를 유지하도록 애플리케이션에서 갱신해야 합니다. 쿼리는 Starter 고객의 계정 ID, 이메일, 요금제, 사용 크레딧, 한도, 활동 일수를 가져옵니다.
조회한 계정 정보는 AI에 전달합니다. 프롬프트는 실제 사용량만 근거로 업그레이드가 도움이 될지 판단하고, 근거가 부족하거나 정보가 모순되면 추천하지 말라고 지시합니다. 승인된 경우에도 크레딧 한도 외의 기능이나 가격, 할인을 언급하지 않는 90단어 미만 이메일을 작성하게 합니다. 출력은 approved 불리언과 email_body 문자열만 포함하는 JSON Schema로 제한합니다. 승인이 없거나 필드가 유효하지 않으면 이메일 발송 단계로 넘어가지 않도록 합니다.
발송 전 검증과 기록
Gmail 노드는 실제 발송 대신 초안 생성으로 설정하고, 테스트 중에는 수신 주소도 본인이 관리하는 주소로 지정합니다. 이메일 발송이 성공한 뒤 PostgreSQL에서 last_upsell_at을 현재 시각으로 갱신해 같은 고객에게 반복 연락하지 않도록 합니다. 테스트 단계에서는 실제 이메일을 보내지 않았으므로 이 데이터베이스 갱신도 비활성화하라고 안내합니다. 워크플로를 공개하기 전에 테스트 데이터로 직접 실행하고 각 노드 결과를 확인하며, 운영 후에도 매달 성과와 오류를 살펴 규칙을 조정하라고 제안합니다.
Indie Hackers 반응
- @smoke_test_1024 — 사용량 임계값 방식은 괜찮지만, 제 경험상 구매 의도가 가장 강하게 드러나는 신호는 크레딧 80% 도달이 아니라 결제 장벽에 부딪히는 이벤트입니다. 잠긴 Pro 기능을 클릭하거나, 1인 요금제에서 두 번째 좌석을 초대하려 하거나, 내보내기를 눌렀다가 워터마크를 발견하는 사용자는 원하는 순간에 무엇을 위해 돈을 낼지 정확히 알려줍니다. 이런 이벤트를 credits_used와 함께 기록하고 프롬프트에서 더 높은 비중을 주겠습니다. 자동 발송에 관해서는 한 가지 주의가 있습니다. 사용량을 지나치게 정확하게 인용하는 AI 업그레이드 이메일은 감시받는 느낌을 줄 수 있습니다. 데이터를 모델의 맥락으로 제공하되 이메일에서는 사용자가 얻을 결과를 중심으로 표현하고, 초안 검토 기간도 예상보다 길게 두세요.
- @BillingHub — 이메일 단계 전에 한 가지 추가하겠습니다. 이메일에 적힌 가격은 결제 화면에서 청구하는 가격과 같아야 하고, 이메일을 작성하는 모델이 가격을 계산하게 해서는 안 됩니다. 저희 제품도 크레딧을 사용하며 업그레이드 금액은 부족분 기준입니다. 더 큰 요금제의 크레딧 중 이미 보유한 양을 제외한 크레딧에 대해서만 결제합니다. 8월에는 두 코드가 같은 계산을 서로 다르게 처리해 업그레이드 카드와 Stripe 결제 화면의 금액이 달랐습니다. 페이지와 결제 화면이 같은 함수를 호출하도록 고쳤습니다. 이런 워크플로에서는 결제 시스템과 같은 코드에서 계산한 가격을 데이터로 프롬프트에 넘기고 모델에는 그 값을 그대로 옮기라고 하겠습니다. 개인화된 이메일에 잘못된 금액을 쓰면 결제 단계에서 속임수처럼 느껴질 수 있습니다. 또 한도에 가까워진 시기는 이탈을 결정하는 때일 수도 있습니다. 저희는 아직 잔액 부족 이메일을 보내지 않는데, 먼저 업그레이드 권유 없이 남은 양만 알리는 간단한 이메일을 보내고 누가 답하는지 확인하겠습니다.
- @Bullpicks — 좋은 패턴입니다. last_upsell_at 제한은 많은 사람이 놓치는 부분입니다. 이메일을 몇 통 보냈는지가 아니라 이메일 때문에 업그레이드한 사람이 몇 명인지 확인할 수 있도록 대조군도 두겠습니다. 크레딧 사용량만으로 업그레이드 의도를 예측해 봤나요? 지원 티켓이나 로그인 빈도도 영향을 주나요?
- @austinparker — 창업자라면 누구나 건너뛰고 싶어 할 추측 게임이네요.
원문: Indie Hackers / 번역·요약: Trawling