예약 노쇼를 줄이는 정책 설계, 보증금·리마인드·취소 규정

 

예약 서비스를 기획하면서 운영하시는 분들 이야기를 들어보면, 거의 빠지지 않고 나오는 하소연이 노쇼입니다.
예약해 놓고 아무 연락 없이 오지 않는 고객 때문에 빈 시간이 생기고, 그 시간은 되돌릴 수 없으니까요.
예약 시스템이 단순히 "예약을 받는 도구"를 넘어서려면, 이 문제를 어떻게 줄여줄 수 있는지가 중요한 기능이라는 생각이 들었어요.
이번 글은 노쇼를 줄이기 위한 정책 선택지를 정리하고, 고객 경험과 어떻게 균형을 잡을지 고민한 내용입니다.
숫자는 모두 설명을 위한 가정입니다.

 

노쇼의 비용은 "그 시간의 매출이 사라진다"에서 끝나지 않는다고 느꼈어요.
가상의 예를 들어볼게요.
커트와 염색을 하는 작은 미용실에서 염색 예약 한 건이 노쇼가 났다고 해보겠습니다.
염색은 두세 시간짜리라서, 그 시간 동안 직원은 대기하고, 약제를 미리 준비해 뒀다면 일부는 낭비가 됩니다.
그 시간에 다른 손님을 받을 수도 있었지만, 이미 예약이 차 있다고 표시돼서 다른 손님이 예약을 포기했을 수도 있어요.

그러니 노쇼 비용은 세 가지로 나눠 볼 수 있습니다.
직접 비용은 비어버린 시간의 매출과 준비한 재료입니다.
기회 비용은 그 시간에 받을 수 있었던 다른 예약이에요.
그리고 눈에 잘 안 보이는 심리 비용이 있습니다.
노쇼가 반복되면 운영자는 예약 자체를 믿지 못하게 되고, 결국 전화 확인이나 선결제 같은 번거로운 방식으로 돌아가게 됩니다.

 

가장 부담이 적은 방법은 예약 전에 다시 알려주는 것입니다.
노쇼의 상당수는 악의가 아니라 깜빡해서 생긴다고 생각해요.
그래서 예약 하루 전이나 당일 몇 시간 전에 알림을 보내면 도움이 됩니다.

설계할 때 고민한 건 시점과 내용이었어요.
너무 이르면 잊어버리고, 너무 늦으면 일정을 바꿀 여유가 없습니다.
예를 들어 "하루 전 저녁"과 "당일 두 시간 전"처럼 두 번 보내고, 알림 안에 "일정 변경이나 취소는 여기서 하세요"라는 링크를 넣어 두는 구성을 생각해 봤습니다.
링크가 쉬워야 오지 못하게 된 고객이 전화 대신 직접 취소하고, 그러면 그 시간은 다른 고객에게 열릴 수 있어요.
리마인드의 진짜 효과는 "상기"보다 "쉬운 취소 경로"에 있다는 걸 알게 됐습니다.

 

"예약 시간 몇 시간 전까지만 무료로 취소할 수 있다"는 규칙입니다.
마감이 있으면 운영자는 그 시점 이후에는 자리를 확정된 것으로 보고 준비할 수 있어요.

다만 마감 시간을 정하는 일은 업종마다 답이 다릅니다.
커트처럼 1시간짜리는 두세 시간 전이면 다른 손님을 받을 여유가 있지만, 반나절짜리 서비스는 하루 전이나 이틀 전까지 알아야 대체가 가능합니다.
그래서 마감 시간을 서비스별로 설정할 수 있게 열어두는 게 좋다고 봤어요.
기획서에는 "취소 마감 시간은 서비스 단위로 설정, 기본값은 운영자가 정한 값"처럼 적고, 마감 이후 취소 시 어떤 일이 일어나는지(취소는 되지만 기록 표시, 보증금 차감 등)를 함께 정해야 합니다.

 

