피드백 루프

의견을 모으는 일은 어느 회사나 했습니다. 설문을 돌리고, 상담 기록을 옮겨 적고, 미팅에서 들은 말을 문서에 붙여 넣었습니다. 그런데 그 문서가 반년 뒤에도 열리지 않은 채 남아 있는 경우가 대부분이었습니다. 모으는 사람과 만드는 사람이 달랐고, 모은 것을 누가 언제 읽는지는 아무도 정해 두지 않았기 때문입니다. 문장 사백 개가 한 문서에 쌓이면 여는 일 자체가 반나절짜리 일이 되어, 급한 일이 하나만 있어도 다음 주로 밀립니다.

고객 쪽에서 보면 더 단순한 장면이었습니다. 불편한 점을 적어 보냈는데 답이 오지 않고, 석 달 뒤에 똑같이 불편한 채로 남아 있습니다. 두 번째에는 조금 더 짧게 적고, 세 번째에는 적지 않습니다. 그러면 회사 쪽에는 의견이 줄어든 것처럼 보이는데, 실제로 줄어든 것은 불만이 아니라 말해 주는 사람입니다.

그래서 한 바퀴라는 말이 붙었습니다. 들어오는 쪽만 만들어 두는 것으로는 부족하고, 들어온 말이 제품에 닿고 그 결과가 말한 사람에게 되돌아가 다음 말을 부르는 데까지 이어져야 한다는 뜻입니다. 고쳤다는 사실보다 고쳤다고 알려 준 사실이 다음 바퀴를 돌립니다.

한 바퀴는 다섯 칸입니다. 분기에 한 번 도는 팀이 많고, 문의가 많은 제품이라면 달마다 돕니다.

1. 받기 — 피드백 채널로 들어온 말을 한 표에 모읍니다. 무엇을 만들어 달라는 형태로 온 것은 기능 요청 한 건으로 적고, 불만이나 칭찬은 그대로 둡니다. 옮길 때 요약하지 않고 고객이 쓴 문장을 그대로 붙입니다.
2. 묶기 — 제품의 어느 영역인지 꼬리표를 달고 같은 문제끼리 모읍니다. 적힌 글자가 달라도 막힌 자리가 같으면 한 묶음입니다. 엑셀 내보내기 일곱 건과 자동 보고서 다섯 건은 월말 보고서라는 한 덩이입니다.
3. 정하기 — 묶은 표를 우선순위 결정 자리에 입력으로 넣습니다. 이 표가 결정을 대신하지는 않습니다. 서른 건이 쌓인 요청도 이번 분기에 하기로 한 일과 맞지 않으면 미룹니다. 대신 미뤘다는 사실과 그 까닭을 항목에 적어 둡니다.
4. 돌려주기 — 말한 사람에게 결과를 알립니다. 만든 것뿐 아니라 만들지 않기로 한 것도 알립니다. 회신은 길 필요가 없어서, 말씀하신 검색 문제는 이번 달에 고쳤고 함께 요청하신 폴더 일괄 이동은 이번 분기에 하지 않기로 했으며 그 까닭은 무엇이라는 세 줄이면 됩니다.
5. 확인하기 — 알린 것으로 끝내지 않고 그 사람이 실제로 문제가 풀렸는지 되묻습니다. 고친 기능을 쓰고 있는지, 여전히 손으로 하고 있는지가 여기서 드러납니다. 이 칸까지 와야 한 바퀴가 닫히고, 닫힌 자리에서 다음 바퀴의 1번이 시작됩니다.

앞의 셋은 회사 안에서 끝나고 뒤의 둘은 고객에게 닿습니다. 뒤의 둘을 빼면 루프라는 이름이 남을 이유가 없습니다. 실제로 빠지는 칸도 거의 언제나 4번이고, 5번까지 도는 팀은 드뭅니다.

