구독 서비스 CRM 온보딩 사례 | AI SaaS의 결제 연동·결제 실패 리마인더·CS 티켓 자동화

구독 서비스 CRM은 신규 고객 유치보다,
결제 실패와 문의 응대를 자동으로 연결하는 게 더 효과적입니다.

이번 주, 결제 실패한 고객에게 누가, 언제, 어떤 메일을 보냈나요?
구독 서비스 CRM을 검토하는 팀에 이 질문을 드리면 바로 답하는 곳이 많지 않습니다.
결제 기록은 결제 도구에, 문의는 메일함에, 발송 기록은 담당자의 파일에 나뉘어 있기 때문이죠.

이 글은 AI 서비스를 구독형으로 판매하는
한 SaaS 기업의 허브스팟 온보딩 기록을 바탕으로 재구성했습니다.

도입 전 해당 기업은 결제 실패 명단을 파일로 내려받아 CRM에 올린 뒤 메일을 보냈습니다.
문의는 메일·메신저·문서 도구로 들어왔고 담당자 배정과 유형 집계는 수동으로 했죠.

그래서 이 온보딩의 과제는 두 가지였습니다.
결제 실패 대응을 규칙으로 돌리는 것, 그리고 흩어진 문의를 티켓 하나의 형식으로 모으는 것입니다.

본문은 ‘새벽별랩스’라는 가상의 회사 CRM 세팅을 통해 따라가보며 진행해보겠습니다.
화면에 적힌 회사 명이나 데이터는 모두 가상으로 만들었으며,
결제 상태 역시 고객사의 세팅과 동일하지 않게 가상의 속성으로, 구조만 비슷하게 재현했습니다.

 

구독 서비스에서 CRM으로 챙겨야 할 부분

구독형 서비스의 매출은 첫 결제에서 끝이 아니라,
매달, 매년 결제가 다시 일어나야 매출이 유지됩니다.

그래서 구독 서비스 CRM이 먼저 챙길 곳은 신규 가입보다,
결제가 끊기는 순간과 고객이 막혀서 문의하는 순간입니다.

• • 결제 실패 : 결제 수단 문제로 결제가 실패한 고객은 해지할 생각이 없어도 그대로 이탈합니다. 제때 안내하면 되돌릴 수 있는 매출입니다.
  • 문의 응대 : 문의가 여러 창구로 흩어지면 같은 고객이 두 번 묻고 누가 답했는지 확인하는 데 시간이 듭니다.
  • 발송 대상 관리 : 구독자가 늘수록 마케팅 메일을 받는 사람도 늘어납니다. 허브스팟에서는 이 인원이 곧 비용의 기준이 됩니다.

세 가지 모두 사람이 매번 판단하려고 하면 놓치는 게 생길 수 있습니다.
하지만, 이를 규칙으로 정해 두면 시스템이 챙기게 됩니다.

도입 전 현황 파악하기

구독 서비스 CRM 온보딩의 첫 시간에는 기능을 바로 소개하기보다,
지금의 운영 방식을 영역별로 적어 봤습니다.

표로 옮기고 나니 문제가 분명해졌습니다.
수작업이 많다는 것보다, 작업 기록이 남지 않는다는 점이 더 컸습니다.

기록이 없으니 다음 달에도 같은 판단을 처음부터 다시 해야 했죠.

 

설계 ① 개인 고객과 기업 고객을 나눈 기준

고객사의 고객은 두 부류였습니다.
개인 고객과 기업 고객입니다. 

• • 개인 고객은 요금제를 골라 스스로 결제하고 (셀프 결제)
  • 기업 고객은 견적을 요청합니다. (견적 문의)

따라서 제품과 요금제는 같아도 문의와 결제가 들어오는 경로가 달랐습니다.

처음에는 개인용과 기업용 계정을 따로 쓰는 안도 나왔습니다.
하지만, 계정을 나눴다가 나중에 합치면 그동안 쌓인 활동 이력이 함께 넘어오지 않습니다.

