예약 정책 안내문 만드는 법: 변경·취소·지각 기준 쓰기
예약 정책 안내문을 쓰다 보면 강한 경고부터 떠올리기 쉽습니다. 하지만 말투가 단호하다고 기준까지 분명해지는 것은 아닙니다. "당일 취소는 불이익이 있습니다"라고만 쓰면 당일이 언제부터인지, 변경과 취소는 어떻게 다른지, 어디로 연락해야 하는지 알 수 없습니다.
안내문은 새 규칙을 만드는 곳이 아니라 운영자가 이미 정한 기준을 고객이 예약 전에 읽을 수 있게 옮기는 곳입니다. 변경, 취소, 지각, 미응답 상황에서 무엇을 먼저 정해야 하는지부터 살펴봅니다.
내부 정책 설계표를 채운 뒤 고객용 안내문을 쓰고, 어느 예약 단계에 보여줄지와 수정 이력을 함께 남깁니다.
안내문보다 내부 기준표를 먼저 만듭니다
| 상황 | 먼저 결정할 값 | 고객에게 알려야 할 내용 |
|---|---|---|
| 일정 변경 | 요청 기한, 횟수, 연락 채널 | 언제까지 어디로 요청하고 새 일정은 언제 확정되는지 |
| 예약 취소 | 접수 기준, 처리 방법, 확인 항목 | 취소 요청과 완료 시점의 차이 |
| 고객 지각 | 연락 기준, 조정 가능 범위 | 도착 예상 시각을 보내는 방법 |
| 매장 지연 | 알림 시점, 제안 가능한 대안 | 예상 지연과 고객의 다음 선택 |
| 미응답 | 가예약 보류 기한, 종료 알림 | 보류가 끝나는 시각과 재문의 방법 |
다른 매장의 문구를 복사하거나 AI가 만든 규칙을 바로 사용하지 마세요. 운영 지역, 서비스, 결제 방식과 플랫폼에 맞는 기준을 직접 확인하고 필요하면 관련 전문가의 검토를 받습니다.
규칙 한 줄에 빠지면 안 되는 내용
- 적용 상황: 변경, 취소, 지각 중 무엇에 적용되는지 씁니다.
- 기준 시점: "미리" 대신 날짜와 시각을 계산할 기준을 씁니다.
- 고객 행동: 어느 채널로 어떤 정보를 보낼지 정합니다.
- 매장 처리: 요청 접수 후 어떤 확인을 하는지 설명합니다.
- 완료 조건: 고객이 어떤 메시지를 받으면 처리가 끝나는지 씁니다.
내부 규칙과 고객용 문장은 역할이 다릅니다
| 상황 | 내부 처리 순서 | 고객 안내 예시 |
|---|---|---|
| 변경 | 기존 예약 유지 → 새 일정 확인 → 재확인 → 교체 | "새 확정 메시지를 받기 전까지는 기존 예약이 유지됩니다." |
| 지각 | 도착 예상 확인 → 다음 예약 영향 확인 → 범위 안내 | "도착 예상 시각을 보내주시면 가능한 진행 범위를 확인하겠습니다." |
| 미응답 | 보류 기한 확인 → 마지막 안내 → 상태 종료 | "안내드린 기한이 지나 현재 가예약은 종료되었습니다." |
위 문장은 구조를 설명하는 예시입니다. 실제 기한과 조건이 빠져 있으므로 그대로 공지하지 말고 매장 기준을 채워야 합니다.
가상 기준을 안내문으로 바꿔봅니다
상황: 일정 변경 / 채널: 공식 메시지 / 처리: 기존 예약을 유지한 채 새 시간 확인 / 완료: 새 확정 메시지를 보낸 시점
고객용 초안: "일정 변경은 [공식 채널]로 기존 예약 정보와 희망 일정을 보내주세요. 가능한 시간을 확인하며, 새 확정 메시지를 받기 전까지는 기존 예약이 유지됩니다."
요청 채널, 매장 처리, 완료 조건이 보입니다. 실제 요청 기한이나 별도 조건은 운영자가 확인한 값만 추가합니다. 모든 예외를 한 문장에 넣기보다 상세 정책 위치나 사람 연결 방법을 함께 제공합니다.
정책은 예약 여정의 네 지점에서 보여줍니다
| 노출 지점 | 보여줄 범위 | 목적 |
|---|---|---|
| 문의 전 | 예약 방식과 핵심 조건 요약 | 기본 기대를 맞춥니다. |
| 일정 제안 | 가예약 여부와 보류 기한 | 시간 제안을 확정으로 오해하지 않게 합니다. |
| 예약 확정 | 변경·취소·지각 연락 방법 | 확정 정보와 함께 다시 확인합니다. |
| 전날 안내 | 당장 필요한 연락 방법 | 긴 정책 대신 실행 정보를 줍니다. |
모든 단계에 긴 정책을 반복하면 중요한 예약 정보가 묻힙니다. 문의 전에는 요약과 상세 위치를, 확정 메시지에는 실제 연락 방법을 넣습니다. 전날 안내는 이동과 변경 연락처럼 시점상 필요한 항목에 집중합니다.
변경·취소·지각을 같은 문장으로 처리하지 않습니다
기존 상태 보존
새 일정 확정 전 기존 예약을 어떻게 다룰지 설명합니다.
종료 확인
취소 요청과 취소 완료를 구분합니다.
가능 범위 확인
도착 예상 시각을 받고 영향 확인 후 답합니다.
정보와 선택지
예상 지연과 다음 행동을 매장이 먼저 알립니다.
일정 변경의 처리 순서는 예약 변경 판단표에서, 확정·전날·당일에 반복할 정보는 예약 단계별 안내 가이드에서 확인하세요.
예외 상황에는 사람 연결 문장을 둡니다
- 서로 다른 정보가 있으면 확인된 사실부터 요약합니다.
- 즉시 판단하기 어렵다면 언제까지 확인할지 알립니다.
- 자동응답이 반복되지 않도록 사람 연결 기준을 표시합니다.
- 답변 후 적용한 정책 버전과 처리 결과를 기록합니다.
감정이 섞인 메시지에는 정책 전문을 반복하기보다 불만 첫 답변의 사실 확인 순서로 전환합니다.
정책 수정일과 적용 범위를 기록합니다
| 버전 | 수정일 | 바꾼 항목 | 적용 대상 | 노출 위치 |
|---|---|---|---|---|
| v1.0 | ____-__-__ | 최초 기준 | 해당 날짜 이후 접수 예약 | 문의 안내·확정 메시지 |
| v1.1 | ____-__-__ | 연락 채널 명확화 | 운영자 확인 | 확정 메시지 |
수정일은 글을 새것처럼 보이게 하는 장식이 아닙니다. 어느 시점에 어떤 기준으로 안내했는지 확인하려는 기록입니다. 문구를 바꾸면 자동응답, 프로필, 확정 메시지처럼 같은 규칙을 쓰는 위치도 함께 고칩니다.
AI에는 문장 정리만 맡깁니다
아래 내용은 운영자가 확정한 예약 정책이다. 새로운 조건이나 숫자를 만들지 말고 '적용 상황, 기준 시점, 고객 행동, 매장 처리, 완료 조건'이 보이는지 확인해줘. 빠진 값은 [운영자 확인]으로 표시하고 모호한 표현은 구체적인 행동 안내로 바꿀 대안을 제시해줘.
공개 전 최종 확인표
- 변경·취소·지각의 적용 상황이 구분되는가?
- '미리', '경우에 따라', '불이익'처럼 기준 없는 표현을 줄였는가?
- 연락 채널과 보낼 정보가 보이는가?
- 요청 접수와 처리 완료를 구분했는가?
- 예외 상황에서 사람에게 연결되는가?
- 확인하지 않은 숫자나 조건을 추가하지 않았는가?
- 수정일과 적용 범위를 기록했는가?
본문에 나온 빈 서식 · v1.0
예약 정책 설계표
변경·취소·지각 규칙을 적용 시점, 고객 행동, 매장 처리, 예외 연락으로 나누는 빈 서식입니다.
예시 행은 열의 쓰임을 보여주려고 넣었습니다. 사용하기 전 지우고 실제 고객 정보 대신 내부 식별 코드를 쓰세요.