자주 묻는 질문

제품을 막 내놓은 팀은 문의를 한 건씩 손으로 답합니다. 하루에 다섯 건이면 담당자가 메일을 열어 한 통씩 쓰면 되니 그렇게 굴러갑니다. 문제는 그 다섯 건 가운데 셋이 어제 답한 것과 똑같은 질문이라는 데서 시작합니다.

페이지덱 초기에 수아는 "결제 카드를 바꾸려면 어디로 가나요" 라는 메일에 같은 답을 일곱 번째 쓰고 있었습니다. 매번 새로 쓰기는 아까워서 지난 메일함을 뒤져 복사하는데, 그 답을 찾는 데만 10분이 들었습니다. 게다가 일곱 통의 문장이 조금씩 달랐습니다. 어떤 답에는 카드 변경 뒤 다음 결제일이 언제인지가 적혀 있고 어떤 답에는 빠져 있어서, 빠진 답을 받은 고객이 며칠 뒤 그것만 다시 물어 왔습니다.

같은 답을 여러 번 쓰는 낭비보다 큰 문제는 답이 사람마다, 또 같은 사람 안에서도 흔들린다는 점입니다. 그래서 반복되는 질문만 따로 모아 답을 한 번만 확정해 두고 그 문서를 가리키기로 한 것이 자주 묻는 질문입니다. 답을 고쳐야 할 일이 생기면 문서 한 곳만 고치면 됩니다.

고객 지원 운영에서 이 문서는 고객이 스스로 답을 찾게 만드는 셀프서비스 갈래에 속합니다. 접수된 문의를 빨리 처리하는 쪽이 아니라 애초에 접수되지 않게 만드는 쪽입니다. 그래서 잘 쓰였는지는 답변 속도가 아니라 문의 감축, 즉 고객이 스스로 답을 찾아 문의를 넣지 않은 비율로 확인합니다.

한 항목은 질문 한 줄과 답 두세 문장, 그리고 이어지는 동작 하나로 이뤄집니다. 이 셋이 한 덩어리이고, 덩어리를 주제별로 묶은 것이 문서 전체입니다.

1. 질문 — 고객이 실제로 쓰는 말 그대로 적습니다. "요금제 변경 정책" 이 아니라 "결제 카드를 바꾸려면 어떻게 하나요" 입니다. 고객은 제품의 기능 이름을 모르는 채로 검색창에 치기 때문에, 내부 용어로 제목을 달면 답이 문서 안에 있어도 찾지 못합니다.
2. 답 — 두세 문장으로 끝냅니다. 배경 설명이나 예외 조항을 앞에 두면 고객은 세 줄째에서 읽기를 그만두고 문의를 넣습니다. 결론을 먼저 쓰고 예외는 뒤에 한 줄로 답니다.
3. 이어지는 동작 — 답을 읽은 사람이 바로 할 일로 연결합니다. 결제 화면으로 가는 링크, 신청 서식, 담당자에게 문의하는 버튼 같은 것입니다. 이 줄이 없으면 고객은 답을 읽고도 어디로 가야 할지 몰라 결국 문의를 넣습니다.

여기에 문서를 운영하기 위한 항목이 둘 더 붙습니다. 분류는 질문을 주제별로 묶는 이름표입니다. 결제, 계정, 권한처럼 대여섯 개면 충분하고, 스무 개로 쪼개면 고객이 어느 칸을 열어야 할지 고민하게 됩니다. 갱신 날짜와 담당자는 각 항목이 언제 마지막으로 확인됐고 틀렸을 때 누구에게 말해야 하는지를 남깁니다.

순서도 구성의 일부입니다. 가나다순이나 기능 순서가 아니라 물어본 횟수가 많은 순으로 놓습니다. 지난달 접수된 지원 티켓, 그러니까 번호와 담당자와 상태가 붙은 문의 한 건씩의 기록을 세어 보면 상위 열 개 질문이 전체의 절반을 넘는 경우가 흔합니다. 그 열 개를 맨 위에 두면 고객 절반이 첫 화면에서 답을 봅니다.