그래서 계정은 하나로 두고 진입 경로로 트랙을 나눴습니다.
한 고객의 결제·문의·메일 이력이 한 화면에 모여야 구독 서비스 CRM이 제 역할을 하기 때문입니다.

기업 문의도 티켓으로 받았습니다.
문의는 모두 한 형식으로 쌓고, 견적이 오가는 건은 티켓 단계로 구분해
주간 단위 전환율을 확인했습니다.

[화면 1] 연락처 속성 › 결제 정보 그룹 : ‘결제 상태(정상·실패·해지)’, ‘결제 통화’, ‘최근 결제일’, ‘문의 횟수’를 한 그룹으로 묶었다. 샌드박스에서는 결제 연동 대신 가상 속성으로 결제 데이터를 대신했고, 실제 운영에서는 결제 도구의 연동 앱이 이 값을 채운다.

[화면 2] 티켓 목록 › 뷰 탭 : 결제 실패 규칙이 만든 자동 티켓과 기업 견적 문의, CS 문의가 한 파이프라인에 쌓이고 ‘CS 문의’, ‘자동 티켓(결제 실패)’, ‘기업 견적 문의’, ‘전체 문의’ 뷰 탭으로 나눠 본다. 샌드박스 가상 데이터.

설계 ② 결제 실패 리마인더를 두 개의 규칙으로 나눈 이유

이 설계가 이 사례의 핵심입니다.
결제 실패 리마인더는 한 번 보내는 것보다,
같은 사람에게 두 번 보내지 않는 것이 더 어려웠기 때문입니다.

판정은 활성 세그먼트, 중복 방지는 정적 세그먼트로

그래서 판정과 중복 방지의 세그먼트를 나눠 설계했습니다.
두 세그먼트를 이렇게 나눈 이유는 세그먼트의 종류와도 연관되어 있습니다.

허브스팟의 세그먼트(구 리스트)에는 두 종류가 있습니다.

• • 활성 세그먼트(Active Segment) : 조건에 맞는 사람이 실시간으로 명단에 들어오고 나갑니다.
  • 정적 세그먼트(Static Segment) : 조건과 상관없이 워크플로우가 직접 명단에 넣고 뺍니다. 워크플로우가 세그먼트를 조작하려면 정적 세그먼트여야 합니다.

이 중, 결제 실패 판정은 활성 세그먼트가 맡았습니다.
그러면 결제 도구에서 넘어온 기록 중 결제 실패 상태인 고객이 자동으로 담깁니다.

그런데 활성 세그먼트만으로는 중복 발송을 막지 못합니다.
결제 실패 상태가 며칠 이어지면, 계속 조건이 맞는 상태로 판정되기 때문입니다.

그래서 ‘안내 진행 중’이라는 정적 세그먼트를 하나 더 뒀습니다.
그러면 고객이 결제 실패 세그먼트에는 있고,
안내 진행 중 세그먼트에는 없을 때만 안내가 시작됩니다.

1. 1. 규칙 1 (안내 시작) : 결제 실패 세그먼트에 들어온 고객을 안내 진행 중 세그먼트에 넣고, 결제 실패 티켓을 만든 뒤 1차 안내 메일을 보냅니다. 2~3일 뒤에도 결제가 되지 않았으면 2차 메일을 보냅니다.
   2. 규칙 2 (재진입 준비) : 안내 진행 중 세그먼트에 들어온 지 8일이 지나면 세그먼트에서 뺍니다. 다음 결제에서 또 실패하면 규칙 1이 처음부터 다시 돌아갑니다. 
      
      

여기서 규칙 1에는 재등록을 켜 뒀습니다.
기본값대로 두면, 한 번 워크플로우에 등록된 고객은 결제에 다시 실패해도
워크플로우에 다시 들어오지 않기 때문입니다.

또, 중간에 결제가 완료되면 2차 메일은 나가지 않습니다.
그런데 결제 건 단위로는 워크플로우 조건을 걸 수 없어서
결제 상태를 고객(연락처) 속성에 표시해 두고 그 값으로 판단하도록 우회했습니다.

