활용 사례 전체 보기
활용 사례 · 구독·유지보수 사업

해지 위험 고객 미리 알림

고객 활동이 줄어들면, 해지 전에 담당자가 먼저 알림을 받습니다

구독 · 유지보수 계약으로 매출 대부분이 기존 고객에게서 나오는 사업이, 고객별 문의 · 미팅 · 최근 활동 · 담당자 변경 · 갱신일을 매주 같은 기준으로 읽어 이탈 위험을 레코드에 남기고, 위험한 고객에게 먼저 연락하려고 만든 흐름입니다.

문제

  1. 01

    해지 통보로 알게 되는 이탈

    고객이 떠나기로 마음먹은 뒤에야 해지 메일로 상황을 알아, 갱신 전에 손쓸 시간이 남지 않았습니다.

  2. 02

    담당자마다 다른 고객 상태

    같은 고객을 두고도 담당자의 감에 따라 괜찮다 · 위험하다가 갈려, 어느 고객부터 챙길지 정하지 못했습니다.

  3. 03

    인계 때 끊기는 맥락

    담당자가 바뀌면 고객이 무엇에 불만이었는지가 메신저와 머릿속에 남아, 새 담당자가 처음부터 다시 파악했습니다.

트래킷으로 이렇게 해결합니다

  1. 1

    위험을 읽는 기준과 요일을 한 번 정해 둡니다

    CS 팀장이 반복 스케줄 트리거에 매주 월요일 오전 8시를 정하고, 위험도를 가르는 기준(문의가 늘었는지, 미팅이 끊겼는지, 마지막 연락이 언제인지, 갱신일이 얼마나 남았는지)을 에이전트 지침으로 적어 둡니다. 담당자가 바뀔 때마다 바뀐 날과 이전 담당자를 노트로 남기는 작은 워크플로우도 함께 켜 둡니다. 사람이 할 일은 여기까지입니다.

  2. 2

    에이전트가 고객마다 기록을 읽고 위험도와 이유를 정합니다

    데이터 검색 블록이 구독 중인 고객사를 모으면, 커스텀 에이전트가 고객사마다 문의 · 미팅 인터랙션, 노트, 할 일, 갱신일을 읽습니다. 그리고 정해 둔 기준대로 위험도(낮음 · 보통 · 높음)와 이유 한 줄로 답합니다. 에이전트는 기록을 읽기만 하고, 데이터를 직접 바꾸지는 않습니다.

  3. 3

    위험도는 고객 레코드에, 연락할 일은 담당자에게 남습니다

    데이터 수정 블록이 고객사 레코드의 위험도 · 위험 이유 칸을 바꿉니다. 위험도가 높은 고객사만 할 일 등록 블록이 담당자에게 갱신 전 연락 할 일을 맡기고, 담당자에게는 알림이 갑니다. 대시보드는 같은 칸을 읽어 위험도별 고객 수를 보여 주고, 담당자가 바뀌어도 위험도와 이유는 레코드에 그대로 있습니다.

  1. 트리거반복 스케줄매주 월요일 오전 8시에 시작합니다.
  2. 처리데이터 검색구독 중인 고객사를 모두 모읍니다.
  3. AI커스텀 에이전트고객사마다 기록을 읽고 위험도와 이유를 정합니다.
  4. 결과데이터 수정고객사 레코드에 위험도와 이유를 남깁니다.
  5. 결과할 일 등록위험이 높으면 담당자에게 연락 할 일을 맡깁니다.

달라진 점

도입 전해지 통보를 받고 나서야 대응합니다
트래킷 도입 후갱신 전에 위험을 보고 먼저 연락합니다
도입 전고객 상태를 담당자마다 감으로 판단합니다
트래킷 도입 후같은 기준의 위험도와 이유가 레코드에 남습니다
도입 전담당자가 바뀌면 고객 상황이 끊깁니다
트래킷 도입 후담당자가 바뀌어도 고객 상태가 레코드에 그대로 있습니다

다른 활용 사례

지금 시작하세요

고객 데이터 관리부터 자동화까지, 트래킷 하나로 시작하세요.