2026-11-05
콜센터·고객 지원 일일 보고 쓰는 법: 응대 기록이나 티켓과 나누고, 문의 속 알아차림을 다음 날의 한 수로 잇기
콜센터·고객 지원의 일일 보고는 응대 건수나 응답률의 사본이 아니라, 응대에서 시도한 것과 그 결과, 자주 오는 문의의 변화나 안내의 알기 어려운 점 같은 응대 속 알아차림, 곤란한 일과 상의하고 싶은 일을 P·D·C·A의 짧은 형식으로 쓰면, 티켓이나 통화 기록, CRM의 응대 기록 같은 정해진 기록과 역할을 나눈 채로 다음 날의 응대와 팀의 개선으로 이어집니다.
넣을 항목, 역할별 예문, 정해진 기록과의 선 긋기, 고객 개인정보의 취급, 폭언이나 괴롭힘을 당했을 때 혼자 떠안지 않고 책임자에게 잇는 것, 슈퍼바이저나 리더가 읽는 법을 설명합니다.
고객 지원의 일일 보고가 '건수의 사본'이 되는 이유
콜센터나 고객 지원의 일일 보고는 '전화와 메일을 차례로 처리. 특별한 문제 없음'처럼 그날 응대한 건수와 끝낸 작업을 늘어놓는 데 그치기 쉽습니다.
건수의 기록은 중요하지만, 그것만으로는 '어떤 응대가 잘되었고 어디에서 망설였는지', '내일 응대에서 무엇을 바꿔 볼지'가 남지 않습니다.
게다가 고객 지원 현장에는 티켓, 통화 기록, CRM의 응대 이력, 에스컬레이션 기록 등 회사 규정이나 정해진 절차에 따라 남기는 기록이 이미 있습니다.
그래서 일일 보고는 같은 내용을 한 번 더 쓰는 작업처럼 보이기 쉬운 것이 실정입니다.
응대 틈틈이나 근무가 끝날 무렵 서둘러 쓰고, 읽은 사람에게서 답도 없으면, 쓰는 쪽은 '특이 사항 없음' 한마디로 끝내게 됩니다.
PDCA로 말하면 실행(D)의 기록에서 멈추고, 평가(C)와 개선(A)이 빠진 상태입니다.
이 글에서는 일일 보고를 '정해진 기록의 사본'에서 '그날 응대의 알아차림을 돌아보고 다음 날의 응대와 팀의 배움으로 잇는 도구'로 다시 자리매김하는 쓰는 법을 생각합니다.
여기서 말하는 일일 보고는 응대 기록이나 티켓을 대신하는 것이 아니라, 구성원끼리 알아차림을 건네기 위한 짧은 돌아보기입니다.
누군가를 탓하는 이야기가 아니라 구조에 관한 이야기로 읽어 주세요.
일일 보고에 넣을 항목: 건수 기록보다 응대의 돌아보기·문의의 변화·내일의 한 수
콜센터나 고객 지원 담당자의 일일 보고에 넣을 항목은 다음 정도로 좁히면 계속하기 쉬워집니다. ① 오늘의 목표(어떤 종류의 문의에서 어떤 안내 방식이나 확인 순서를 시도할지).
② 실제로 해 보니 어땠는지(잘된 점, 생각대로 되지 않은 점).
③ 응대 속에서 알아차린 것(자주 오는 문의의 변화, 매뉴얼이나 FAQ의 안내가 알기 어렵다고 느낀 점, 자신의 응대에 대한 돌아보기 등).
④ 팀에서 공유하고 싶은 것(같은 근무조의 구성원이나 다음 근무조에 건네고 싶은 것). ⑤ 곤란한 일과 누구에게 무엇을 상의하고 싶은지. ⑥ 내일의 첫 한 수.
요점은 티켓이나 응대 이력에 남겨야 할 내용을 일일 보고에서 되풀이하지 않고, 자신의 응대에 대한 돌아보기와 팀에서 공유하고 싶은 것, 상의할 일로 좁히는 것입니다.
반대로 '이번 주 들어 요금 확인 방법을 묻는 문의가 늘고 있다', '도움말 페이지의 순서가 고객 화면의 표시와 달라서 설명에 시간이 걸렸다' 같은 알아차림은 한 건 한 건의 기록에는 남기 어렵습니다.
이는 일일 보고에서만 건질 수 있는 정보입니다.
일일 보고에는 고객의 이름이나 번호를 쓰지 않고 '요금에 관한 문의', '로그인에 관한 문의'처럼 문의의 종류로 쓰는 운영을 해 두면 개인정보를 끌어들이지 않아도 됩니다.
칸을 너무 늘리면 쓰는 시간이 길어지고 빈칸이 늘어납니다. 처음에는 다섯 개 안팎으로 시작해, 구성원의 목소리를 들으며 더하고 뺍니다.
예문 1: 전화 응대 상담원의 일일 보고와 다음 날 P로 잇는 법
일일 보고 PDCA의 형식은 P(오늘의 목표)·D(실제로 한 일)·C(알아차림)·A(다음에 어떻게 할지)와 다음 날의 P, 이렇게 다섯 가지입니다.
전화 응대를 맡은 상담원을 예로 들어 보겠습니다(내용과 숫자는 설명을 위한 가상의 예입니다).
P는 '로그인이 안 된다는 문의에서 확인할 항목을 정해 둔 순서대로 묻고, 보류하는 횟수를 줄인다'.
D는 '오전의 로그인 문의 8건 가운데 3건에서 도중에 확인 순서가 뒤섞여, 고객을 보류해 두고 매뉴얼을 다시 봐야 했다. 통화 한 건 한 건이 평소보다 길어졌다'.
C는 '고객이 쓰는 기기의 종류를 먼저 묻지 않으면 매뉴얼의 어느 페이지를 열지 정할 수 없다. 매뉴얼의 항목 순서와 실제로 묻는 순서가 맞지 않았다'.
A는 '내일은 먼저 기기의 종류를 확인한 다음 매뉴얼의 페이지를 연다. 매뉴얼의 순서에 대해서는 리더에게 상의한다'.
다음 날의 P는 '기기의 종류를 먼저 묻고, 보류 없이 확인을 진행한다'. 다음 날의 P로 잇는 요령은 A를 '다음에 할 구체적인 한 가지'로 쓰는 것입니다.
'매끄러운 응대를 의식한다'가 아니라 '먼저 기기의 종류를 확인한다'라고 쓰면, 다음 날의 일일 보고에서 했는지 못 했는지를 확인할 수 있습니다.
한 건 한 건의 응대 내용은 티켓이나 응대 이력에 남기고, 일일 보고에는 자신의 응대에서 궁리한 점을 씁니다. 각 칸은 1~3줄이면 충분합니다.
예문 2: 들어온 지 얼마 안 된 상담원이나 메일·채팅 담당자의 일일 보고와 망설임을 일찍 꺼내는 궁리
들어온 지 얼마 안 된 상담원이나, 파트타임으로 짧은 시간 일하는 구성원, 메일이나 채팅 창구로 막 옮긴 구성원이 있습니다.
이들의 일일 보고는 망설임이나 불안을 혼자 떠안지 않고 일찍 꺼내는 자리도 됩니다(설명을 위한 가상의 예입니다).
P는 '반품 문의에 메일로 답할 때 템플릿을 그대로 쓰지 않고, 고객의 질문에 맞춰 한 문장을 더한다'. D는 '답장을 썼지만 어디까지 덧붙여도 되는지 망설여져 한 통마다 시간이 걸렸다.
판단이 서지 않는 한 통은 옆자리 선배에게 확인을 받은 뒤 보냈다'. C는 '템플릿의 어디는 바꿔도 되고 어디는 바꾸면 안 되는지, 팀의 규칙을 아직 잘 몰랐다.
바쁜 시간대라 물어볼 때를 잡지 못했다'. A는 '내일 아침 조회가 끝난 뒤 템플릿을 바꿔도 되는 범위를 리더에게 묻는다'.
망설임을 쓰는 것은 못 하는 것을 보고하기 위해서가 아니라, 팀이 일찍 손을 보탤 수 있게 하기 위해서입니다.
읽는 쪽인 슈퍼바이저나 리더, 선배 구성원이 써 준 것을 먼저 한마디로 받아 주고, 다음에 도움이 될 실마리를 하나만 돌려주면, 구성원은 안심하고 망설임을 쓸 수 있게 됩니다.
짧은 근무일에도 쓸 수 있도록 칸은 적게 해 둡니다. 실수를 쓴 것을 탓하는 답은 피합니다.
티켓·통화 기록·CRM의 응대 기록과 일일 보고 사이에 선을 긋는다
콜센터나 고객 지원 현장에는 티켓과 문의 관리 기록, 통화 기록, CRM의 응대 이력, 에스컬레이션 기록, 인수인계 메모, 근태 기록 등 이미 정해진 기록이 있습니다.
이것들은 회사 규정과 개인정보 취급 규칙, 정해진 절차에 따라 각각의 자리에 남기는 것입니다.
어떤 기록을 어떤 항목으로 얼마 동안 남길지는 회사와 다루는 상품·서비스에 따라 다릅니다. 일일 보고는 그것을 대신하지 못합니다.
일일 보고에 '요금 문의, 처리 완료'라고만 써서는 정식 응대 기록으로 다룰 수 없다고 생각해 주세요.
선 긋기의 기본은 한 건 한 건의 응대 사실은 정해진 기록에 정해진 절차대로 남기고, 일일 보고에는 자신들의 응대에 대한 돌아보기와 알아차림, 다음 한 수를 쓴다는 나눔입니다.
일일 보고에서 그런 기록을 언급할 때는 자세한 내용을 되풀이하지 말고 '티켓에 기록함', '2차 지원 담당에게 에스컬레이션함'이라고 한마디 덧붙이면 충분합니다.
이 선을 처음에 그어 두면 같은 것을 두 번 쓰는 부담이 줄고, 일일 보고가 '기록의 중복'이 아니라 '돌아보기의 자리'로 남습니다.
어떤 기록을 어디에 남길지는 회사 규정과 슈퍼바이저나 책임자의 판단을 따라 주세요.
고객의 개인정보나 통화 내용의 세부는 쓰지 않는다. 폭언이나 괴롭힘을 당했을 때는 일일 보고에서 떠안지 말고 바로 책임자에게
일일 보고의 C 칸에는 '같은 고객에게서 여러 번 문의가 왔다', '강한 말투로 오랫동안 질책을 받는 전화가 있었다', '내가 안내한 내용이 틀렸을지도 모른다' 같은 내용이 나올 때가 있습니다.
이런 일은 일일 보고에 쓰고 끝내지 말고, 회사가 정한 절차로 잇습니다.
고객의 이름·전화번호·주소·주문 번호나 고객 번호처럼 개인을 알 수 있는 정보와, 통화나 메일로 주고받은 자세한 내용은 일일 보고에 쓰지 않고, 정해진 기록과 회사 규정에 따라 다룹니다.
일일 보고에는 '요금에 관한 문의에서 설명에 시간이 걸렸다'처럼 문의의 종류와 자신의 알아차림만 쓰면 충분합니다.
폭언이나 위압적인 언동, 오랜 시간 붙잡아 두기 등 고객에 의한 괴롭힘을 당했다고 느꼈을 때는 일일 보고를 쓸 때까지 기다리지 말고 혼자 떠안지도 말아야 합니다.
바로 슈퍼바이저나 책임자에게 알리고 회사의 절차에 따라 대응합니다.
안내가 틀렸을지도 모르거나 고객에게 불이익이 생겼을지도 모른다는 것을 알아차렸을 때도 일일 보고 안에서 끝내지 말고, 정해진 방법으로 바로 책임자에게 알립니다.
어떻게 대응할지는 회사 규정과 책임자의 판단을 따라 주세요. 원인이나 책임을 일일 보고 안에서 단정하지 않고, 특정한 사람을 탓하는 쓰기 방식도 하지 않는 것이 중요합니다.
일일 보고는 '알아차렸다'는 입구이지 대응 그 자체가 아닙니다. 일일 보고에 '슈퍼바이저에게 보고함'이라고 한마디 써 두면, 읽는 쪽은 정식 대응으로 이어졌는지 확인할 수 있습니다.
슈퍼바이저·리더가 읽는 법과 주간 돌아보기
슈퍼바이저나 리더는 구성원의 일일 보고를 매일 훑어보게 됩니다. 전부 꼼꼼히 읽으려 하면 이어지지 않습니다.
그러므로 A(다음에 어떻게 할지)부터 읽고, 이어서 C(알아차림)와 상의 칸에서 손을 보태야 할 일이나 다음 날의 근무 편성과 매뉴얼·FAQ 수정에서 정해야 할 일이 없는지 확인합니다.
돌려주는 코멘트는 사실을 한마디로 받아 주고 질문이나 다음 한 수를 하나만 덧붙이는 형태로 하면 계속하기 쉬워집니다. 예를 들어 '매뉴얼의 순서를 알아차려 줘서 도움이 됐어요.
내일 아침 조회에서 기기의 종류를 먼저 묻는 진행 방식을 팀에도 공유해요' 같은 답입니다.
교대 근무로 근무 시간대가 구성원마다 다르고 모두가 모일 기회가 적은 현장에서는, 일일 보고가 근무 교대를 넘어 알아차림을 건네는 자리도 됩니다.
또한 응답률이나 건수, 통화 시간 같은 숫자는 중요합니다. 하지만 일일 보고를 숫자로 구성원끼리 비교하거나 한 사람 한 사람의 응대를 점수로 재는 도구로 삼지 않습니다.
응대 속 알아차림을 일찍 건지기 위한 도구로 다루는 것이 솔직하게 써 달라고 하는 전제가 됩니다. 일주일에 한 번은 한 주 분량의 일일 보고를 나란히 놓고 돌아봅니다.
KPT(계속할 것·문제·시도할 것)의 형태로, 같은 종류의 문의나 같은 안내에서 망설임이 되풀이되고 있지 않은지, 시도한 안내 방식과 절차의 궁리가 어땠는지를 이야기합니다.
그러면 한 사람의 알아차림이 매뉴얼과 FAQ의 개선, 팀 전체의 응대 진행 방식 개선으로 이어집니다.
일일 보고 PDCA의 주간 요약을 쓰면 한 주 분량의 알아차림을 한꺼번에 다시 볼 수도 있습니다.
제출되지 않은 날이 있어도 먼저 탓하지 말고 이유를 묻고, 칸이나 쓰는 시각이 근무 흐름에 맞는지 다시 살펴봅니다.
AI는 초안까지. 판단은 사람이 한다
일일 보고 PDCA에서 AI는 일일 보고의 초안, 돌아보기를 돕는 질문, 주간 요약을 거드는 보조 역할입니다. 콜센터나 고객 지원 현장에서도 이 선은 달라지지 않습니다.
구성원의 짧은 메모를 다듬거나 한 주의 일일 보고에서 되풀이되는 문의의 종류나 상의할 일을 골라내는 식으로 쓸 수는 있습니다.
하지만 매뉴얼과 FAQ를 어떻게 고칠지, 근무 편성을 어떻게 바꿀지, 고객에게 어떻게 대응하고 에스컬레이션을 어떻게 할지는 슈퍼바이저나 책임자가 판단합니다.
고객의 이름과 연락처, 주문 번호, 통화의 자세한 내용 같은 개인을 알 수 있는 정보는 일일 보고에 쓰지 않는 운영을 해 두면 안심입니다.
일일 보고 PDCA는 일일 보고 데이터를 이용하시는 기업, 곧 독자 여러분의 회사 자신의 Google 드라이브(스프레드시트)에 기록하는 설계입니다.
당사 쪽에 정보를 쌓아 두지 않는 최소 데이터 보유의 사고방식을 따르고 있습니다. 정해진 기록과 역할을 나누고, 짧은 형식으로, 답이 돌아오는 일일 보고를 계속한다.
그 축적이 매일의 응대 속 작은 알아차림을 다음 날의 한 수와 팀의 일하는 방식 개선으로 바꾸는 토대가 된다고 생각합니다.
같은 회사가 만든 업무와 생활 도구 모음입니다. Norolu Works(새 탭에서 열림) OKR 작성법(새 탭에서 열림)