일 잘하는 후임을 제 손으로 만들었습니다
[8월 회고] 단순 반복은 시스템에 넘기고,고객을 이해하는 데 집중해보자!
2026.09.28
7월에 “이제 서비스 좀 안다”고 말하며 남겨둔 숙제가 있었죠.
"그래서 고객은 어쩌다가 우리 서비스에 찾아오는 걸까?"
그래서 8월의 미션은 바로 이 질문에 답을 찾는 것, 즉 ‘고객과 시장 이해’였어요.
그런데 막상 CRM 담당자로 CS 업무를 처리하다 보니까, 고객을 이해하려면 일단 제게 시간이 필요했습니다.
밀려있는 문의들, 끝난 건지 아닌지 헷갈리는 문의들, 매번 똑같이 새로 쓰고 있는 답변들까지.
고객의 진짜 니즈를 파악하기 위해서는 이런 자잘한 업무들을 빠르게 해결하고, 덜어낼 여유가 필요했어요.
그래서 8월의 저는 자동화를 꺼내 들었습니다.
단순 반복은 시스템에 넘기고, 저는 고객을 이해하는 데 집중하기 위해서요.
반복을 걷어내는 과정: 자동화로 효율 끌어올리기⚙️
‘고객과 시장 이해’라는 목표 아래, 저는 CS 응대 속도를 높이고 반복 업무를 줄이는 데 집중했습니다.
1. CS 운영 체계 구축: 담당자의 머릿속 지식을 문서로 남기기
가장 먼저 [태니지먼트 CS 운영 가이드북]을 만들었어요.
회원가입부터 결제, 포인트, 워크스페이스, 팀 다이어그램, 리포트, 재검사, 전문가 할인까지!
모든 정책과 기능 매뉴얼, 상황별 답변 사례를 한 페이지에 모았죠.
이 작업을 가장 먼저 해야만 했던 이유는 제가 답변을 직접 쓰는 시간보다
‘이거 어떻게 안내해야 하지?’하고 정보를 찾고, 기존 담당자분께 묻고, 대답을 기다리는 시간이 훨씬 길었거든요.
신규 담당자인 제가 기존 담당자님의 머릿속 지식에만 의존해 전달하는 구조이기도 했고요.
특히 예외가 많은 정책은 판단 기준이랑 실제 응대 사례를 같이 적어뒀어요.
규칙만 달랑 있으면 결국 “이번 건은 어떻게 해결해야 하죠?” 하고 또 묻게 되잖아요.
이 가이드북 덕분에 답변 작성과 함께 고객 대기 시간이 줄고, FAQ 오피셜 DB를 구축하고 기록하는 데 큰 도움이 됐습니다.
2. 채널톡 워크플로우 구축: 끝나지 않는 문의에 마침표를!
CS 문의 종료 기준을 세우며 채널톡 워크플로우를 새로 만들었습니다.
이번 달 자동화 작업 중 가장 손이 많이 간 일이에요.
CS 업무를 처리하면서 저를 가장 애매하게 했던 게 ‘종료되지 않는 문의’였어요.
그래서 문의 종료를 위한 워크플로우를 도입하기로 했습니다.
처음 만든 워크플로우는 매니저가 마지막 답변을 하면 자동으로 워크플로우가 작동하도록 했는데,
고객께서 "감사합니다"라고 마무리 인사를 보내면 그 이후에 또 뜬금없이 "더 궁금하신 점 있으실까요?"가 나가는 거예요.
그래서 '진행중'인 문의가 '종료됨'으로 넘어가는 데 오랜 시간이 걸렸고, 실제 문의 현황이랑 데이터가 계속 어긋났어요.
그래서 기존 워크플로우 작동을 중단하고 모듈형 워크플로우를 새로 만들었습니다. 채팅창 → 워크플로우 트리거 → 상담 종료 요청하기 구조로, 채팅창에서 담당자가 ‘아, 이건 종료해도 되겠다’ 싶을 때
직접 트리거를 눌러서 호출하는 방식으로 변경했어요. 종료가 필요하다고 판단한 순간에 직접 호출할 수 있도록 했습니다.
"태니지먼트입니다. 더 궁금하신 점 있으실까요?" 메시지 + 응답 버튼
→ "없어요" 선택 시: 종료 안내 → 상담 종료
→ "있어요" 선택 시: 워크플로우 종료 (고객 문의 입력창 열림)
워크플로우를 만들면서 깨달은 게 있어요.
처음엔 인사말 없이 “더 궁금하신 점 있으실까요?”라는 문구와 함께 상담 링크만 보냈는데, 고객 입장에서 보니까 너무 스팸 같은 거예요.
링크를 누르면 내 정보가 다 털릴 것 같은 느낌!
그래서 다급하게 앞에 “태니지먼트입니다”를 붙였죠.
자동화는 내가 세팅하는 순간이 아니라, 고객이 화면에서 직접 확인하는 순간에 완성된다는 걸 뼈저리게 느꼈습니다.
고객이 오프라인일 때 문자가 전송되면 건당 1원씩 든다는 거, 연락처를 남기지 않으면 전송되지 않는다는 것도 직접 테스트하며 확인했어요. 그리고 워크플로우가 작동했는데도 고객 반응이 없다면 작동 24시간 경과 후 언제든 종료해도 된다는 명확한 기준을 세워서 [CS문의 종료 기준]으로 정책 문서를 남겼습니다.
*채널톡 모듈형 워크플로우 설정은 이렇게 하시면 돼요! (자세히 알아보기)
[+새 워크플로우 만들기] → [새로 만들기] → [모듈형 워크플로우] 트리거 선택 → [트리거 설정] → [상담에서 사용하기]
3. CS 문의 대시보드: 느낌 말고 숫자로 말하기
채널톡/카카오톡, 이메일로 여기저기 흩어져서 들어오는 문의들을 하나의 로그 DB로 모아 대시보드와 분석 리포트를 만들었어요.
주별 추이, 채널 비중, 문의 유형 분포, 아직 해결 안 된 목록까지 한눈에 볼 수 있도록요!
”CS 문의 처리 잘하고 있습니다”가 아니라, “이번 주 18건, 해결률 97%, 미해결 1건 이유는 이러합니다.”라고 명확한 숫자로 말하고 싶었거든요.
매주 월요일마다 [구글 시트 CSV 추출 → 로그 연결 → 중복 확인 → 개선점 작성]이라는 루틴을 고정했어요.
덕분에 8월 월간 리포트를 무사히 완성했고, 9월부터는 매주 월요일마다 주간 리포트도 뽑아낼 예정이에요.
매주 “이번 주는 뭘 개선해야 하지?”, “이번 주에 봐야할 일이 뭐가 있지?” 고민할 시간을 줄이려고요.
4. Slack ↔ 구글폼 웹훅 연결: 보고도 효율적으로!
기존에는 전문가 양성 과정이 언제 열리는지 유저가 확인하기 참 어려웠어요.
블로그 홈페이지에서 확인하기 어려우니, CS 채널로 유입이 되었고요.
그래서 안내 화면을 '개편 중'으로 바꾸고, 오픈 알림 명단을 등록할 수 있도록 구글폼을 붙여두었어요.
실제로 구글폼 도입 전에는 전체 문의 중 전문가 양성 과정 알림 문의 비중이 7.56%~10.53%나 됐는데,
폼 도입 후에는 이 문의가 0건으로 뚝 떨어졌답니다!
2025.01.01~2026.07.21 : 유효 문의 807건 중 전문가 양성 과정 오픈 문의 61건 (7.56%)
2026.08 전체 문의 57건 중 전문가 양성 과정 오픈일 문의 6건(10.53%)
그런데 폼에 수집되는 응답을 제가 일일이 확인해서 보고하는 건 또 다른 비효율이더라고요.
효율 따지기를 좋아하는 저는 ‘효율을 높일 방법’으로 ‘웹훅(Webhooks)’을 썼습니다.
구글폼에 응답이 들어올 때마다 슬랙으로 알림이 오게 만드는 거죠.
컴퓨터와 별로 안 친한 저도 제 단짝 제미나이와 함께 한시간 반 동안 씨름한 끝에 결국 성공했답니다.
이 글을 읽는 분은 30분 내로 성공하시길 바라는 마음으로 그 과정을 공유해 드릴게요.
[Slack 웹훅 URL 발급받기]
1. 알림을 받을 Slack 채널 접속 → 상단 이 channel의 모든 멤버 보기 클릭
2. 에이전트 및 앱 탭에서 에이전트 또는 앱 추가 클릭
3. Incoming Webhooks 검색해서 보기 클릭 → 구성 클릭
4. 워크스페이스 확인 후 Slack에 추가 클릭 → 알림 받을 채널 선택하고 수신 웹후크 통합 앱 추가 클릭
5. 생성된 https://hooks.slack.com/services/... URL 복사
(고유한 웹후크 URL이기에 노출되면 안 돼요!)
[코드 스크립트 작성 (AI에게 맡기기를 강력 추천합니다)]
1. 구글폼 편집 화면 우측 상단 더보기(⋮) 클릭 → Apps Script 클릭
2. Code.gs (❮ ❯) 화면에서 가운데 코드 영역 아무 데나 클릭하고 전체 선택 후 전부 지우기
3. AI에게 받은 코드 스크립트를 전체 복사해 붙여넣기
4. 여기까지 했다면 저장!
[웹훅 URL 세팅]
1. 좌측 맨 아래 톱니바퀴(⚙️) 프로젝트 설정 클릭
2. 스크립트 속성 수정 클릭
3. 속성: SLACK_WEBHOOK_URL 입력 (코드 스크립트에 있던 속성이에요)
값: 미리 복사해둔 웹훅 URL을 넣고 저장
[트리거 설정하기]
1. 좌측 시계 모양(⏰) 트리거 클릭
2. 우측 하단 트리거 추가 클릭
3. 이벤트 소스를 '설문지에서', 이벤트 유형을 '양식 제출 시'로 설정하고 저장
이제 폼을 제출해 보고 슬랙에 알림이 잘 오면 대성공입니다!
8월의 수확물: 예상 결과물 퀘스트 점검📨
온보딩에서 세웠던 8월의 목표들, 과연 얼마나 이뤘을까요?
-
FAQ·문의 분석표 (완료)
2025년 1월부터 2026년 7월까지 축적된 CS 문의 DB에서 의미 없는 데이터 447건은 과감하게 걷어내고, 진짜 의미 있는 알짜배기 데이터 807건만 남겼어요. 이를 통해 FAQ 생성의 뼈대를 잡았죠.
그리고 8월 문의부터는 새로 만든 CS 로그 DB와 대시보드에 착실히 기록하고 있어요.
신규 FAQ를 생성할 때에는 “왠지 자주 묻는 것 같은데?” 하는 감에 의존하는 것이 아니라, ‘반복 빈도·고정성·셀프 해결 가능성·모든 고객에게 적용 가능한가’ 같은 명확한 [FAQ 선정 기준]을 규칙으로 세워서 객관적으로 관리하고 있어요.
-
대표 페르소나의 여정맵 (진행 중)
단순히 나이나 직업 같은 뻔한 속성 말고, 페르소나 별 구체적인 상황, 핵심 문제, 해결하고 싶은 니즈, 그리고 스스로 문제를 인식하게 된 계기를 중심으로 4개의 페르소나를 뾰족하게 뽑아냈어요.
그중에서도 인구수가 가장 많고 문제의 임팩트가 제일 컸던 ‘취준생’을 대표 페르소나로 최종 선정했습니다.
사실 대표 페르소나를 선정하기까지 시행착오가 정말 많았습니다.
기존에 잡았던 여정맵, 우리 서비스가 들어갈 지점, 유저한테 줄 가치, 기능 요구사항 등 고려할 게 너무 많았거든요. 그러다 보니 페르소나가 자꾸 흔들리고, “어차피 태니지먼트를 쓰게 된다”고 전제해 버리니까 결국 모두가 똑같은 상황과 문제로 귀결되면서 길을 잃는 기분이었어요. 사람의 경험을 하지 못하고 입력한대로 수행하는 AI는 별 도움이 되지 못했고요.
‘역기획’ 방식으로 접근해야 제대로 된 여정맵이 나온다는 걸 머리로는 알면서도, ‘태니지먼트’의 틀에서 벗어나는 게 참 힘들더라고요.
그래도 대표 페르소나를 선정할 때는 우리 서비스에 매이지 않고 통계 데이터에만 집중했더니, 드디어 태니지먼트에서 살짝 멀어질 수 있었습니다.멀어지고 나니까 ‘아, 이제 진짜 내가 그리려던 여정맵을 그릴 수 있겠다’ 하는 자신감이 생기더라고요!
9월에는 멋진 여정맵을 완성해서 꼭 공유해 드리고 싶어요. -
고객 언어 아카이브 (우회)
아직 별도의 산출물 형태로 만들지 않았지만, 완전히 손 놓고 있었던 건 아니에요.
CS 대시보드에 문의를 기록할 때, 문의 제목을 “A워크스페이스에서 결제한 리포트를 B워크스페이스에 연동하여 팀다이어그램을 확인하고 싶습니다."처럼 고객이 실제로 표현한 문장 그대로 기록해 두고 있거든요.
이 아카이브를 기획했던 이유가 결국 고객이 우리 서비스를 이용하면서 정확히 어떤 언어와 표현을 쓰는지 파악하기 위해서였는데요.
지금 이렇게 쌓인 원재료만 57건이라, 유저들의 실제 표현 습관을 파악하기에는 이미 충분한 바탕이 마련되었다고 생각해요.
에필로그💬
8월 초만 해도 전 자동화가 단순히 ‘내 일을 줄여주는 기술’인 줄 알았어요.
그런데 한 달을 겪어보니 아니더라고요. 자동화는 ‘사람이 해야 할 일에 시간을 몰아주는 배분 기술'이었습니다.
워크플로우를 만들어 규칙이 알아서 상담 종료 여부를 물어봐 주니까, 저는 "이 문의 종료된 건가?" 판단하는 대신 고객이 남긴 문의 내용을 다시 들여다볼 수 있었어요. 가이드북을 만든 덕분에 답을 찾는 시간이 줄어드니, "왜 똑같은 문의가 인입되는 거지?" 하고 원인을 생각할 여유가 생겼고요.
물론 아쉬운 점도 있습니다.
개인 프로젝트로 욕심냈던 페르소나 여정맵은 아직도 다듬는 중이고, 자동화도 ‘상담 종료’ 쪽에만 치우쳐 있어서 문의가 처음 들어오는 입구는 여전히 100% 제 손을 거치고 있거든요. 9월에는 제 손이 닿기 전 봇이 해결하는 ‘완벽한 자동화’를 이뤄내고 싶습니다.
이번 회고의 목적은 다음과 같았어요.
첫째, 8월에 제가 한 자동화가 단순한 ‘툴 만지기’가 아니라 분명한 목적을 가진 작업이었음을 스스로 점검하고
둘째, 고객을 이해하는 과정이 이제 감이 아닌 ‘데이터와 루틴’ 위에서 돌아가고 있다는 걸 보여드리고 싶었어요.
좌절도 하고, 기뻐도 하고, 때로는 고뇌하고 뿌듯해할 저의 성장 스토리를 끝까지 함께해 주세요!