[화면 3] 활성 세그먼트 › 결제 실패 : ‘결제 상태 = 실패’이고 ‘최근 결제일 = 어제’인 연락처가 자동으로 담긴다. 샌드박스 가상 데이터 5명.

[화면 4] 정적 세그먼트 › 안내 진행 중 : 필터 없이 워크플로우가 직접 넣고 뺀다. 오른쪽 ‘사용처’에서 이 세그먼트를 쓰는 워크플로우 두 개(안내 시작·재진입 준비)를 확인할 수 있다.

[화면 5] 결제 실패 안내 워크플로우 › 등록 조건 : ‘결제 실패 세그먼트의 구성원’이면서 ‘안내 진행 중 세그먼트의 구성원이 아님’. 왼쪽 설정 탭에서 재등록을 켰다.

[화면 6] 결제 실패 안내 워크플로우 › 앞부분 : 안내 진행 중 세그먼트에 추가 → 결제 실패 티켓 생성 → 결제 통화 분기(원화 → 한국어, 달러 → 영어) 순서로 이어진다.

[화면 7] 결제 실패 안내 워크플로우 › 1차 메일 : 통화별로 한국어·영어 1차 안내 메일을 보낸 뒤 지연을 두고 결제 상태를 다시 확인한다. 샌드박스에서는 지연을 3일로 설정했다.

[화면 8] 결제 실패 안내 워크플로우 › 2차 메일 : 결제 상태가 아직 실패면 2차 메일을 보내고, 결제가 완료됐으면 메일 없이 종료한다.

[화면 9] 재진입 준비 워크플로우 : ‘안내 진행 중’ 등록 → 8일 지연 → 정적 세그먼트에서 제거. 이 규칙이 있어야 다음 결제 실패 때 안내가 다시 나간다.

이렇게 트리거·지연·분기를 조합하는 워크플로우 설정 자체는 어렵지 않습니다.
어려운 건 중복을 막는 구조를 먼저 세팅하는 것입니다.

오늘이 아니라 ‘어제 데이터’를 기준으로 잡기

테스트 중, 오늘 결제에 실패한 고객이 세그먼트에 바로 들어오지 않는 일이 생겼습니다.
원인은 두 가지였습니다.

• • 반영 시차 : 결제 도구의 기록이 허브스팟으로 넘어오기까지 시간이 걸려, 당일 실패 건 일부는 그날 판정 시점에 아직 들어와 있지 않았습니다.
  • 시간대 차이 : 결제 도구와 허브스팟이 쓰는 시간대가 달라, 자정 무렵 결제 건은 두 곳에서 날짜가 하루씩 다르게 찍혔습니다.

‘오늘’을 기준으로 삼으면 아직 넘어오지 않은 건과 날짜가 밀린 건이 빠집니다.
반면 하루가 지난 뒤에는 기록이 모두 들어와 있고 날짜도 확정됩니다.

그래서 판정 기준을 ‘어제 생성된 결제 기록’으로 바꿨습니다.
안내가 하루 늦어지더라도 빠지는 고객이 없는 쪽을 택한 것입니다.

국가 대신 결제 통화로 언어를 나눈 이유

안내 메일은 한국어와 영어 두 가지 종류가 있었습니다.
따라서 처음에는 국가 값을 기준으로 올바른 언어의 메일이 나가도록 자동화하려 했지만,
결제 데이터에 국가 값이 비어 있는 고객이 많았습니다.

대신 결제 통화는 빠짐없이 채워져 있었습니다.
따라서 원화 결제 고객은 한국어, 달러 결제 고객은 영어로 분기했습니다.

정확해 보이는 값이라도 비어 있으면 분기 기준으로 쓸 수 없습니다.
분기 기준은 ‘항상 채워지는 값’으로 잡아야 합니다.

설계 ③ 문의는 티켓으로, 파이프라인은 하나로

CS 문의는 제품도 두 가지인 데다 접수 경로도 여러 가지였습니다.
그래서 처음에는 제품·팀별로 티켓 파이프라인을 나누자는 이야기가 나왔습니다.

