예약 상태표 설계 가이드: 문의와 확정을 헷갈리지 않는 기준

같은 대화를 보고도 고객은 예약이 잡혔다고 생각하고, 매장은 아직 시간을 확인하는 중이라고 생각할 수 있습니다. "가능해요", "일단 잡아둘게요", "확인했습니다"처럼 상태가 보이지 않는 말이 원인이 되기도 합니다. 내부 예약표가 정확해도 고객에게 보낸 문장이 다르면 오해는 남습니다.

해결 방법은 상태 이름을 많이 만드는 데 있지 않습니다. 문의, 정보 대기, 일정 확인, 가예약, 확정, 종료가 언제 시작되고 어떤 조건에서 다음 단계로 넘어가는지를 같은 표에 적는 것이 더 중요합니다.

상태는 기분이 아니라 확인된 사건으로 바꿉니다

"거의 확정", "아마 가능", "잠시 보류"는 듣는 사람에 따라 뜻이 달라집니다. 누가 어떤 정보를 보냈는지, 운영자가 무엇을 확인했는지처럼 나중에 다시 확인할 수 있는 사건으로 상태를 정합니다.

가예약을 운영하지 않는 매장은 해당 상태를 빼도 됩니다. 예약금 확인이나 신청서 제출처럼 확정 전에 꼭 거치는 단계가 있다면 그 상태를 추가하되 고객에게도 같은 용어와 조건을 설명해야 합니다.

가예약은 보류 시간과 해제 조건이 있어야 합니다

• 시작 조건: 고객이 시간을 선택하면 시작하는지, 별도 정보가 필요한지
• 보류 기한: 어느 날짜와 시각까지 자리를 유지하는지
• 종료 조건: 확정, 자동 해제, 고객 취소 중 무엇으로 끝나는지

상태표에는 현재 값 하나와 이력 한 줄을 남깁니다

한 예약에 "정보 대기/일정 확인"처럼 두 상태를 같이 적으면 누가 움직여야 하는지 다시 모호해집니다. 현재 상태는 하나만 고르고, 이전 상태는 이력 칸에 시간과 함께 남깁니다.

위 표는 구조를 설명하는 가상 예시이며 실제 매장 데이터를 사용한 사례가 아닙니다. 상태 변경 시각은 성과를 과장하기 위한 값이 아니라 어느 안내 이후 상태가 달라졌는지 찾는 기준입니다.

고객 메시지에도 현재 상태를 한 줄로 표시합니다

상태 이름을 매번 반복할 필요는 없지만 "확정", "확인 중", "답변 대기"처럼 오해를 줄이는 단어는 분명히 표시합니다. 가능 시간을 제안하는 문장과 예약을 확정하는 문장은 따로 써야 합니다.

가상 대화로 상태 전환을 확인합니다

이 대화는 흐름을 설명하기 위해 만든 가상 상황입니다. 업종별 예약금이나 동의 절차를 가정하지 않았으며 매장에 해당하는 조건은 직접 채워야 합니다.

변경 요청은 기존 확정을 지우지 않고 처리합니다

확정된 예약에 변경 요청이 들어와도 기존 시간을 먼저 삭제하지 않습니다. 현재 상태를 "변경 확인 중"으로 표시하고 기존 확정 정보와 새 희망 정보를 함께 둡니다. 새 시간이 가능하고 고객이 다시 확인한 뒤에 확정 정보를 바꿉니다.

구체적인 처리 순서는 예약 변경 판단표와 답변 순서에서 확인할 수 있습니다. 변경이 끝난 뒤에는 예약 확정 메시지의 필수 정보를 처음부터 다시 보냅니다.

색상은 보조 수단으로만 사용합니다

• 셀 안에 상태명을 적고 색은 빠르게 찾는 용도로만 사용합니다.
• 종료된 행은 별도 보기로 옮겨 현재 업무와 분리합니다.
• 기한이 지난 행은 색보다 '기한 지남' 표시로 찾습니다.
• 새 상태를 추가할 때 시작·종료 조건도 함께 적습니다.

AI로 상태 기준을 점검할 때의 경계

AI는 가상 문장을 기준표에 대입해 빠진 항목을 찾는 데 사용할 수 있습니다. 실제 고객 개인정보를 입력하거나 예약 가능 여부와 확정 조건을 판단하게 해서는 안 됩니다.

상태표 완성 체크리스트

• 각 상태의 시작 조건이 확인 가능한 사건으로 적혀 있는가?
• 한 문의에는 현재 상태가 하나만 있는가?
• 가예약에 보류 기한과 해제 조건이 있는가?
• 내부 상태와 고객에게 보낸 문장이 일치하는가?
• 확정 조건 전 '확정'이라고 쓰지 않는가?
• 변경 요청 때 기존 확정 정보를 바로 지우지 않는가?
• 종료 이유가 완료·취소·미응답 중 하나로 남는가?

상태를 붙일 목록이 없다면 먼저 예약 문의 한 줄 기록표를 만드세요. 최초 문의에서 필요한 정보가 자주 빠진다면 DM 예약 접수 기준부터 보완하는 것이 순서입니다.