매크로

고객 지원 창구에 들어오는 지원 티켓은 생각보다 종류가 적습니다. 결제 영수증을 다시 받고 싶다, 비밀번호를 못 바꾸겠다, 팀원을 더 초대하고 싶다 같은 질문이 전체의 대부분을 차지합니다. 그런데 답변은 매번 새로 쓰였습니다. 하루에 같은 질문을 열두 번 받은 담당자가 열두 번 같은 문장을 타이핑했고, 그러면서 조금씩 다르게 썼습니다.

그 결과 두 가지가 무너졌습니다. 하나는 속도입니다. 3분이면 끝날 답을 쓰는 데 8분이 들면 하루에 처리하는 건수가 절반 가까이 줄어듭니다. 다른 하나는 일관성입니다. 같은 환불 문의에 한 사람은 "영업일 기준 3일" 이라고 답하고 다른 사람은 "일주일 정도" 라고 답하면, 두 답을 나란히 받아 본 고객은 어느 쪽도 믿지 않습니다.

페이지덱에서도 이 문제가 개인 메모로 버텨지던 시기가 있었습니다. 담당자마다 자기 메모장에 자주 쓰는 문장을 모아 두고 복사해 붙였습니다. 수아가 휴가를 간 주에 대신 답하던 사람이 수아의 메모를 볼 수 없어서 환불 안내를 처음부터 다시 썼고, 그 문장에 이전과 다른 기한이 적혀 나갔습니다. 개인이 들고 있던 문장을 팀의 자산으로 꺼내 놓는 장치가 매크로입니다.

같은 문제를 도움말 센터로 푸는 방법도 있습니다. 고객이 직접 찾아볼 수 있게 정리해 둔 문서 모음인데, 이쪽은 문의가 들어오기 전에 작동합니다. 매크로는 이미 들어온 문의에 붙으므로 둘은 앞뒤로 놓입니다.

매크로 하나는 문장 한 덩어리가 아닙니다. 지원 도구에 등록할 때 함께 채우는 항목이 다섯 가지 있습니다.

1. 이름과 분류 — 담당자가 답변 창에서 검색해 찾는 이름입니다. "환불1" 처럼 짧게 적으면 본인 말고는 아무도 못 찾으므로, "결제/구독 취소 후 환불 일정 안내" 처럼 상황이 드러나게 적습니다.
2. 제목 — 메일로 나갈 때 쓰이는 제목 줄입니다. 창구가 채팅뿐이면 비워 둡니다.
3. 본문 — 실제로 나가는 문장입니다. 인사, 답, 다음에 할 일, 마무리 순으로 짜 두면 담당자가 가운데만 손보게 됩니다.
4. 치환 변수 — 불러오는 순간 자동으로 채워지는 자리입니다. 고객 이름, 티켓 번호, 요금제 이름 같은 값이 들어갑니다. 변수를 쓰지 않고 "고객님" 으로만 두면 편하지만, 이름이 들어간 답변과 안 들어간 답변의 체감 차이는 큽니다.
5. 함께 실행되는 동작 — 문장을 넣는 것 외에 티켓 상태를 대기로 바꾸거나, 분류 태그를 붙이거나, 담당을 2차 지원으로 넘기는 동작을 묶어 둡니다. 나중에 어떤 문의가 몇 건이었는지 세는 근거가 여기서 쌓입니다.

본문을 쓸 때 걸리는 것은 언제나 분량입니다. 한 매크로에 모든 경우를 담으려 하면 고객이 자기와 상관없는 문단까지 읽게 됩니다. 월 결제와 연 결제의 환불 계산이 다르면 하나에 둘을 다 넣지 말고 두 개로 나눕니다. 고르는 데 드는 5초가 고객이 읽는 데 드는 1분보다 쌉니다.

쓰는 사람은 문의를 가장 많이 받아 본 지원 담당자입니다. 페이지덱에서는 수아가 초안을 잡습니다. 새 문장을 지어내는 것이 아니라 이미 보낸 답변 중에서 고객이 되묻지 않고 끝난 것을 골라 다듬습니다. 실제로 통한 문장이 가장 좋은 초안이기 때문입니다. 환불 기한이나 약관 해석처럼 틀리면 곤란한 대목은 등록 전에 규원이 한 번 확인합니다.