하지만, 파이프라인을 쪼개면 리포트도 같이 쪼개집니다.
전체 문의 건수를 보려면 매번 여러 리포트를 합쳐야 하죠.

그래서 CS 파이프라인은 하나로 두고 구분이 필요한 값은 티켓 속성으로 만들었습니다. 

• • 문의 경로 : 챗봇·폼·이메일 중 처음 접수된 경로입니다.
  • 제품 : 어떤 제품에 대한 문의인지 고릅니다.
  • 문의 유형 : 미리 정해 둔 세부 유형 목록에서 고릅니다. 유형이 너무 잘게 나뉘면 통폐합부터 했습니다.

팀별로 확인하고 싶은 내용을 볼 때는 이 세 값으로 필터를 건 뷰 하나면 충분했습니다.
대시보드도 같은 값으로 나눠 집계합니다.

여기서 티켓을 만들 때는 문의 유형을 필수로 받았습니다.
이 값이 비어 있으면 집계에서 빠지기 때문입니다.
대신, 고객이 잘못 고른 유형은 CS 담당자가 고칠 수 있게 열어 뒀습니다.

결제 실패 규칙이 자동으로 만든 티켓은 응대가 필요 없으면 기록으로만 두고,
담당자가 처리할 목록에서는 뺐습니다.
또한 같은 고객이 같은 내용으로 두 번 남긴 문의는 티켓 병합으로 하나로 합쳤습니다.

연락처에는 문의 횟수 속성을 만들어 연결된 티켓 수가 자동으로 쌓이게 했습니다.
그러면 같은 문제로 여러 번 문의하는 고객을 따로 골라 볼 수 있습니다.

[화면 10] 티켓 속성 › 문의 분류 그룹 : ‘문의 경로’, ‘문의 유형’, ‘제품’을 드롭다운 속성으로 만들어 한 그룹에 모았다.

[화면 11] 문의 유형 › 드롭다운 옵션 : ‘결제 실패(자동)’, ‘결제·환불’, ‘계정·로그인’, ‘기능 사용’, ‘요금제 변경’, ‘기업 견적’ 여섯 가지로 미리 정했다. 자유 입력이 아니라서 리포트로 바로 집계된다.

[화면 12] 티켓 만들기 양식 편집 : 문의 분류 속성 세 개를 양식에 넣고 문의 유형을 필수(*)로 지정했다. 값을 고르지 않으면 티켓이 저장되지 않는다.

[화면 13] 연락처 레코드 › 결제 정보 : 결제 상태·결제 통화·최근 결제일과 함께 ‘문의 횟수’가 쌓인다. 이 고객은 연결된 티켓이 3건이라 문의 횟수가 3이다. 샌드박스 가상 데이터.

[화면 14] 문의 횟수 워크플로우 : CS 파이프라인에 티켓이 생기면 연결된 연락처의 ‘문의 횟수’를 1씩 올린다. 티켓 기준 워크플로우라 다른 티켓 값은 건드리지 않는다.

문의 창구를 티켓으로 모으는 서비스 허브의 헬프데스크 구성도 같은 방식으로 구성합니다.
티켓 기반 설계에는 무엇보다 유형 목록을 먼저 정하는 게 중요합니다.

담당자 자동 배정이 안 되던 문제는 1분 지연으로

기업 문의 폼이 들어오면 티켓이 만들어지고 담당자가 배정되도록 규칙을 걸었습니다.
그런데 일부 티켓은 담당자 칸이 비어 있었습니다.

원인은 실행 순서였습니다.
티켓이 만들어진 직후, 연결 정보와 속성값이 다 채워지기 전에
배정 워크플로우가 먼저 실행돼 배정에 필요한 값을 읽지 못한 것입니다.

해결은 간단했습니다.
배정 워크플로우 맨 앞에 1분 지연을 넣어, 티켓 정보가 모두 채워진 뒤 배정되게 했습니다.

비슷한 문제가 하나 더 있었습니다.
연락처 기준 워크플로우에서 티켓 값을 바꾸면 그 연락처에 연결된 모든 티켓이 함께 바뀝니다.

