전화 기록 확인이 늘 늦어진다면 기록을 처음 본 때와 실제로 행동을 시작한 때를 나눠보세요. 앱이나 장부를 더 자주 열어보라는 지시만으로는 해결되지 않을 수 있습니다. 이미 읽었지만 무엇을 해야 할지 몰라 멈춘 경우도 있기 때문입니다.
읽기 지연과 처리 지연은 다른 문제입니다
가상의 예로 사장님은 직원이 한참 뒤에 회신했으니 기록도 늦게 봤다고 생각합니다. 실제로 직원은 바로 읽었지만 필요한 현장 정보를 찾지 못해 기다렸습니다. 이때 기록 확인 횟수를 늘려도 회신이 빨라지지 않을 수 있습니다. 어느 단계가 늦었는지 확인해야 합니다.
반대로 기록을 볼 담당과 시점이 정해져 있지 않아 아무도 확인하지 않은 경우도 있습니다. 이미 읽은 건의 판단 문제와 처음부터 발견하지 못한 건을 같은 원인으로 묶지 않는 것이 중요합니다.
발생·확인·착수의 간격을 적습니다
- 요청 발생: 가게가 해당 용건을 받은 시점
- 처음 확인: 담당이 내용을 실제로 읽거나 전달받은 시점
- 의미 확인: 다음 행동과 필요한 조건을 이해한 때
- 착수: 질문을 전달하거나 회신 준비를 실제로 시작한 때
- 멈춘 이유: 자료, 권한, 인력, 시한 판단 중 어떤 문제가 있었는지
정확한 시각을 확인할 수 없다면 아는 범위만 적습니다. 추측한 분 단위 수치를 만들어 비교할 필요는 없습니다. 예시로 ‘기록은 점심 전 확인, 담당 결정이 없어 오후까지 대기’라고만 남겨도 읽기 문제인지 알 수 있습니다.
가장 긴 간격의 이유를 직접 확인합니다
발생에서 처음 확인까지 길었다면 담당과 확인 경로를 살펴봅니다. 확인에서 착수까지 길었다면 읽을 정보가 부족했는지, 누가 결정하는지 몰랐는지 봅니다. 착수는 했지만 답을 못 낸 경우에는 외부 응답이나 현장 조건이 남았을 수 있습니다.
손님과 합의한 시한이 아직 남아 있어 우선순위를 조정한 경우라면 단순 지연과 구분해야 합니다. 빠르게 시작하는 것이 항상 올바른 순서는 아닙니다. 어떤 약속을 기준으로 기다렸는지 설명할 수 있어야 합니다.
바꾼 단계만 다시 점검합니다
처음 확인 담당을 정했다면 다음 비슷한 용건에서 그 사람이 실제로 읽었는지 봅니다. 권한 기준을 바꿨다면 읽은 뒤 누구에게 물어볼지 몰라 멈추는 일이 줄었는지 확인합니다. 전체 회신 시간만 비교하면 문의 성격 차이 때문에 결과를 잘못 해석할 수 있습니다.
시간표를 직원 감시용으로 과하게 만들 필요는 없습니다. 반복해서 늦는 한 유형을 골라 원인을 확인하고, 필요한 업무 흐름을 정하는 정도로 시작할 수 있습니다.
콜든타임은 통화 내용을 앱에 남깁니다. 이 글의 확인·착수 시점과 대기 이유는 매장에서 관찰해 작성하는 항목이며, 앱이 직원의 모든 업무 행동을 자동 측정한다는 의미는 아닙니다.