CS 정책 플레이북¶

🚧 내용 추가 필요

이 플레이북은 확정된 CS 운영 문서(raw 출처)에서 온 게 아니라, 제품 원칙·QA 분류 기준을 바탕으로 합리적 골격을 미리 잡아 둔 초안이다(source: []). 아래 두 가지를 실제로 확정해 주세요: ① 실제 CS 접수 채널 — 인앱 문의하기·FAQ가 정말 화면에 붙어 있는지, 카톡 오픈채팅·이메일 주소가 무엇인지(tools-accounts에 등재). ② 실제 응대 사례 — 알파/베타에서 실제로 들어온 문의 유형과 처리 결과를 1~2건이라도 적어, 분류표·우선순위가 우리 현실과 맞는지 검증. 사례가 쌓이면 반복 문의는 faq로, 반복 버그는 qa-playbook 회귀 케이스로 흘려보낸다.

알파·MVP 단계에선 사용자 한 명의 경험이 곧 제품의 생사다. 기본 동선 하나가 막히면 그건 단순 불편이 아니라 이탈이고, 초기 신뢰는 한 번 깨지면 회복이 어렵다. 그래서 사용자 문의·버그 제보·불만을 어떤 경로로 받고 어떻게 처리할지를 미리 정해뒀다. 아직 전담 CS 인력이 없어 전원이 나눠 맡는데, 접수 뒤 분류 결과에 따라 담당이 갈린다 — 버그는 개발이, 장애는 인시던트 담당이, 사용 문의는 FAQ 담당이 가져간다.

접수 채널¶

사용자가 우리에게 닿는 입구는 넷이다. 그중 인앱 문의하기와 FAQ는 1차 셀프서비스 창구라 화면에 항상 노출돼 있어야 한다 — 이게 묻혀 있으면 사용자는 길을 잃는다(그래서 qa-playbook UX 관찰 포인트로도 본다).

채널	용도	비고
인앱 문의하기 / FAQ	1차 셀프서비스·문의	항상 노출. FAQ는 faq
버그 제보 경로	인앱 버그 신고	화면·동작·환경 등 재현 정보 수집
카톡 오픈채팅	외부 사용자 소통	마케팅 채널과 공유
이메일	외부·공식 문의	마케팅 채널과 공유

채널 계정은 tools-accounts에, 런치 때 피드백을 어떻게 연결하는지는 gtm-launch-checklist에 있다.

들어온 문의를 어떻게 가르나¶

접수된 것을 성격에 따라 네 갈래로 분류한다. 갈래가 정해지면 라우팅과 우선순위가 따라온다.

유형	어디로	우선순위
버그	Jira "디에듀QA"에 Bug 등록 후 개발 티켓과 링크. 재현 절차 필수	기본 동선 차단이면 최우선(P0)
기능 요청·피드백	feedback · ideas로	백로그 → 기획 반영
긴급(서비스 장애)	CS 흐름이 아니라 즉시 인시던트 절차 — incidents + 런북(version-control)	즉시
사용 문의(how-to)	FAQ로 답하고, 없으면 faq에 추가	일반

여기서 P0, 즉 최우선으로 다루는 건 로그인·회원가입·문의·탈퇴처럼 기본 동선이 막히는 제보와 결제·데이터 손실 위험이다. 우리에겐 이게 단순 버그가 아니라 신뢰 문제이기 때문이다.

처리 흐름¶

접수하면 먼저 위 네 갈래로 분류해 담당을 정한다. 그다음 임시 응답을 보내 접수됐다는 것과 예상 처리 시점을 알린다 — 방치가 가장 나쁘다. 본 처리는 버그면 재현→티켓→픽스로, 장애면 런북 가동으로 간다. 처리가 끝나면 결과나 일정을 반드시 회신한다. 마지막으로, 반복되는 문의는 faq나 릴리즈 노트(release-announce)에, 반복되는 버그는 QA 회귀 케이스(qa-playbook)로 흘려보내 같은 문제가 다시 안 오게 한다.

접수·처리에 쓰는 도구는 인앱 문의하기/FAQ, 버그 제보 경로, 카톡 오픈채팅, 이메일, 그리고 버그 티켓과 약속을 박제하는 Jira "디에듀QA"다. 접근 경로는 tools-accounts에 있다.

응대할 때 지키는 것¶

몇 가지 태도를 합의해 뒀다. 답변은 사과·공감을 먼저, 사실·일정을 그다음에 둔다. 추측을 단정하지 않고, 모르면 "확인 후 회신"이라 말한다. 사용자에게 한 약속은 Jira 이슈 코멘트에 박제해 휘발을 막는다(how-we-work). 그리고 무엇보다 루프를 닫는다 — 회신 없이 끝내지 않고 처리 결과를 반드시 알린다.

CS 정책 플레이북¶

접수 채널¶

들어온 문의를 어떻게 가르나¶

처리 흐름¶

응대할 때 지키는 것¶

관련¶