그러면 새 문의가 들어올 때마다 지난 티켓의 상태까지 바뀌는 일이 생겨,
티켓 값은 티켓 기준 워크플로우에서만 바꾸도록 나눴습니다.

[화면 15] 기업 문의 워크플로우 : ‘[기업] 새벽별랩스 도입 문의 폼’을 제출하면 ‘[폼] 기업 견적 – 회사 이름’ 티켓을 만든다. 담당자는 이 단계에서 정하지 않는다.

[화면 16] 티켓 배정 워크플로우 : 기업 견적 티켓이 생기면 1분 지연 → 담당자 2명에게 순환 배정 → 내부 알림 메일 순서로 진행한다.

이번 예시처럼, 자동화가 잘 안 될 때는
설정이 틀렸다기보다 작동 순서가 어긋난 경우가 많습니다.

설계 ④ 마케팅 발송 대상을 규칙으로 관리하기

허브스팟의 마케팅 이메일은 마케팅 연락처(마케팅 컨택)로 지정된 사람에게만 나갑니다.
이 인원이 요금 기준이 되고,
결제 실패 안내처럼 워크플로우로 보내는 메일도 예외가 아닙니다.

문제는 마케팅 연락처가 바로 해제되지 않는다는 점입니다.
마케팅 연락처에서 해제해도 다음 업데이트 날짜(이 계정에서는 매월 1일)가 돼야 반영됩니다.

결국, 그때그때 마케팅 연락처를 바꾸는 방식은 통하지 않으니,
처음부터 규칙으로 걸러 두는 편이 낫겠다고 판단했습니다.

1. 1. 폼의 자동 지정 끄기 : 폼을 제출한 사람이 모두 마케팅 연락처가 되지 않도록 폼 옵션을 껐습니다. 마케팅 연락처 지정은 워크플로우가 맡습니다.
   2. 반응 없는 주소 해제 : 마케팅 메일을 10회 이상 받고 한 번도 열지 않은 사람을 해제 대상으로 잡았습니다.
   3. 반송 주소 해제 : 메일이 반송된 주소도 해제 기준에 넣었습니다.
   4. 결제 상태와 연결 : 구독이 끝난 고객은 해제하고, 결제가 실패한 고객은 안내를 받을 수 있게 다시 마케팅 연락처로 등록합니다.

여기서 반송은 두 가지로 나눠 봐야 합니다.

• • 소프트 바운스는 받은편지함이 가득 찬 경우처럼 일시적인 문제이고
  • 하드 바운스는 존재하지 않는 주소처럼 영구적인 문제입니다.

하드 바운스는 다시 보내도 닿지 않으니, 마케팅 연락처 해제 기준에 바로 넣습니다.
소프트 바운스는 다음 발송에서 문제가 해소될 수 있으니,
한 번 바운스가 발생했다고 바로 해제하지는 않는 것이 좋습니다.

[화면 17] 마케팅 연락처 해제 워크플로우 › 등록 조건 : ‘마케팅 이메일 10회 이상 수신이면서 오픈 0회’ 또는 ‘반송 이유가 파악됨(하드 바운스)’ 또는 구독 해지. 해제 액션은 마케팅 연락처 기능이 켜진 계정에서 ‘마케팅 연락처 상태 설정’으로 추가한다.

발송 대상이 정리돼야 오픈율·클릭률 같은 이메일 마케팅 성과도
제대로 확인할 수 있게 됩니다.

 

설계 ⑤ 자동화가 늘어난 뒤에 필요해진 이름 규칙

워크플로우, 이메일, 세그먼트가 열 개를 넘으면 목록만 보고는 무엇이 무엇인지 모르게 됩니다.
그래서 첫 회차에 이름 규칙부터 정했습니다.

• • 시스템이 자동으로 보내는 것에는 [시스템] 접두어를 붙입니다.
  • 이름은 ‘원인 > 결과’ 형태로, 완료 시제로 짓습니다.
  • 목록 칼럼에서 이미 보이는 정보(작성자, 수정일 등)는 이름에 넣지 않습니다.

예를 들면 이렇습니다.

