이 글의 순서
핵심 내용
“고객과 전문가가 이야기해야 하니까 채팅도 넣어주세요.” 상담·중개 앱을 준비할 때 자연스럽게 나오는 요구입니다. 그런데 채팅 화면을 만드는 것만으로는 어떤 정보를 받고, 누가 답하며, 무엇을 최종 약속으로 남길지가 정해지지 않습니다.
먼저 대화의 역할을 나눠보는 것이 좋습니다. 처음부터 필요한 정보는 요청서로 받고, 처리 단계는 상태로 안내합니다. 그 뒤에도 설명과 조율이 필요한 부분을 대화로 풀어갑니다. 상담 자체가 서비스의 핵심이라면 채팅이 첫 버전의 중심 기능이 될 수 있습니다. 반대로 접수 확인과 일정 안내가 대부분이라면 다른 방식으로 시작할 여지가 있습니다.
아래에서는 가상의 출장 수리 서비스를 예로 들겠습니다. 실제 고객 사례나 개발 성과가 아니라, 기능 범위를 판단하기 위한 예시입니다.
먼저 대화에서 결정해야 할 내용을 찾습니다
고객이 “기계가 작동하지 않아요”라고 문의했다고 가정해 보겠습니다. 담당자는 어떤 기계인지, 어떤 증상인지, 현장에 언제 방문할 수 있는지를 알아야 합니다.
기종·증상·사진·희망 일정은 요청서에서 미리 받을 수 있습니다. 요청서를 본 전문가가 “전원을 켜면 소리도 나지 않나요?”라고 확인하는 일은 상황에 따라 달라지는 추가 질문입니다. 이후 “방문 일정이 확정됐습니다”라는 안내는 협의가 아니라 이미 정해진 결과의 전달입니다.
세 가지를 모두 채팅에 맡길 수도 있습니다. 다만 그러면 담당자가 매번 같은 질문을 하거나, 긴 대화에서 약속한 내용을 다시 찾아야 할 수 있습니다. 채팅 여부를 결정하기 전에 자주 오갈 말을 적고, 정해진 정보를 받는 일인지, 추가 설명을 나누는 일인지, 결과를 알려주는 일인지 구분해 보세요.
이때 모든 예외를 입력 항목으로 만들 필요는 없습니다. 고객이 알기 어려운 기계 상태까지 필수 선택지로 요구하면 오히려 접수가 어려워집니다. 필수 질문은 줄이고, 설명이 필요한 부분을 대화로 남기는 식으로 균형을 잡습니다.
요청서와 상태 안내와 채팅의 역할을 나눕니다
네 가지 방식은 서로 대체하기도 하지만 함께 사용할 수도 있습니다.
요청서는 처음부터 필요한 정보가 정해져 있을 때 적합합니다. 출장 수리라면 증상과 사진, 희망 일정을 받습니다. 다만 희망 일정을 입력한 것과 방문이 확정된 것은 구분해서 보여줘야 합니다.
상태 안내는 “접수가 됐나요?”, “담당자가 정해졌나요?”처럼 현재 진행 상황을 확인하는 데 사용합니다. 접수·확인 중·일정 협의·방문 확정 등의 상태와 다음 행동을 보여줍니다. 상태가 바뀌었다는 이유만으로 고객에게 언제나 문자를 보내는 것은 아니며, 어떤 변화에 어떤 안내가 필요한지도 정합니다.
요청별 질문과 답변은 특정 수리 요청에 부족한 정보를 보충하는 메시지 기능입니다. 사진과 질문을 한 번에 정리하고 담당자가 확인한 뒤 답해도 되는 업무부터 검토할 수 있습니다.
자유 채팅은 요청 한 건을 넘어서 지속적으로 상담할 때 검토합니다. 대화의 범위와 응답 속도는 별개입니다. 요청 안에서도 짧은 대화를 빠르게 주고받아야 할 수 있고, 지속 상담이어도 나중에 답할 수 있습니다. 질문을 묶어서 답해도 되는지, 답에 따라 곧바로 다음 질문이 이어져야 하는지를 보고 대화 방식을 정하세요. 채팅창이 있다는 이유만으로 즉시 답변을 약속하지는 않습니다.
이 수리 서비스의 첫 버전이라면 ‘요청서 → 요청별 추가 질문 → 확정 내용 안내’부터 검토할 수 있습니다. 대화 자체의 가치가 큰 전문 상담 서비스까지 같은 구성으로 제한하자는 뜻은 아닙니다.
채팅을 넣는다면 참여자와 시작과 끝을 정합니다
채팅이 필요하다고 결정했다면, 메시지를 주고받는 화면보다 먼저 대화의 경계를 정해야 합니다. 누구나 전문가에게 말을 걸 수 있는지, 요청을 맡은 전문가와만 대화하는지에 따라 사용 흐름이 달라집니다.
가상 수리 서비스에서는 담당 전문가가 정해진 뒤 고객과 전문가가 요청 안에서 대화하도록 설계할 수 있습니다. 담당자가 바뀌면 이전 담당자가 계속 대화를 볼 수 있는지, 새 담당자에게 어떤 기록을 넘길지도 정합니다. 역할 자체를 먼저 나눠야 한다면 매칭 앱의 고객·전문가·관리자 역할 설계를 함께 참고할 수 있습니다.
작업 완료 후에도 같은 방에서 새 수리를 요청할 수 있게 할까요? 계속 열어두면 편리할 수 있지만, 새 요청과 이전 작업의 후속 질문이 섞일 수 있습니다. ‘이전 대화는 확인할 수 있고 새 수리는 새 요청으로 접수한다’는 방식도 선택지입니다. 완료 후 문의를 받을 통로는 별도로 안내합니다.
사진 첨부도 같은 기준으로 봅니다. 증상 확인에 사진만 필요한데 처음부터 모든 파일 형식과 음성 메시지를 지원할 필요는 없습니다. 무엇을 보내야 하는지, 전송되지 않은 사진을 어떻게 알려줄지까지가 요구사항입니다. 연결·저장·재접속의 기술적 차이는 실시간 통신과 WebSocket에서 따로 설명합니다.
대화 내용과 확정된 조건을 구분합니다
고객이 “금요일 오후가 좋습니다”라고 보냈고 전문가가 “확인했습니다”라고 답했다고 해보겠습니다. 고객은 방문이 확정됐다고 생각할 수 있지만, 전문가는 희망 시간을 확인했다는 뜻으로 답했을 수도 있습니다.
이런 상황을 줄이려면 대화에서 협의한 내용을 별도의 확정 영역으로 옮기는 방법을 검토해 보세요. 예를 들어 다음처럼 표시할 수 있습니다.
확인해보세요
- 방문 일정: 10월 16일 오후 2시
- 작업 범위: 고장 원인 점검
- 비용 조건: 방문 점검비와 추가 수리비를 구분해 안내
- 진행 상태: 고객 확인 대기
이 예시에서는 전문가가 조건을 제안하고 고객이 확인하면 ‘방문 확정’으로 바꿉니다. 현장을 보기 전에는 수리비를 확정할 수 없다면, 금액을 임의로 채우지 않고 현장 확인 후 별도 동의를 받는다고 표시합니다.
확정 후 일정이나 범위가 달라질 때도 기존 내용을 조용히 덮어쓰기보다 변경안을 보여주고 다시 확인하도록 정할 수 있습니다. 메시지의 ‘읽음’ 표시는 내용을 확인했다는 단서이지, 방문 조건이나 추가 비용에 동의했다는 기록을 대신하지 않습니다.
별도 확정 영역이 꼭 복잡한 계약 기능이어야 하는 것은 아닙니다. 고객과 담당자가 같은 최신 조건을 확인할 수 있고, 누가 언제 변경·확인했는지 남기는 것이 이 예시의 목적입니다.
답이 없거나 담당자가 바뀌는 상황을 준비합니다
평소의 대화뿐 아니라 응답이 끊겼을 때의 처리도 필요합니다. 고객이 사진을 보냈는데 전문가가 확인하지 않으면 누구에게 일이 남을까요? 고객이 일정 제안에 답하지 않은 상태에서 방문이 확정되면 안 됩니다.
예를 들어 고객의 확인이 없으면 ‘확인 대기’를 유지하고, 운영자가 미응답 요청을 살펴보도록 정할 수 있습니다. 응답을 기다릴 시간, 재안내 여부, 종료 기준은 실제 운영 여력에 맞춰 선택합니다. 운영할 수 없는 상시 응답을 화면에서 약속하지 않는 것이 중요합니다.
잘못 보낸 메시지의 수정·삭제, 담당자 교체, 신고 역시 미리 판단할 항목입니다. 운영자가 문제 해결을 위해 대화를 볼 필요가 있더라도 모든 직원에게 모든 대화를 항상 열어둘 필요는 없습니다. 어떤 사유로 누가 어느 범위를 확인하는지, 고객에게 어떻게 안내할지를 함께 정합니다. 보관 기간과 열람·삭제 정책은 서비스의 상황에 맞춰 별도로 검토해야 합니다.
첫 버전의 범위를 한 장으로 정리합니다
개발 요청서에 ‘채팅 기능’ 한 줄만 넣기보다, 아래 항목을 짧게 채워보세요. 괄호 안은 앞에서 사용한 가상 수리 서비스의 선택 예시입니다.
확인해보세요
- 대화 목적: 요청서만으로 확인하기 어려운 것은 무엇인가? (증상 보충과 방문 조건 협의)
- 참여자: 누가 누구와 대화하는가? (고객과 배정된 전문가, 운영자는 정해진 사유와 권한 범위에서 확인)
- 시작과 종료: 언제 대화를 열고 완료 후 문의는 어디로 받는가? (배정 후 시작, 새 수리는 새 요청, 완료 건의 후속 문의 통로 안내)
- 첨부: 어떤 자료가 필요하고 실패하면 어떻게 안내하는가? (증상 사진, 전송 실패 표시와 다시 보내기)
- 확정 기록: 무엇을 누가 제안하고 확인하는가? (일정·점검 범위·비용 조건을 전문가가 제안하고 고객이 확인)
- 응답 공백: 답이 없으면 누가 무엇을 하는가? (대기 상태 유지, 운영자의 미응답 목록 확인)
- 보류 기능: 첫 버전에서 다루지 않을 것은 무엇인가? (단체 대화·음성 메시지·요청과 무관한 자유 대화)
이렇게 정리하면 개발할 화면뿐 아니라 테스트할 상황도 분명해집니다. 담당자가 바뀌어도 필요한 기록이 이어지는지, 미확인 일정을 확정으로 보여주지 않는지, 사진 전송 실패를 알 수 있는지 확인할 수 있습니다.
채팅을 넣는 것이 목표는 아닙니다. 고객과 담당자가 필요한 정보를 주고받고, 같은 약속을 확인하며, 다음 행동을 알 수 있어야 합니다. 준비 중인 서비스에서 가장 흔한 요청 한 건을 골라 이 흐름부터 적어보세요. 개발 상담에서도 그 흐름을 바탕으로 대화 기능의 필요와 첫 버전의 범위를 함께 검토할 수 있습니다.
