같은 "답변 완료"라도 이후에 할 일은 다릅니다. 고객에게 서비스 종류를 물었을 수도 있고, 가능한 시간을 제안했을 수도 있고, 최종 확정을 보냈을 수도 있습니다. 이 세 가지를 같은 상태로 기록하면 마감 때 대화창을 다시 열어봐야 합니다.
상태표는 친절하게 응대한 횟수가 아니라 예약이 현재 어디에 있고, 다음에 누가 무엇을 해야 하는지를 나타내는 도구입니다. 아래 상태는 인포픽의 작업용 제안입니다. 이용하는 예약 서비스의 공식 상태명이나 법적 예약 성립 기준을 대신하지 않습니다.
상태 이름보다 시작 조건을 먼저 정합니다
상태는 직원이 같은 사건을 보고 같은 값을 선택할 수 있을 때 쓸모가 있습니다. "거의 확정"처럼 판단이 갈리는 표현 대신 고객 답변 수신, 예약표 반영, 확정 안내 발송처럼 확인 가능한 사건으로 나눕니다.
| 상태 | 이 상태가 되는 조건 | 다음에 볼 것 |
|---|---|---|
| 접수 | 문의가 들어왔으나 내용을 아직 분류하지 않음 | 신규·변경·단순 질문 구분 |
| 고객 답변 대기 | 운영자가 필요한 질문 또는 후보를 보냄 | 고객의 누락 정보나 선택 |
| 매장 확인 중 | 고객 답변은 받았으나 매장 확인이 남음 | 시간·서비스·조건 확인과 답변 기한 |
| 보류 | 안내한 조건에 따라 특정 시각을 잠시 막음 | 보류 만료와 안내 여부 |
| 확정 | 필요 조건 충족, 예약표 반영, 확정 안내까지 완료 | 최종 날짜·시각·서비스의 일치 |
| 종료 | 취소 또는 안내한 기준에 따라 문의를 닫음 | 종료 이유와 필요한 후속 처리 |
입금이 필요한 매장이라면 그 확인도 확정 조건에 넣습니다. 예약금이 없는 매장에 입금 대기를 억지로 넣을 필요는 없습니다. 특정 고객의 요구가 아니라 운영자가 모든 문의에 일관되게 적용할 기준을 정하는 작업입니다.
가상 문의 한 건을 끝까지 따라가 봅니다
아래 EX-A는 실제 고객이 아닌 연습용 기록입니다. 고객이 9월 25일 오후를 문의했고, 매장은 16:15에 75분짜리 기본 관리가 가능하다고 확인한 상황입니다.
| 시각 | 관찰한 사건 | 현재 상태 | 다음 행동 |
|---|---|---|---|
| 10:02 | 첫 문의 도착 | 접수 | 서비스와 첫 방문 여부 확인 |
| 10:05 | 운영자가 확인 질문 발송 | 고객 답변 대기 | 고객이 서비스 답변 |
| 10:12 | 기본 관리·첫 방문 답변 수신 | 매장 확인 중 | 75분 구간 대조 |
| 10:17 | 16:15 후보를 제안 | 고객 답변 대기 | 고객 선택 수신 |
| 10:25 | 고객이 16:15 선택 | 매장 확인 중 | 다른 접수와 충돌 없는지 재확인 |
| 10:28 | 예약표 반영과 확정 안내 완료 | 확정 | 최종 정보 대조 |
10:17의 안내를 곧바로 확정이라고 기록하지 않는 이유는 고객이 아직 선택하지 않았기 때문입니다. 10:25에도 매장 최종 확인 전이라면 확정 안내를 서두르지 않습니다. 이 사이에 시간을 막아두기로 했다면 보류 상태와 기한을 명시적으로 기록합니다.
보류가 필요한 경우와 필요 없는 경우
가격만 묻는 문의까지 모두 가예약으로 처리하면 실제보다 예약표가 가득 찹니다. 보류는 구체적인 시각을 임시로 확보할 때 사용합니다. 보류하지 않는 매장은 고객에게 "현재 확인되는 후보이며 답장 후 최종 확인한다"고 안내하고, 고객 선택 시 예약표를 다시 확인하면 됩니다.
보류를 운영한다면 최소한 시각, 만료 시점, 고객에게 안내한 내용을 함께 기록하세요. 내부에서 30분으로 정해놓고 고객에게는 알리지 않은 상태라면, 시간이 지났다는 이유만으로 고객도 그 조건을 알고 있었다고 가정할 수 없습니다.
연습용 보류 안내: 9월 25일 16:15를 오늘 11:00까지 임시로 확보해두겠습니다. 이 시간까지 선택 여부를 알려주세요. 아직 최종 확정 전이며, 답장을 확인한 뒤 확정 안내를 보내드리겠습니다.
확정 뒤 변경 요청이 들어오면 두 기록을 나눕니다
이미 16:15로 확정된 고객이 17:30으로 바꿀 수 있느냐고 묻는 상황입니다. 이때 기존 16:15 예약을 먼저 지우면 고객이 새 시각을 선택하지 않았거나, 새 시각이 불가능할 때 기준 일정을 잃게 됩니다.
예약표의 기존 확정은 유지하고, 문의 기록에는 "변경 요청 확인 중"을 남깁니다. 변경 문의에는 기존 예약 ID와 제안 시각을 연결합니다. 새 시각 확정이 끝난 뒤 기존 구간을 해제하고 변경 이력을 남기는 순서입니다.
- 기존 확정 ID와 16:15 점유 구간을 확인합니다.
- 17:30의 빈 구간과 서비스 시간을 대조합니다.
- 고객에게 변경 가능 여부와 필요한 조건을 안내합니다.
- 고객 선택을 확인하고 새 예약표를 반영합니다.
- 기존 구간 해제와 최종 변경 안내를 완료합니다.
변경을 철회했다면 기존 예약은 그대로 두고 변경 문의만 종료합니다. 두 행을 만들었다고 예약 건수를 두 번 세면 안 됩니다. 구체적인 문장은 변경 요청 응대 예제에서 볼 수 있습니다.
CSV에는 상태 변경의 근거를 남깁니다
예약 상태 관리표의 열은 기록 ID, 현재 상태, 상태 변경 시각, 확인된 사실, 확인 필요, 다음 행동, 담당, 변경 이력입니다. 기본 예시의 "확인중"은 실제로 쓰기 전에 "매장 확인 중"처럼 위 표의 상태명으로 통일하세요.
확인된 사실에는 "고객이 16:15 선택", 확인 필요에는 "다른 접수와 충돌 여부", 다음 행동에는 "운영자: 예약표 반영 후 확정 발송"을 넣을 수 있습니다. 고객의 전체 메시지를 옮기는 대신 상태를 바꿀 근거만 적는 방식입니다.
마감 때 발견해야 하는 세 가지 불일치
첫째, 상태는 확정인데 예약표에 날짜가 없는 경우입니다. 둘째, 예약표는 바뀌었는데 고객에게 이전 시각이 안내된 경우입니다. 셋째, 보류 상태인데 만료 시각이나 다음 행동이 없는 경우입니다. 이 세 경우는 상태 이름을 더 만드는 것으로 해결되지 않습니다. 기록과 안내를 대조해야 합니다.
한 사람이 쓰더라도 상태 이름을 자주 바꾸면 지난 기록을 같은 기준으로 집계하기 어렵습니다. 첫 주에는 위 상태로 시작하고, 구분하지 못하는 상황이 실제로 생겼을 때만 추가하세요. 한 주의 미처리 행을 분석하는 방법은 주간 점검 예제에서 이어집니다.