• • [시스템] 결제 실패 안내 > 한국어 (1차)
  • [시스템] 티켓 생성 > 담당자에게 내부 알림
  • [안내 진행 중] 결제 실패 안내 발송 대상
    
    

[화면 18] 워크플로우 목록 : [시스템] 접두어와 ‘원인 > 결과’ 규칙으로 이름을 붙였다. 목록만 봐도 무엇이 무엇을 일으키는지 읽힌다.

 

팀별 트랙으로 나눠 진행한 온보딩

SaaS 고객사는 CS, 마케팅, 그로스 등 여러 팀이 한 계정을 함께 썼습니다.
팀마다 주로 쓰는 객체가 달라서, 공통 교육만으로는 실습이 어려울 수밖에 없었습니다.

그래서 사전 인터뷰로 팀별 요구를 먼저 모으고,
공통 구간과 팀별 트랙을 중심으로 온보딩을 진행했습니다.

1. 1. 공통 구간 : 초반 두 회차는 전 팀이 함께 들었습니다. 여기서는 CRM 기본 구조, 이름 규칙, 필수 데이터 범위, 워크플로우와 리포트의 개념을 맞췄습니다.
   2. 고객 여정 정리 : 팀별 실습에 앞서 고객이 어디로 들어와 어디서 결제하고 어디서 문의하는지를 고객사가 먼저 정리했습니다. 이 결과가 이후 회차의 설계 기준이 됐습니다.
   3. 팀별 트랙 : 이후에는 CS(티켓·챗봇), 그로스(결제 연동·결제 실패 자동화), 마케팅(발송 대상·캠페인 리포트) 트랙으로 나눠 각자의 화면을 직접 만들었습니다.
   4. 점검 회차 : 마지막에는 팀별로 만든 워크플로우를 함께 점검하고 실행 순서 문제처럼 운영 중 드러난 오류를 고쳤습니다. 
      
      

경성솔루션의 허브스팟 온보딩은
요구사항 정의 → 프로세스 구체화 → 기능 가이드 → 설계·구축 → 사용자 교육 → 리포트·안착의 6단계로 진행됩니다.
비용은 1 Set(4회차·8시간) 단위로 산정하고 팀 구성과 범위에 따라 회차를 조정합니다.

도입 후 달라진 것

구독 서비스 CRM을 세운 뒤 가장 먼저 달라진 건
결제 실패 대응을 사람이 챙기지 않아도 된다는 점입니다.

명단을 내려받아 올리던 일이 규칙을 통해 자동화되었고,
담당자는 자동으로 만들어진 티켓만 확인합니다.

• • 안내 성과 확인 : 1차·2차 안내 메일을 캠페인으로 묶고 메일을 받은 뒤 결제 완료로 바뀐 고객 수를 월별로 보는 리포트를 구성했습니다.
  • 문의 유형별 집계 : 유형별 건수가 쌓이면서 어떤 안내 콘텐츠나 챗봇 답변을 먼저 만들지 판단할 근거가 생겼습니다.
  • 반복 문의 고객 파악 : 문의 횟수 속성으로 같은 문제를 여러 번 겪는 고객을 따로 볼 수 있게 됐습니다.

그렇게 되자, CS팀이 잡은 목표도 분명해졌습니다.
문의 건수를 기간별로 보고 상담원 연결 없이 해결되는 문의 비율을 높이는 것입니다.

[화면 19] 대시보드 › 결제·문의 현황 : 결제 상태별 고객 수, 문의 유형별 티켓 수, 문의 경로별 티켓 비율을 한 화면에 모았다. 샌드박스 가상 데이터.

이처럼, 리포트와 대시보드를 구성하는 방법은
허브스팟 리포팅·대시보드 활용법에서 실제 허브스팟 화면과 함께 다룹니다.

구독 서비스에 CRM을 도입할 때의 체크포인트

구독 서비스에 CRM을 도입할 때 미리 정리해 두면 좋은 것들입니다.

