퍼널을 개선하려 할 때 대부분 앞쪽을 봅니다. 유입을 늘리고, 랜딩을 고치고, 폼을 짧게 만듭니다. 그런데 이미 문의를 보낸 사람에게 얼마나 빨리 답하는지는 그보다 손대기 쉬운 곳이면서, 자주 방치되는 곳이기도 합니다.
고객 입장에서 문의는 여러 곳에 동시에 보내는 행동인 경우가 많습니다. 그리고 대화가 시작된 곳에서 결정이 나기 쉽습니다. 답이 늦으면 우리는 검토 대상에서 조용히 빠집니다 — 거절당하는 것이 아니라 고려되지 않는 것이라 데이터에도 남지 않습니다.
먼저 지금 상태를 잽니다
개선의 출발은 현재를 아는 것입니다. 지난 몇 달의 문의를 놓고, 도착 시각과 첫 답장 시각을 적어 봅니다. 평균 하나만 보지 말고 가장 오래 걸린 건도 함께 봅니다 — 평균은 멀쩡한데 특정 요일이나 담당자 부재 기간에만 며칠씩 걸리는 경우가 흔합니다.
여기서 나오는 숫자는 우리 것이고 추정이 아닙니다. 이 숫자를 기준선으로 두면, 이후의 변화가 실제 개선인지 착각인지 구분할 수 있습니다.
흐름을 문서로 만듭니다
“문의 오면 빨리 답한다” 는 흐름이 아니라 의도입니다. 의도는 바쁜 날에 가장 먼저 무너집니다. 흐름은 누가 · 언제까지 · 무엇을 · 다음은 무엇을 이 정해진 상태를 말합니다.
담당 지정이 빠지면 모두의 일이 아무의 일도 되지 않습니다. 혼자 운영하는 사업이라면 담당은 자동으로 정해지지만, 그때도 확인하는 시각을 정해 두는 것이 좋습니다 — 하루 두 번 정해진 시각에 보는 편이 종일 알림에 반응하는 것보다 응답 시간을 안정시킵니다.
종결도 단계입니다. 답이 없는 문의를 언제까지 붙들고 있을지 정해 두지 않으면 목록이 계속 부풀고, 진짜 진행 중인 건이 그 안에 묻힙니다. 몇 번 시도한 뒤 종결하고, 종결 사유를 한 줄 남깁니다 — 그 사유가 다음 분기의 개선 재료가 됩니다.
자동화는 사람을 대신하지 않고 기한을 지킵니다
자동화를 도입할 때 목표를 잘못 잡으면 관계가 상합니다. 자동화가 잘하는 일은 답장 자체가 아니라 기한을 지키는 일입니다 — 접수 즉시 자동 회신을 보내고, 일정 시간이 지나도 첫 응답이 없으면 담당자에게 알리고, 상태가 바뀌지 않은 건을 목록 위로 올려 줍니다.
실제 답장의 내용은 사람이 씁니다. 특히 첫 응답에서 고객이 쓴 표현을 그대로 되받아 쓰면, 자동 발송이 아니라는 사실이 즉시 전달됩니다. 자동 회신의 문장을 앞선 회차에서 따로 다룬 것도 같은 이유입니다.
운영을 절차로 만드는 방법은 개발 워크플로우 아카이브에서 더 다루고, 접수부터 완료까지의 단계를 실제로 어떻게 나누는지는 작업 과정에 우리 사례로 공개돼 있습니다.
다음 회차
흐름이 갖춰지면 마지막 질문이 남습니다 — 이 문의는 어디서 왔는가. 마지막 회차는 리드와 콘텐츠를 잇는 방법이고, 그 연결이 있어야 다음에 무엇을 쓸지 근거로 정할 수 있습니다.