고객 문의는 이메일로 받고, 내부에서는 메신저로 개발팀에 묻고, 최종 현황은 엑셀에 적는 방식은 처음에는 익숙합니다. 그러나 요청이 늘면 “이 건은 누가 답해야 하나요”, “고객이 추가 자료를 보냈나요”, “수정은 언제 반영되나요”를 확인하는 데 시간이 더 듭니다.
이때 고객 요청 관리 시스템을 검토하는 팀은 흔히 이메일과 고객 포털 중 하나를 골라야 한다고 생각합니다. 판단 기준은 채널을 없애는 일이 아닙니다. 고객이 요청의 진행 상태와 자신의 다음 행동을 반복해서 물어보는지, 그 정보를 내부 담당자만 알아도 되는지부터 봐야 합니다.
이메일을 유지해도 되는 운영 방식
고객이 이메일을 선호하고, 요청 건수도 많지 않으며, 대부분의 답변이 한두 번의 왕복으로 끝난다면 이메일 접수를 유지할 수 있습니다. 대신 이메일 한 통을 업무의 시작점으로만 두고, 담당자·고객사·요청 유형·현재 상태·답변 이력을 한곳에 기록해야 합니다. 엑셀은 현황을 내보내거나 임시로 정리하는 용도일 수 있지만, 누가 처리 중인지 판단하는 기준 기록이 되면 안 됩니다.
이 방식이 맞는 팀은 고객이 진행 상황을 수시로 확인할 필요가 적고, 내부 담당자가 바뀌어도 요청 기록을 쉽게 이어받을 수 있는 팀입니다. 예를 들어 기능 문의를 받은 뒤 답변 여부와 후속 약속만 관리하면 되는 경우라면, 고객용 화면을 새로 만들기보다 이메일 접수 내용을 공통 요청 기록으로 모으는 편이 더 빠를 수 있습니다.
다만 메일함, 메신저, 엑셀에 같은 요청의 최신 내용이 따로 남기 시작하면 신호가 달라집니다. 담당자는 “처리 중”이라고 알고 있는데 고객은 답변을 기다리고 있거나, 고객이 보낸 파일이 개발팀에 전달되지 않는 일이 반복된다면 채널보다 기록 구조를 먼저 바꿔야 합니다.
고객 포털이 필요한 순간은 상태 공유가 업무가 될 때다
고객 포털은 문의를 줄이기 위한 게시판이 아니라, 고객과 내부 팀이 같은 요청의 일부 정보를 함께 보는 화면입니다. 고객이 “지금 검토 중인가요”, “무엇을 더 제출해야 하나요”, “수정본은 어디에서 받나요”를 자주 확인한다면 포털의 우선순위가 높아집니다. 특히 한 고객사 안에서 요청자, 승인자, 실무자가 나뉘어 같은 건을 봐야 할 때 효과가 큽니다.
가령 고객사가 계산 결과 오류를 이메일로 알렸다고 가정해 보겠습니다. 내부에서는 재현 여부를 확인하고, 개발팀은 수정 범위를 검토하며, 운영 담당자는 고객에게 자료를 더 요청할 수 있습니다. 이 모든 내부 작업을 고객에게 보여줄 필요는 없습니다. 고객 화면에는 접수됨, 추가 자료 필요, 검토 중, 수정 예정, 완료처럼 이해 가능한 단계와 현재 필요한 행동만 보여주면 됩니다.
포털을 만들기 전에 다음 다섯 가지를 먼저 합의해 두면 화면을 과하게 키우지 않을 수 있습니다.
- 고객에게 보여줄 상태 이름과 각 상태의 뜻
- 내부 메모와 고객 공개 답변을 나누는 기준
- 고객사 안에서 요청자 본인만 볼지, 동료와 공유할지의 범위
- 고객이 올린 파일과 내부 검토 자료를 구분하는 방법
- 상태를 갱신하고 고객 답변을 남길 내부 담당자
상태 정의 없이 로그인 화면부터 만들면 포털은 또 다른 문의 채널이 될 수 있습니다. 고객은 화면의 “검토 중”이 무엇을 뜻하는지 다시 이메일로 묻게 되고, 담당자는 포털과 메일에 같은 답을 반복하게 됩니다.
처음에는 공통 기록을 만들고, 반복 흐름만 연다
포털 도입은 한 번에 모든 고객 요청을 옮기는 프로젝트일 필요가 없습니다. 먼저 이메일로 들어온 요청과 내부 등록 요청을 같은 이력으로 묶고, 담당자와 상태를 한곳에서 관리하는 단계부터 시작할 수 있습니다. 그다음 고객이 자주 확인하는 진행 현황과 자료 제출 같은 흐름만 고객 화면에 열면 됩니다.
이 순서는 고객별 권한 구조가 복잡한 B2B 서비스에서 특히 중요합니다. 같은 고객사 소속이라고 해서 모든 요청과 첨부파일을 서로 볼 수 있는 것은 아닙니다. 고객사 관리자, 일반 사용자, 외부 협력사가 어떤 요청까지 열람할 수 있는지 정한 뒤, 로그인한 사용자가 해당 요청을 볼 수 있는지 요청마다 확인해야 합니다. 고객사 식별값이나 주소에 포함된 값만으로 열람 범위를 판단해서는 안 됩니다.
삼태연구소가 공개한 대출 상담 통합 CRM 사례도 수기와 엑셀에 흩어진 상담 업무를 웹 기반 기록으로 모은 사례입니다. 고객 포털까지 포함한 사례로 확대할 수는 없지만, 외부 공개 화면을 논의하기 전에 내부 기록의 기준을 하나로 모아야 한다는 출발점에는 참고가 됩니다. 지금 필요한 선택이 포털 개발인지 판단하려면, 고객이 반복해서 확인하는 정보 한 가지와 내부에서 책임지고 갱신할 상태 한 가지부터 골라보는 편이 좋습니다.