쓰는 사람은 문의를 직접 받는 지원 담당이고, 사실이 맞는지는 그 기능을 만든 사람이 확인합니다. 지원 담당이 쓰는 이유는 고객이 어떤 말로 묻는지를 그 사람만 알기 때문이고, 만든 사람이 확인하는 이유는 예외 조건을 그 사람만 알기 때문입니다. 개발자가 혼자 쓰면 정확하지만 아무도 검색으로 찾지 못하는 문서가 되고, 지원 담당이 혼자 쓰면 읽기는 쉬운데 틀린 답이 반년 동안 걸려 있게 됩니다.

읽는 쪽은 셋입니다.

1. 고객 — 문서를 직접 열어 읽습니다.
2. 상담 담당 — 답변에 이 문서를 붙여 보냅니다. 자주 쓰는 답변을 미리 저장해 두는 매크로도 대개 이 문서의 문장을 그대로 가져다 쓰므로, 문서를 고치면 매크로도 함께 고쳐야 답이 어긋나지 않습니다. 사람을 대신해 대화 창구에서 답하는 챗봇도 마찬가지로 이 문서를 읽어 답을 고릅니다.
3. 검색엔진 — 질문 형태의 제목과 짧은 답은 검색 결과 맨 위에 답만 발췌해 보여 주는 피처드 스니펫에 뽑히기 좋은 모양입니다. 그래서 잘 만든 문서는 지원 비용을 줄이면서 검색 유입도 함께 가져옵니다.

"이 질문 이번 주에만 열두 번 들어왔어요. FAQ에 올릴까요?"

문의 기록에서 반복이 확인됐으니 문서로 올려 앞으로는 사람이 답하지 않게 하자는 제안입니다.

"FAQ에 있긴 한데 아무도 못 찾는 것 같아요."

답은 있는데 제목이 고객이 쓰는 말과 달라 검색으로 걸리지 않는다는 뜻입니다.

"정책이 바뀌었으니 FAQ부터 고치고 공지 나갑시다."

문서가 답의 원본이라 여기를 고치지 않으면 상담 답변과 공지가 서로 다른 말을 하게 된다는 뜻입니다.

페이지덱에서는 달마다 수아와 지현이 마주 앉아 지난달 문의를 훑습니다. 수아가 많이 들어온 질문 열 개를 뽑아 오면 지현이 그 자리에서 둘로 나눕니다. 문서로 답하면 끝나는 질문과, 제품을 고쳐야 사라지는 질문입니다. "초대 링크가 만료됐다는데 왜 만료되나요" 는 앞쪽이라 그날 문서에 한 줄이 늘고, "저장 버튼이 어디 있는지 모르겠다" 는 뒤쪽이라 제품 과제로 넘어갑니다.

항목이 많을수록 좋은 문서라고 생각하기 쉽습니다. 질문을 빠짐없이 담아 두면 고객이 무엇을 묻든 답이 있으니 그럴듯합니다. 실제로는 항목이 늘수록 고객이 자기 질문을 찾을 확률이 떨어집니다. 서른 개가 걸린 화면에서 고객은 제 질문을 눈으로 훑어 찾다가 포기하고 문의를 넣습니다. 그대로 두면 문서는 계속 길어지는데 문의는 줄지 않고, 담당자는 이미 문서에 답이 있는 질문에 계속 답하게 됩니다. 문의가 많은 순으로 자르고 아래쪽은 주제별 문서로 옮기는 편이 낫습니다.

이 문서로 제품 문제를 덮을 수 있다고 보는 것도 흔한 오해입니다. 고객이 헤매면 설명을 붙이면 된다는 생각이라 자연스럽지만, 반대로 읽어야 맞습니다. 같은 질문이 한 달에 백 건씩 들어온다는 것은 그 화면이 스스로 설명하지 못한다는 신호입니다. 문서를 붙이면 그 신호가 숫자에서 사라지기 때문에, 고칠 자리를 영영 못 찾은 채 설명만 쌓입니다. 잘 굴러가는 팀은 새 항목을 올릴 때마다 제품 과제 후보로도 한 줄 남겨 둡니다.