읽는 쪽은 셋입니다.

1. 지원 담당자 — 답변 창에서 불러 쓰는 사람입니다. 이들에게 필요한 것은 잘 쓴 문장보다 찾기 쉬운 이름이고, 고쳐야 할 부분이 어디인지 한눈에 보이는 구조입니다.
2. 새로 합류한 담당자 — 매크로 목록은 그 자체로 교육 자료입니다. 이 회사가 어떤 문의를 받고 각각에 어떤 태도로 답하는지가 문장으로 정리돼 있어서, 첫 주에 목록을 훑는 것만으로 업무 범위가 잡힙니다.
3. 고객 — 최종 독자입니다. 고객은 이 답변이 틀에서 나왔는지 모르고 읽습니다. 그래서 "안녕하세요 고객님, 문의 주셔서 감사합니다" 로 시작해 아무 정보 없이 끝나는 매크로는 없느니만 못합니다. 읽는 사람이 다음에 무엇을 해야 하는지가 문장 안에 있어야 합니다.

"이건 매크로로 빼죠. 이번 주에만 같은 질문 서른 건이에요."

반복이 확인됐으니 답변을 틀로 만들어 두자는 제안입니다.

"그 매크로 문구 옛날 정책이에요. 환불 기한 바뀐 거 반영 안 됐어요."

저장된 문장이 실제 정책과 어긋난 채로 나가고 있다는 경고입니다.

"매크로 넣고 두 번째 문단은 고객 상황 맞춰서 고쳐 보내세요."

틀을 그대로 보내지 말고 개별 사정을 반영하라는 지시입니다.

페이지덱이 기업용 플랜을 열면서 문의가 한 달 만에 두 배로 늘었을 때 수아가 먼저 한 일이 매크로 정리였습니다. 지난 석 달 티켓을 분류해 보니 상위 여덟 개 질문이 전체의 60퍼센트였고, 그 여덟 개를 먼저 만들었습니다. 그다음 달 첫 응답 시간이 평균 4시간에서 1시간 반으로 줄었습니다. 문의가 들어온 뒤 사람이 처음 답할 때까지 걸린 시간을 재는 숫자입니다.

대신 분기마다 한 번씩 목록을 훑는 일정을 같이 잡았습니다. 제품이 바뀌면 안내 문장도 같이 틀려지는데, 매크로는 한 번 등록하면 아무도 다시 열어 보지 않아서 틀린 채로 반년을 나갑니다. 수아는 화면 이름이 바뀐 달에 그 단어가 들어간 매크로를 검색해 한 번에 고쳤습니다.

매크로를 쓰면 성의 없어 보인다는 걱정이 가장 흔합니다. 직접 쓴 문장이 더 정성스럽다는 감각은 자연스럽습니다. 하지만 고객이 느끼는 성의는 문장을 새로 썼는지가 아니라 자기 상황에 맞는 답을 받았는지에서 나옵니다. 오히려 매번 새로 쓰면 급할 때 빠뜨리는 항목이 생기고, 잘 다듬어 둔 틀에서 한 문단만 고쳐 보낸 답변이 더 친절하게 읽힙니다. 문제는 틀을 쓰는 것이 아니라 고칠 자리를 안 고치고 보내는 것입니다.

매크로가 많을수록 좋다고 생각하는 것도 자주 보는 오해입니다. 문의 종류마다 하나씩 만들어 두면 빈틈이 없어 보이기 때문입니다. 그런데 200개짜리 목록에서는 담당자가 원하는 것을 못 찾아 결국 직접 씁니다. 게다가 안 쓰는 매크로일수록 내용이 낡아 있어서, 어쩌다 한 번 불려 나갈 때 틀린 정보를 내보냅니다. 상위 20개가 문의의 절반을 덮는 편이 100개가 흩어져 있는 편보다 낫고, 석 달 동안 한 번도 안 쓰인 매크로는 지웁니다.