고객에게 진행 상황을 어디까지 열어야 할까

유지관리 요청이 접수되고 완료되기까지, 고객이 볼 수 있는 정보의 범위를 정하는 일. 다 보여주는 것과 잘 보여주는 것은 다릅니다.

고객사에서 가장 자주 듣는 말은 기능 요청이 아니라 질문입니다. "지난주에 요청한 건 어떻게 됐나요." 이 질문에 답하기 위해 담당자가 내부에 확인하고 다시 회신하는 왕복이 계속 발생합니다.

그래서 고객이 직접 볼 수 있게 하기로 했습니다. 문제는 어디까지 보여줄 것인가였습니다.

상태를 몇 단계로 나눌 것인가

내부에서 실제로 일이 진행되는 단계는 접수, 검토, 견적, 승인, 작업, 완료로 나뉩니다. 여기에 어느 단계에서든 발생할 수 있는 반려가 있습니다.

처음에는 이걸 줄이려고 했습니다. 고객에게는 "진행 중 / 완료" 정도만 보여주면 충분하지 않을까 싶었습니다. 결론은 반대였습니다. 단계를 줄이면 "진행 중"에 머무는 기간이 길어지고, 그 기간에 다시 같은 질문이 옵니다.

고객이 알고 싶은 것은 “진행 중인가”가 아니라 “지금 누구 차례인가”였습니다.

견적을 기다리는 것과 승인을 기다리는 것은 다릅니다. 후자는 고객이 움직여야 하는 단계입니다. 단계를 그대로 보여주니 "내가 지금 할 일이 있는가"가 스스로 드러났습니다.

보여주지 않기로 한 것

반대로 열지 않은 것도 있습니다.

• 내부 작업 분해 — 요청 하나가 내부에서 몇 개의 작업으로 쪼개지는지는 고객의 관심사가 아니고, 개수가 진척으로 오해됩니다.
• 담당자 개인별 진행 상황 — 조직 내부 사정이 외부 평가 대상이 되면 기록이 왜곡됩니다.
• 견적 산출 근거의 세부 — 항목과 금액은 열고, 내부 원가 구조는 열지 않습니다.

기준은 하나였습니다. "이 정보를 보고 고객이 다음 행동을 정할 수 있는가." 아니라면 그건 투명성이 아니라 소음입니다.

요청과 작업을 이어 두었다

고객이 올린 요청과 내부 작업을 서로 연결해 두었습니다. 승인된 요청에서 작업을 만들면 그 작업 카드에 원래 요청 번호가 따라붙습니다. 사소해 보이지만, 이게 없으면 몇 달 뒤 "이 작업은 왜 했는가"에 답할 수 없습니다.

유지관리는 한 번 납품하고 끝나는 일이 아니라 몇 년에 걸쳐 이어지는 일이라서, 판단의 근거가 남는지가 기능의 개수보다 중요합니다.

남은 개선

아직 부족한 부분은 알림입니다. 상태가 바뀌었을 때 고객이 포털에 들어와야 알 수 있다면, 결국 다시 전화가 옵니다. 실시간 알림 구조는 만들어 두었으니 어떤 변화를 알리고 어떤 변화는 알리지 않을지를 정하는 단계입니다. 전부 알리면 아무것도 알리지 않는 것과 같아집니다.