1. 1. 결제 데이터 확인 : 결제 도구의 어떤 값이 CRM으로 넘어오는지 먼저 봅니다. 이 사례처럼 국가 값이 비어 있을 수 있습니다.
   2. 중복 발송 방지 : 판정용 세그먼트와 진행 표시용 세그먼트를 규칙 설계 단계에서 함께 만듭니다.
   3. 문의 유형 목록 : 티켓을 받기 전에 유형 목록을 확정합니다. 이를 나중에 바꾸면 과거 데이터와 집계 기준이 어긋나게 됩니다.
   4. 발송 대상 규칙 : 마케팅 연락처(마케팅 컨택) 지정·해제 규칙은 도입 초기에 만듭니다. 해제가 월 단위로 반영되기 때문입니다.
   5. 이름 규칙 : 자동화 이름 규칙은 첫날 정합니다. 자동화 개수가 늘어난 뒤 바꾸면, 전부 다시 고쳐야 합니다.
      
      

 

자주 묻는 질문(FAQ)

Q1. 결제 도구와 연동하면 실시간으로 반영되나요?

연동 방식에 따라 다릅니다.
이 사례에서는 결제 기록이 허브스팟에 넘어오기까지 시차가 있었고, 시간대 차이로 날짜가 어긋나는 건도 있었습니다.
누락을 막으려면 전날 기준으로 규칙을 돌리는 편이 안정적입니다.

Q2. 같은 고객이 여러 번 실패하면 메일이 계속 가나요?

정적 세그먼트로 ‘안내 진행 중’을 표시해 두면 한 번의 실패에 안내가 한 번만 나갑니다.
일정 기간 뒤 세그먼트에서 빠지고 다음 결제에서 또 실패하면 그때 다시 안내가 나가게 됩니다.

Q3. 문의 관리 도구를 따로 쓰는데 티켓이 또 필요한가요?

결제 이력과 문의 이력을 한 고객 화면에서 보려면 필요합니다.
구독 서비스 CRM에서 티켓은 응대 기록이자 이탈 신호를 읽는 데이터입니다.
CS 담당자가 결제 상태를 확인하고 답하면 훨씬 구체적으로 안내할 수 있습니다.

Q4. 구독 갱신 안내도 같은 방식으로 되나요?

네, 구조는 같습니다.
연간 결제 고객의 갱신 시점을 날짜 속성으로 두고 그 날짜를 기준으로 안내 규칙을 걸면 됩니다.

Q5. 어떤 허브가 필요한가요?

폼과 이메일은 마케팅 허브, 티켓은 서비스 허브를 활용합니다.
워크플로우는 Professional 이상에서 쓸 수 있고, 허브스팟 자체의 결제·구독 기능은
레베뉴 허브 영역이라 국내 지원 범위는 도입 시점에 공식 문서로 확인하시는 게 좋습니다.
무료 체험판으로 구조를 먼저 만들어 본 뒤 정식 버전으로 넘어가셔도 됩니다.

구독 서비스 CRM은 결제 실패 규칙 하나와
문의 유형 정리만으로도 일이 많이 줄어듭니다.

우리 서비스의 결제·문의 흐름을 허브스팟에 어떻게 옮길지 궁금하시거나,
허브스팟 온보딩을 고민하고 계시다면 편하게 문의해 주세요.

30분 ~ 1시간 무료 미팅을 통해 무엇이 가능하고 어려운지 분명히 나눠 말씀드리겠습니다.

경성솔루션은 무조건 다 된다는 무모한 약속은 하지 않습니다.
정확한 진단을 바탕으로 ‘솔직한 제안’을, 남들에게도 똑같이 제공하는 일괄적인 설명이 아니라 우리 조직만의 정답을 찾아드립니다.

[ 1시간 무료 진단 신청하기 ]

[ 허브스팟 온보딩 알아보기 ]

함께 읽으면 좋은 글

---

► 허브스팟 마케팅 자동화 – 워크플로우 설정부터 리드 너처링까지 실전 가이드
► 허브스팟 온보딩 완벽 가이드 : 도입 첫 30일 로드맵과 체크리스트
► 허브스팟 서비스 관리 솔루션
► 허브스팟 도입 문의