가장 강한 수단은 보증금입니다.
예약할 때 일정 금액을 미리 받고, 방문하면 결제 금액에서 차감하고, 노쇼면 운영자가 가져가는 방식이에요.
노쇼율을 줄이는 데 효과가 크다고 알려져 있지만, 고객 입장에서는 예약 단계의 장벽이 확 올라갑니다.

그래서 저는 보증금을 "모든 예약에 기본으로 걸기"보다 "필요한 곳에만 걸기"로 정리했습니다.
예를 들어 소요시간이 길거나 재료 준비가 필요한 서비스에만 켜고, 짧은 서비스에는 끄는 식이에요.
또 주말 저녁처럼 수요가 몰려 빈자리의 손해가 큰 시간대에만 적용하는 방법도 생각해 볼 수 있습니다.
보증금이 걸리면 환불 규정, 결제 수수료, 취소 마감 이전의 환불 처리까지 설계할 일이 늘어나기 때문에, 처음 버전에서는 선택 기능으로 두는 것이 현실적이라고 느꼈어요.
결제와 환불은 관련 법령과 결제사의 규정도 얽혀 있어서 기획자가 혼자 확정할 수 있는 영역이 아니라는 점도 적어 둡니다.

 

노쇼를 반복하는 고객을 아예 막고 싶다는 요구는 자연스럽게 나옵니다.
그런데 이 부분은 조심해야 한다고 생각했어요.
고객 정보를 근거로 예약을 막는 기능은 오해와 분쟁의 소지가 있고, 개인정보와도 연결되어 있습니다.
한 번의 노쇼로 낙인을 찍을 수는 없고, 불가피한 사정이 있었는지도 알 수 없으니까요.

그래서 이런 단계를 생각해 봤습니다.
처음에는 "노쇼 횟수 기록"만 보여줍니다.
운영자가 예약을 승인하기 전에 참고할 수 있는 정보로만 두는 거예요.
그다음 단계로 "반복 노쇼 시 보증금이 필요한 고객"처럼 완화된 제약을 둡니다.
완전 차단은 마지막 수단으로 남기고, 차단하더라도 고객에게 이유를 알리고 이의를 제기할 경로를 열어두는 쪽이 맞다고 봅니다.
테넌트 구조에서는 한 업장의 노쇼 기록이 다른 업장에 공유되지 않도록 데이터 범위를 분리하는 것도 중요한 기준이었어요.

 

정책을 모두 합치면 노쇼는 줄겠지만, 예약이 너무 까다로워지면 고객이 예약 자체를 포기할 수 있습니다.
저는 이렇게 단계적으로 접근하는 게 좋겠다고 정리했어요.
첫 단계는 리마인드와 쉬운 취소 경로입니다.
이건 고객에게 부담이 거의 없는 선택이에요.
두 번째는 취소 마감 시간으로, 규칙이 투명하게 보이기만 하면 대부분의 고객이 받아들이는 편이라고 생각합니다.
세 번째가 보증금이고, 운영자가 꼭 필요하다고 판단한 서비스에만 켭니다.

여기에 한 가지 원칙을 더 붙였습니다.
"규칙은 예약하기 전에 보이게 하자"입니다.
예약이 끝난 뒤에 알려주는 규칙은 불신을 만들고, 예약 화면에 한 줄로라도 먼저 보여주면 같은 규칙도 훨씬 부드럽게 받아들여져요.

정리하자면, 노쇼 정책은 기능 하나를 추가하는 일이 아니라, 운영자와 고객 사이의 약속을 어떻게 설계할지의 문제라는 생각이 들었습니다.

아직 정리하지 못한 건, 효과를 어떻게 확인할 것인가입니다.
노쇼율이 줄었는지 보려면 기준 기간의 기록이 필요하고, 정책을 바꾼 시점도 남겨둬야 하니까요.
운영자에게 "이 정책을 켜면 이만큼 줄었어요"를 보여줄 수 있는 지표 설계는 다음 숙제로 남겨 두려고 합니다.