[PonsLink] DM 상담 요청을 바로 예약으로 보내지 않기로 한 이유

처음에는 DM이 들어오면 곧바로 캘린더 예약으로 보내는 게 정답처럼 보였다. 전환이 빠르고, 빈 슬롯이 차면 일이 굴러가는 느낌이 났다. 지표도 예뻤다.

문제는 예약 다음에 드러났다. 시간은 잡혔는데 용건이 없다. 상대가 무엇을 상담하려는지 모른 채 방에 들어가면, 첫 10분은 다시 “무슨 일로 오셨죠?”를 묻는 데 쓴다. 예약은 성공인데 상담은 처음부터다. 사용자는 그 장면을 제품 완성도로 읽는다.

DM이 채널이 아니라 누수였던 이유

상담 요청은 한 곳으로 오지 않았다. 인스타 DM, 메일, 오픈채팅, 지인 소개가 섞였다. 각 채널에 맥락 조각이 흩어지고, 캘린더에는 시간만 남았다. 회의 직전에야 메시지를 다시 스크롤하며 용건을 복원하는 일이 반복됐다.

바로 예약 링크를 붙여 두면 그 누수가 구조가 된다. 맥락을 모을 단계가 제품 밖에 있으니, 운영자 머릿속이 임시 데이터베이스가 된다. 사람이 아프거나 메시지가 묻히면 맥락은 영영 사라진다.

지표는 올랐는데 상담 품질이 떨어진 장면

직결 구조의 반례는 로그보다 방 안에서 먼저 보였다. 예약은 찼다. 그런데 준비가 안 된 상담이 늘었다. 자료가 없고, 질문이 없고, 기대 범위가 다르다. 호스트는 매번 즉석 인터뷰를 하고, 게스트는 “이미 말했는데요”를 반복한다.

전환율만 보면 성공이다. 상담 한 건의 준비 비용과 신뢰 비용까지 보면 실패에 가깝다. 빠른 경로가 나중 단계의 비싼 질문을 다시 만들고 있었다.

예약 앞에 요청 수집을 둔 이유

다시 그은 경계는 단순하다. DM은 곧장 예약이 아니라 요청 수집으로 보낸다. 용건, 현재 상태, 원하는 도움을 짧은 폼으로 받는다. 그다음에야 시간을 연다.

단계	책임	결과
유입	채널을 한 입구로 모은다	맥락 분산 감소
요청 수집	용건과 상태를 남긴다	예약 전 공통 기록
예약	시간을 확정한다	맥락이 붙은 입장
상담	본 대화를 한다	기록이 다음 요청으로 이어짐

예약의 정의를 바꿨다. 예전에는 시간 확정이었다. 지금은 맥락이 붙은 입장이다. 시간이 맞아도 요청이 비어 있으면 아직 예약이 아니다.

요청 수집은 거절 장치가 아니다. 선별 장치다. 필요한 질문만 짧게 받는다. 질문이 길어지면 유입이 죽으니, “없어도 진행은 된다”와 “있으면 상담이 산다”의 최소 세트만 남겼다.

DM 경계 나누기

기본 경로는 DM → 요청 → 예약 → 방이다. 맥락 없는 예약은 예외로만 남긴다. 급하면 예외를 열 수 있어야 하지만, 예외가 기본이 되면 다시 누수로 돌아간다.

상담이 끝나면 기록을 다음 요청에 연결한다. 같은 사람이 다시 올 때 처음부터 설명하게 만들지 않기 위해서다. 예약 캘린더만 있으면 이력은 시간축이고, 요청 기록이 있으면 이력은 문제축이 된다. 상담 제품에는 문제축이 맞다.

화면 문장도 맞췄다. “바로 예약” 대신 “먼저 요청 남기기”가 기본 버튼이다. 내부적으로는 같은 리드라도, 사용자에게 보이는 다음 행동이 달라지면 기대가 달라진다.

마치며

요청 단계가 늘면 전환 일부는 떨어질 수 있다. 그 비용을 인정해야 한다. 대신 방에 들어왔을 때의 준비 비용과 “시간만 버리고 끝났다”는 인상이 줄어든다. 나는 후자를 더 비싼 손실로 본다.

아직도 채널별 유입 문장, 질문 세트, 거절/보류 기준은 다듬는 중이다. 다만 큰 방향은 고정했다. DM을 워크플로라고 부르지 않는다. DM은 입구일 뿐이고, 제품의 본체는 요청이 남고 시간이 붙고 방으로 이어지는 기록 있는 경로다.

DM 상담을 바로 예약으로 보내지 않은 것은 속도를 포기한 결정이 아니다. 빈 시간 위에 상담을 올리지 않기로 한 결정이다.