예약 알림 설계, 알림톡·문자·푸시 선택 기준

 

예약 시스템을 기획하면서 처음에는 알림을 "나중에 붙이는 부가 기능" 정도로 생각했습니다.
그런데 예약 흐름을 한 줄로 그려보니, 알림이 빠지면 흐름이 이어지지 않는 지점이 생각보다 많더라고요.
예약이 잘 됐는지 고객이 믿을 수 있는 것도, 노쇼가 줄어드는 것도, 운영하시는 분이 새 예약을 놓치지 않는 것도 결국 알림이 맡는 일이었습니다.
이번 글에서는 알림을 언제, 어떤 채널로, 어떤 문구로 보낼지 정리하면서 세운 기준을 기록해봅니다.

 

채널을 고르기 전에 "언제 알려야 하는가"부터 적는 게 순서가 맞다고 느꼈습니다.
채널은 나중에 바꿀 수 있지만, 시점이 빠져 있으면 서비스 경험에 구멍이 나기 때문이에요.
예약 한 건의 생애주기를 따라가며 적어보면 대략 이런 목록이 나옵니다.

예약 완료 직후에는 "예약이 접수되었습니다, 날짜와 시간은 이렇습니다"라는 확인 알림이 필요합니다.
업장이 예약을 직접 승인하는 구조라면 접수와 확정을 나눠서 두 번 보내야 하고요.
방문 하루 전에는 리마인드가 필요하고, 당일 몇 시간 전에 한 번 더 보내는 경우도 있습니다.
예약이 변경되거나 취소됐을 때는 고객과 업장 양쪽에 다 알려야 하고, 업장 사정으로 취소될 때는 문구가 특히 조심스러워져요.

여기서 놓치기 쉬운 것이 받는 사람이 고객만이 아니라는 점입니다.
새 예약이 들어왔을 때, 고객이 취소했을 때, 아직 승인하지 않은 예약이 쌓여 있을 때 운영자에게도 알림이 가야 합니다.
그래서 저는 표를 만들 때 "이벤트, 받는 사람, 시점" 세 칸으로 시작했습니다.
이벤트가 열 개면 알림이 스무 개 가까이 나올 수도 있다는 걸 이 단계에서 알게 됩니다.

 

예약 알림에서 많이 쓰는 채널은 크게 알림톡, 문자, 앱 푸시 세 가지로 나눠 볼 수 있습니다.
각각 장단점이 뚜렷해서, 하나만 쓰기보다 조합하는 쪽으로 생각이 기울었어요.

알림톡은 메신저 안에서 받는 알림이라 열어볼 가능성이 높고, 미리 승인된 템플릿으로 보내는 방식이라 형식이 안정적입니다.
대신 템플릿에 들어갈 수 있는 내용에 제한이 있고, 템플릿을 새로 만들거나 고칠 때 검수를 거쳐야 해서 문구를 자유롭게 바꾸기 어렵습니다.
문자는 휴대폰 번호만 있으면 도달한다는 점이 가장 큰 장점입니다.
다만 건당 비용이 보통 알림톡보다 높은 편이어서, 발송량이 늘면 비용이 눈에 띄게 커집니다.
앱 푸시는 추가 비용이 거의 없지만 고객이 앱을 설치하고 알림을 켜 둬야 하는데, 예약 서비스는 한두 번 쓰고 마는 고객이 많아서 기대하기 어려울 때가 많아요.

그래서 정리한 기본 방향은 이렇습니다.
기본은 알림톡으로 보내고, 알림톡을 받지 못하는 경우에는 문자로 대체하며, 앱이 있는 서비스라면 푸시를 보조로 쓰는 구조입니다.
이때 "대체 발송을 쓸지"는 비용이 걸린 정책이라서, 테넌트별로 켜고 끌 수 있게 할지도 따로 정해야 합니다.
비용 감각을 위해 가정 예시를 하나 들어볼게요.
어떤 업장이 한 달에 예약 300건을 받고 예약당 알림을 평균 세 번 보낸다고 하면 월 900건입니다.
건당 단가가 몇 배 차이 나는 채널을 쓰면 이 숫자가 곧바로 월 비용 차이가 되기 때문에, 발송 건수를 먼저 어림해보는 습관이 도움이 됐습니다.

 

알림은 보낼 수 있다고 다 보내도 되는 게 아닙니다.
거래와 직접 관련된 예약 확인 알림과, 프로모션 성격의 알림은 성격이 다르다는 정도는 기획자가 알아야 해요.
정확한 요건은 법과 사업자 정책에 따라 달라질 수 있어서, 실제 적용 전에는 공식 안내와 담당 전문가 확인이 꼭 필요하다는 전제로 말씀드립니다.
제가 기획서에 적어둔 원칙은 단순합니다.
예약과 직접 관련된 안내와 광고성 안내를 이벤트 수준에서 분리하고, 광고성은 별도 동의가 있을 때만 보낸다는 것입니다.

또 하나 챙긴 것이 발송 시간대입니다.
예를 들어 방문 하루 전 리마인드를 "정확히 24시간 전"으로 만들면, 새벽 두 시 예약의 리마인드가 새벽 두 시에 가는 일이 생깁니다.
그래서 리마인드는 "전날 오후 특정 시각 이후 가장 가까운 시점" 같은 규칙으로 바꾸는 편이 낫겠다고 정리했습니다.
이런 사례는 개발자와 이야기하다가 발견했는데, 로직을 문장으로 적어보면 이런 허점이 드러나요.

 

테넌트 구조의 예약 시스템이다 보니, 업장마다 말투와 안내 사항이 다르다는 점이 알림 설계를 까다롭게 만듭니다.
예를 들어 미용실은 "방문 시 이전 시술 사진이 있으면 가져와 주세요"를 넣고 싶어 하고, 식당은 "10분 이상 늦으면 자리가 유지되지 않을 수 있습니다"를 넣고 싶어 할 수 있습니다.
그렇다고 테넌트가 알림 문구를 통째로 자유롭게 쓰게 하면, 알림톡 템플릿 검수 구조와 충돌하거나 잘못된 안내가 나갈 위험이 커집니다.

그래서 고정 문구와 변수 영역을 나누는 방식을 생각하고 있습니다.
날짜, 시간, 업장 이름, 서비스 이름처럼 시스템이 채우는 값은 변수로 두고, 업장이 직접 채우는 "추가 안내" 한 칸만 제한된 길이로 열어주는 구조입니다.
템플릿의 뼈대는 플랫폼이 관리하고, 업장은 안내 문구 한 줄만 바꿀 수 있게 하면 검수 부담과 커스터마이징 요구를 어느 정도 같이 풀 수 있어 보였어요.
이 구조에서는 "추가 안내가 비어 있을 때 문장이 어색하지 않은지"도 확인해야 해서, 기획서에 빈 값일 때의 미리보기도 같이 적어둡니다.

 

알림 설계를 하면서 가장 크게 느낀 건, 알림은 기능이 아니라 정책의 묶음이라는 점입니다.
언제 보낼지, 누구에게 보낼지, 실패하면 어떻게 할지, 비용은 누가 부담할지가 모두 정책이에요.
아직 정하지 못한 질문도 남아 있습니다.

고객이 알림을 끄고 싶다고 할 때 예약 확인까지 꺼도 되는지, 발송 실패 시 운영자에게 어떤 방식으로 알려야 하는지, 알림 이력을 테넌트에게 어디까지 보여줄지 같은 것들입니다.

이 부분은 개발자와 운영하시는 분들 이야기를 더 들어보면서 정리해 볼 생각입니다.