오피셜메일

Posted on Jul 30 • Originally published at officialsite.kr

1인 개발자를 위한 고객 문의 큐: CRM 전에 필요한 4가지 상태

#startup #productivity #beginners #webdev

고객 문의를 관리하는 일은 거대한 CRM 프로젝트가 아니라, 작은 상태 머신(state machine) 을 운영하는 일에 가깝습니다.

혼자 제품을 만드는 동안 문의는 이메일, SNS DM, 폼, 전화에서 동시에 들어옵니다. 각 채널을 따로 기억하면 누락은 트래픽이 많을 때보다 컨텍스트 전환이 많을 때 먼저 생깁니다.

이 글에서는 도구보다 먼저 고정해야 할 최소 데이터 모델과 전이 규칙을 정리합니다.

최소 스키마부터 정한다

문의 한 건을 다음처럼 생각해 봅시다.

type InquiryState = "new" | "active" | "waiting" | "done";

type Inquiry = {
  customer: string;
  source: "email" | "form" | "social" | "phone";
  summary: string;
  state: InquiryState;
  nextAction: string | null;
  dueAt: string | null;
  sourceUrl?: string;
};

필드는 많을수록 좋은 것이 아닙니다. 다음 판단을 바꾸는 정보만 저장해야 합니다. 특히 nextAction과 dueAt이 없다면 그 항목은 기록이지 작업이 아닙니다.

네 상태면 대부분의 초기 팀에 충분하다

상태	의미	빠져나가는 조건
`new`	아직 첫 답변 전	이해 확인 또는 추가 질문을 보냄
`active`	내가 처리할 일이 있음	전달을 마치거나 상대 답변을 기다림
`waiting`	고객·파트너 회신 대기	회신 수신 또는 확인 날짜 도달
`done`	남은 행동이 없음	새 요청이 생기면 다시 `new`

상태 이름보다 중요한 것은 전이 조건입니다. “진행 중”에 모든 것을 몰아넣으면 큐는 다시 받은편지함처럼 변합니다.

운영 규칙은 코드의 불변식처럼 다룬다

작은 문의 시스템에도 몇 가지 불변식이 필요합니다.

new 상태는 정해 둔 점검 시간 안에 비워진다.
active 항목에는 항상 하나의 다음 행동이 있다.
waiting 항목에는 다시 볼 날짜가 있다.
done은 “답장을 보냄”이 아니라 “남은 행동이 없음”을 뜻한다.
전화와 DM에서 결정한 내용도 기준 기록 위치로 옮긴다.

이 규칙은 도구를 바꿔도 유지됩니다. 스프레드시트에서 시작했다가 데이터베이스나 티켓 시스템으로 옮겨도 마이그레이션할 수 있는 운영 지식입니다.

폴링 작업처럼 하루 두 번 실행한다

알림마다 즉시 인터럽트를 받는 대신 문의 큐를 짧게 폴링합니다.

오전 실행

new 항목에 첫 응답 보내기
오늘 기한인 active 항목 처리하기
오래된 waiting 항목 확인하기

오후 실행

오늘 보낸 답변에 nextAction 추가하기
내일 기한을 점검하기
실제로 끝난 항목만 done으로 옮기기

긴급 요청의 정의만 별도로 두면, 나머지 문의가 개발 시간을 계속 끊는 일을 줄일 수 있습니다.

실패 처리는 사람에게 명확해야 한다

자동 회신이 발송됐다고 업무가 끝난 것은 아닙니다. 폼 전달 실패, 잘못된 주소, 첨부 누락처럼 시스템이 놓칠 수 있는 경우를 정하세요.

전달 실패는 별도 라벨 또는 오류 큐로 보냅니다.
자동 회신에는 실제 확인 가능한 시간만 안내합니다.
고객의 마지막 메시지와 내가 해야 할 일을 분리합니다.
후속 날짜가 지나면 조용히 묻히지 않고 다시 active로 올립니다.

자동화는 반복이 보인 뒤에 붙인다

초기에는 수동으로 일주일 정도 운영하면서 어떤 입력이 반복되는지 관찰하는 편이 낫습니다. 그다음 아래처럼 경계가 선명한 부분부터 자동화합니다.

form submitted
  -> shared inbox
  -> create inquiry(new)
  -> assign dueAt
  -> notify owner

반대로 답변의 품질 판단, 요구사항 해석, 환불·보상 결정처럼 맥락이 중요한 일은 사람이 확인해야 합니다.

공식 요청의 기준 채널이 필요하다면 도메인 기반 회사 메일을 한곳의 intake로 쓸 수 있습니다. 하지만 제품을 선택하기 전에 상태와 다음 행동 규칙부터 고정하세요.

오늘 적용할 체크리스트

최근 문의를 한 목록으로 모았다
각 항목에 상태 하나를 붙였다
active 항목에 다음 행동을 적었다
waiting 항목에 다시 볼 날짜를 적었다
오전·오후 점검 시간을 정했다

운영 관점의 전체 예시와 응답 구조는 1인기업 고객 문의 관리 4단계 가이드에서 이어서 볼 수 있습니다.

DEV Community