고객이 누구인지 알 수 있는 제품에서 잘 돕니다. 로그인해서 쓰는 업무용 제품이라면 요청한 사람의 주소와 회사를 알고 있어서 4번이 어렵지 않습니다. 문의량이 한 사람이 읽을 수 있는 규모일 때도 잘 맞습니다. 주 스무 건이면 한 사람이 목요일 오후에 훑고 넘길 수 있습니다. 반대로 하루 삼백 건이 들어오는 제품에서는 읽는 일이 한 사람의 전담 업무가 되고, 그 사람이 휴가를 가면 바퀴가 멈춥니다.

한계는 세 가지입니다. 첫째, 익명 사용자가 대부분인 대량 서비스에서는 개별 회신이 불가능합니다. 이때는 개별 회신 대신 업데이트 소식과 공개된 계획표로 대신하는데, 한 사람에게 닿는 정도가 약해 바퀴가 느슨하게 돕니다. 둘째, 한 바퀴가 도는 데 걸리는 시간이 제품의 개발 주기보다 길면 회신이 의미를 잃습니다. 요청한 지 열 달 만에 도착한 연락에 고객은 대개 자기가 무슨 말을 했는지 기억하지 못합니다. 셋째, 이 바퀴에 올라타는 사람은 전체 고객 가운데 말해 주기로 마음먹은 일부입니다. 말없이 떠난 쪽의 사정은 이탈 사유 기록이나 순추천지수 같은 다른 자리에서 따로 봐야 합니다.

바퀴를 돌리기 시작하면 요구가 늘어난 것처럼 보이는 시기가 옵니다. 답이 온다는 것을 안 고객이 그동안 접어 두었던 말을 꺼내기 때문입니다. 늘어난 것은 불만이 아니라 보이는 불만입니다.

"이 건은 아직 루프가 안 닫혔어요. 배포는 했는데 요청한 고객한테 연락을 안 했습니다."

고친 것과 고쳤다고 알린 것을 구분하는 말입니다.

"안 하기로 한 것도 알려 드리세요. 그 회신이 다음 의견을 만듭니다."

거절 통보가 오히려 채널을 살린다는 뜻입니다.

"지난 분기에 들어온 요청 중에 회신이 나간 비율이 얼마예요?"

루프가 실제로 닫히고 있는지를 숫자로 확인하자는 요구입니다.

페이지덱에서는 수아가 분기 초에 지난 분기 요청 목록을 열어 회신이 나가지 않은 항목부터 채웁니다. 지현이 각 항목에 만들었는지 미뤘는지와 그 까닭을 한 줄씩 붙여 주고, 수아는 그 줄을 고객별로 묶어 보냅니다. 미팅이 잡힌 고객에게는 자리에서 말로 전합니다.

닫히지 않은 항목이 쌓이면 다음 분기에 들어오는 의견이 눈에 띄게 줄어듭니다. 수아가 회신 비율을 분기마다 재는 이유가 이것입니다.

배포하면 루프가 닫힌다고 여기는 경우가 가장 많습니다. 만드는 쪽에서 보면 요청이 처리됐으니 끝난 일처럼 보입니다. 하지만 요청한 고객은 업데이트 목록을 읽지 않고, 자기가 말한 기능이 생겼다는 사실을 모른 채 예전 방식으로 계속 일합니다. 그러면 만든 쪽은 요청대로 만들었다고 생각하고 고객은 아무것도 바뀌지 않았다고 생각하는 상태가 몇 달씩 이어집니다. 심한 경우 같은 고객이 반년 뒤에 같은 요청을 다시 보내고, 받는 쪽은 이미 있는 기능이라고 답하게 됩니다.

루프를 설문 돌리기와 같은 말로 읽는 것도 흔합니다. 둘 다 고객에게 묻는 일처럼 보이기 때문입니다. 그런데 설문은 1번 칸 하나를 채우는 도구여서, 백 명에게 물어 답을 받아도 그 답이 어디로 가서 무엇이 되었는지 돌려주지 않으면 바퀴는 한 칸도 돌지 않습니다. 설문을 반복해서 돌리는 회사일수록 응답률이 떨어지는 이유도 여기에 있습니다.