알림톡 템플릿 작성방법은 발송 목적부터 적는 것

얼마 전 주문 확인 알림톡이 반려됐다는 연락을 받았습니다. 문구는 짧고 주문번호도 들어 있었는데, 끝에 붙인 ‘이번 주 할인 상품 보기’ 버튼이 문제였습니다. 알림톡 템플릿 작성방법을 물으면 저는 문장부터 다듬지 않습니다. 먼저 이 메시지가 고객의 거래나 신청에 따라 꼭 필요한 안내인지 확인합니다.
정보성 안내인지 먼저 구분합니다
알림톡은 주문, 결제, 배송, 예약처럼 고객의 행동이나 거래와 연결된 정보를 보내는 채널입니다. 주문 완료 고객에게 주문번호와 결제금액을 알리는 문구는 목적이 분명합니다. 같은 고객에게 신상품이나 할인 행사를 권하는 문구는 광고성 정보입니다. ‘주문 안내’라는 제목을 붙여도 본문이나 버튼에 판촉 내용이 섞이면 정보성 안내로 보기 어렵습니다.
한국인터넷진흥원의 불법스팸 안내에서도 광고성 정보는 사전 수신동의와 수신거부 처리 등을 따로 다룹니다. 광고 메시지에는 필요한 표시 사항과 무료 수신거부 방법을 갖춰야 하고, 밤 9시부터 다음 날 오전 8시까지 보내려면 별도의 야간 수신동의가 필요합니다. 수신거부한 사람에게는 광고를 다시 보내면 안 됩니다. 알림톡에 광고 문구를 얹어 이런 절차를 건너뛰려는 운영은 피해야 합니다.
특히 쿠폰이나 적립금을 일방적으로 지급한 뒤 ‘소멸 예정’이라고 알리는 문구는 주의가 필요합니다. 거래 안내처럼 보이더라도 광고 수신동의가 필요한 사례가 있습니다. 발송 목적이 애매하면 혜택 문구를 지우고 정보성으로 인정될 내용만 남길 수 있는지부터 판단합니다. 남길 수 없다면 광고 메시지 발송 요건을 검토해야 합니다.
한 템플릿에는 한 가지 사건만 씁니다
문구의 출발점은 ‘무슨 일이 발생했는가’입니다. 주문 완료, 결제 실패, 배송 시작, 예약 변경을 각각 별도 템플릿으로 잡으면 고객도 내용을 바로 이해하고 운영자도 발송 조건을 관리하기 쉽습니다. 주문 완료와 배송 시작을 한 문구에 담으려 하면 아직 확정되지 않은 내용을 보내거나 빈 항목을 남기기 쉽습니다.
저는 본문을 발신자, 발생한 일, 고객이 확인할 값, 필요한 다음 행동 순서로 씁니다. 예를 들면 ‘[가온상점] #{고객명}님, 주문이 완료됐습니다. 주문번호: #{주문번호} / 결제금액: #{결제금액}원. 주문 내역은 아래 버튼에서 확인할 수 있습니다.’ 정도면 충분합니다. 실제 발송 시에는 빈칸이 생기지 않도록 값이 없는 항목의 처리 방식까지 정해야 합니다.
예약 변경 안내라면 변경 전후 날짜와 시간을 함께 적는 편이 낫습니다. ‘예약이 변경됐습니다’만 보내면 고객이 다시 조회해야 하니까요. 반대로 고객에게 필요하지 않은 내부 접수번호나 처리 단계까지 길게 넣으면 중요한 값이 묻힙니다. 개인정보도 최소한으로 담습니다. 화면을 옆 사람이 볼 수 있는 메시지에 주민등록번호나 상세한 민감 정보를 넣을 이유는 없습니다.
변수와 버튼은 승인된 내용에 맞춥니다
변수는 고객마다 달라지는 값에만 씁니다. 고객명, 주문번호, 예약일시처럼 의미가 고정된 항목이 적합합니다. #{안내문구} 같은 큰 변수 하나에 문장 전체를 넣으면 고객별로 다른 판촉 문구가 들어갈 수 있고, 템플릿 검수 취지도 흐려집니다. 고정 문장은 템플릿에 적고 변수의 용도를 분명히 하는 편이 안전합니다.
버튼도 본문과 같은 목적이어야 합니다. 배송 안내의 ‘배송 조회’, 예약 안내의 ‘예약 확인’은 메시지와 자연스럽게 이어집니다. 주문 안내 아래 ‘특가 상품 보기’를 붙이면 안내를 광고 유입 수단으로 바꿔 버립니다. 카카오 비즈메시지 안내에는 승인된 템플릿과 실제 발송 내용 또는 버튼 정보가 다르면 발송되지 않을 수 있다고 명시돼 있습니다. 검수 후 버튼 이름이나 연결 대상을 운영 중에 임의로 바꾸지 않도록 관리해야 합니다.
변수 값의 길이도 미리 시험합니다. ‘김민수’라는 이름으로만 화면을 확인하면 긴 상품명이나 여러 품목이 들어왔을 때 줄바꿈이 어색해질 수 있습니다. 금액 단위가 중복되거나 ‘원원’처럼 표시되지 않는지도 봅니다. 주문번호와 예약시간이 서로 다른 고객의 값으로 섞이는 문제는 템플릿 심사보다 발송 데이터 점검에서 잡아야 합니다.
검수 전에 실제 발송 흐름까지 확인합니다
템플릿을 등록하기 전에는 발송 조건을 한 줄로 적어 둡니다. 예를 들어 ‘결제 승인 직후, 해당 주문의 구매자에게 1회 발송’입니다. 이 조건을 적기 어렵다면 메시지 목적이 너무 넓을 수 있습니다. 다음으로 예시 값을 넣어 본문과 버튼을 확인하고, 승인된 템플릿 코드와 발송 시스템이 사용하는 코드를 맞춥니다.
- 고객의 거래나 신청에 따른 안내인지 확인합니다.
- 본문과 버튼에 할인, 구매 유도, 채널 홍보가 섞이지 않았는지 봅니다.
- 각 변수에 어떤 값이 들어가는지 정하고 빈값과 긴 값으로 시험합니다.
- 승인된 문구·버튼·템플릿 코드가 실제 발송 요청과 일치하는지 확인합니다.
- 발송 실패 시 문자로 전환한다면 문자 내용과 비용, 광고성 여부를 따로 점검합니다.
마지막 항목은 자주 빠집니다. 알림톡이 실패했을 때 문자로 자동 전환하도록 설정해 두면, 고객은 결국 문자 내용을 받습니다. 정보성 안내의 대체 문자에도 판촉 문구가 들어가면 발송 채널만 바뀌었을 뿐 광고 규정 검토가 필요합니다. 발송 성공 건수만 볼 게 아니라 실패 사유와 대체 발송 내용까지 함께 확인해야 운영 사고를 줄일 수 있습니다.
제가 템플릿을 볼 때 가장 먼저 읽는 것은 멋진 첫 문장이 아니라 ‘이 고객에게 지금 이 안내가 필요한 이유’입니다. 그 이유가 본문과 발송 조건에 뚜렷하게 드러나면 문구도 짧아지고 검수 뒤 운영도 한결 수월해집니다.
