홈블로그리소스배송 알림 자동화 방법: 6단계로 살펴보는 트리거, 채널 및 템플릿

배송 알림 자동화 방법: 6단계로 살펴보는 트리거, 채널 및 템플릿

17TRACK

배송 알림을 자동화하려면 배송 이벤트를 주문 기록에 연결하고, 어떤 상태 변경에 메시지를 보낼지 정의하며, 허용된 전달 채널을 선택하고, 각 트리거에 템플릿을 연결하세요. 그런 다음 출시 전에 중복 방지, 예외 처리 및 테스트를 추가하세요. 아래의 6단계에서는 전자상거래 팀이 반복적이거나 오해를 불러일으키는 알림을 보내지 않으면서 고객에게 유용한 업데이트를 제공하는 워크플로를 구축하는 방법을 설명합니다.

How to Automate Shipment Notifications Triggers Channels Templates in 6

이 가이드는 구매 후 커뮤니케이션을 담당하는 판매자, 전자상거래 운영팀 및 개발자를 위한 것입니다. 권장되는 시작점은 운송사 접수, 배송 출발, 배송 완료, 고객의 조치가 필요한 예외 등 신뢰할 수 있는 소수의 알림입니다. 다른 메시지는 별도의 고객 질문에 답할 때만 추가하세요.

1. 추적 이벤트를 올바른 주문 및 수취인에 연결하기

배송 라벨, 운송사 스캔 및 고객 알림은 서로 다른 것입니다. 라벨을 생성했다고 해서 운송사가 소포를 수령했다는 의미는 아닙니다. 자동화는 처음부터 이러한 차이를 유지해야 합니다.

먼저 알림 결정을 담당할 시스템을 식별하세요. 스토어의 알림 워크플로, 추적 애플리케이션 또는 주문 관리 시스템에 연결된 서비스일 수 있습니다. 각 메시지 유형에 하나의 담당 시스템을 지정하여 여러 시스템이 동일한 업데이트를 독립적으로 보내지 않도록 하세요.

실용적인 구현 방법은 다음 두 가지입니다.

  • 앱 기반 설정: 팀이 전체 통합을 직접 구축하지 않고 지원되는 이벤트와 고객 대상 메시지를 구성하려는 경우 전자상거래 추적 애플리케이션을 사용하세요. Shopify 판매자의 경우 17TRACK 앱 등록 페이지가 배송 추적 및 알림 워크플로를 평가하기 위한 적절한 시작점입니다. 규칙을 구성하기 전에 구체적인 트리거, 채널, 사용자 지정 옵션 및 요금제 요구 사항을 확인하세요.
  • API 기반 설정: 배송 이벤트를 기존 주문 시스템 또는 사용자 지정 메시징 워크플로에 전달해야 하는 경우 추적 통합을 사용하세요. 17TRACK Tracking API와 공식 문서는 관련 구현 참고 자료입니다. 사용하려는 통합의 이벤트 전달 방식, 페이로드 필드, 인증 및 재시도 동작을 확인하세요. 추적 데이터를 수신하는 일과 고객 메시지를 보내는 일은 서로 다른 책임입니다.

어떤 방법을 선택하든 각 배송을 올바른 주문 및 수취인에 매핑하세요. 유용한 내부 기록에는 다음이 포함됩니다.

  • 주문 참조 번호 및 배송 식별자.
  • 가능한 경우 운송장 번호 및 운송사 식별자.
  • 해당 배송에 포함된 상품, 특히 분할 주문의 경우.
  • 고객 연락처, 언어, 시간대 및 채널 환경설정.
  • 마지막으로 확인된 배송 상태 및 이벤트 발생 시간.
  • 각 메시지가 어떤 배송과 관련되었는지를 포함한 알림 기록.

이벤트 발생 시간과 시스템이 업데이트를 수신한 시간을 구분하세요. 지연된 스캔이 자동으로 새로운 고객 알림이 되어서는 안 됩니다. 또한 지원팀이 모호한 이벤트를 조사할 수 있도록 정규화된 상태와 함께 운송사의 원래 설명을 보존하세요.

2. 의미 있는 배송 변경을 반영하는 트리거 정의하기

트리거는 모든 새로운 추적 기록이 아니라 고객과 관련된 변경을 나타내야 합니다. 여러 물류 시설 스캔이 모두 “배송 중”을 의미할 수 있습니다. 각각에 대해 알림을 보내면 고객의 의사 결정에 도움이 되지 않는 소음이 발생합니다.

수신 이벤트를 이해하기 쉬운 소수의 상태에 매핑하세요. 다음 표는 제안된 워크플로이며, 모든 운송사에 적용되는 보편적인 상태 사전은 아닙니다.

트리거발송 조건메시지 목적
라벨 생성선택 사항. 준비 단계와 운송사의 소포 보관을 구분합니다.추적 정보가 준비되었음을 설명합니다.
운송사 접수지원되는 이벤트가 운송사가 소포를 수령했음을 나타냅니다.배송이 운송사 네트워크에 진입했음을 확인합니다.
배송 중선택적 주요 단계. 반복되는 일반 스캔은 억제합니다.스캔별 피드가 아닌 의미 있는 진행 상황을 제공합니다.
배송 출발수신 상태가 이 해석을 명시적으로 뒷받침합니다.고객이 소포 수령을 준비하도록 돕습니다.
배송 예외중요한 문제 또는 필요한 조치가 확인되었습니다.문제와 다음에 취할 유용한 조치를 설명합니다.
배송 완료운송사가 이 배송의 완료를 보고합니다.보고된 결과를 확인하고 도움을 받을 방법을 제공합니다.

예외는 일반적인 주요 단계보다 신중하게 처리하세요. 배송 시도 실패, 통관 문제, 주소 문제 및 발송인 반송 이벤트에는 서로 다른 안내가 필요할 수 있습니다. 이벤트가 고객이 해야 할 일을 설명하지 않는다면 해결 방법을 임의로 만들어내지 마세요.

“최근 업데이트 없음” 규칙에는 하나의 보편적인 간격을 적용하지 말고 서비스와 경로에 적합한 기준을 선택하세요. 스캔이 없다고 해서 소포가 분실되었다는 증거는 아닙니다. 불확실한 사례를 내부 검토 대기열로 보내거나, 알려진 사실을 정확히 설명하는 중립적인 업데이트를 보내세요.

예상 배송일과 배송 상태를 구분하세요. 신뢰할 수 있는 출처가 있을 때만 예상일을 포함하고, 예상치임을 명시하며, 운영상 지원할 수 없는 계산된 약속으로 누락된 데이터를 대체하지 마세요.

3. 채널을 선택하고 연락 규칙 설정하기

단순히 이용 가능하다는 이유가 아니라 메시지와 고객의 선호에 적합한 채널을 사용하세요. 이메일은 자세한 업데이트를 위한 실용적인 시작점입니다. 시간에 민감한 조치에는 더 즉각적인 채널이 유용할 수 있지만, 권한, 제공업체 규칙 및 현지 요건이 허용하는 경우에만 사용하세요.

  • 이메일: 주문 맥락, 추적 링크, 분할 배송 설명 및 지원 안내에 적합합니다. 일반 텍스트 버전을 포함하고 모바일 레이아웃을 확인하세요.
  • SMS: 허용되는 경우 짧고 실행 가능한 알림에 유용합니다. 발신자를 식별하고 메시지를 핵심 내용에 집중시키며 불필요한 주문 정보를 노출하지 마세요.
  • 푸시 알림: 고객이 앱을 사용하고 알림을 활성화한 경우 적합합니다. 일반적인 홈 화면이 아니라 관련 배송으로 연결하세요.
  • 메시징 앱: 고객이 이미 해당 채널을 사용하고 있으며 구현이 플랫폼의 권한 및 메시지 요건을 충족할 때 고려하세요.
  • 추적 페이지: 자세한 참조 목적지로 사용하세요. 발신 알림을 보완하지만 고객이 조치를 취해야 할 때 알림을 대체하지는 않습니다.

채널 간 관계를 문서화하세요. 예를 들어 일반적인 주요 단계에는 이메일을 사용하고, 조치가 필요한 배송 문제에는 허용된 모바일 채널을 사용할 수 있습니다. 모든 이벤트를 사용 가능한 모든 채널로 자동 전송하지 마세요.

방해 금지 시간 처리와 대체 정책을 설정하세요. 일시적인 이메일 실패가 자동으로 SMS 발송을 승인해서는 안 됩니다. 채널을 전환하기 전에 적절한 연락처 정보와 권한이 있는지, 다른 시스템이 이미 메시지를 보내지 않았는지 확인하세요.

배송 업데이트를 운영상의 내용으로 유지하세요. 홍보성 콘텐츠를 추가하면 관련 규정에 따라 메시지가 처리되는 방식에 영향을 줄 수 있습니다. 미국에서는 FTC의 CAN-SPAM 지침이 상업적 콘텐츠와 거래성 콘텐츠가 결합될 때 메시지의 주된 목적이 중요하다고 설명합니다. 주문을 언급하는 모든 메시지가 상업적 이메일 요건에서 면제된다고 가정하지 마세요.

4. 명확한 대체 동작이 있는 템플릿 구축하기

각 템플릿은 세 가지 질문에 답해야 합니다. 무슨 일이 있었나요? 이것이 이 배송에 어떤 의미인가요? 고객은 다음에 무엇을 해야 하나요? 데이터가 누락되었을 때 깨진 자리 표시자를 남기지 말고 깔끔하게 사라지도록 조건부 필드를 사용하세요.

아래 예시는 시작용 템플릿입니다. 대괄호로 표시된 변수는 예시일 뿐 특정 플랫폼의 템플릿 구문이 아닙니다.

운송사 접수 이메일

제목: 주문 [order_number]의 배송이 시작되었습니다

안녕하세요, [first_name]님.

[carrier_name]에서 주문 [order_number]의 배송을 접수했습니다. 여기에서 진행 상황을 확인할 수 있습니다: [tracking_link].

[신뢰할 수 있는 예상일이 있는 경우: 예상 배송일: [estimated_delivery_date]. 이 예상일은 변경될 수 있습니다.]

[주문이 분할된 경우: 이 배송에는 [shipment_items]이(가) 포함되어 있습니다. 주문의 다른 상품에는 별도의 추적 업데이트가 제공됩니다.]

배송 출발 메시지

최근 운송사 업데이트에 따르면 주문 [order_number]의 배송이 시작되었습니다. 진행 상황과 이용 가능한 배송 세부 정보를 확인하세요: [tracking_link].

운영에 그러한 약속을 뒷받침할 확실한 근거가 없는 한 보장된 도착 시간을 추가하지 마세요. “배송 출발”은 보고된 상태일 뿐, 당일 배송 완료를 보장하는 것은 아닙니다.

확인된 다음 단계가 포함된 예외 메시지

제목: 주문 [order_number]의 배송 업데이트

운송사에서 고객님의 배송에 대해 [plain_language_issue]을(를) 보고했습니다. [verified_next_step]. 여기에서 최신 세부 정보를 확인하세요: [tracking_link]. 도움이 필요하면 [support_link]로 문의하세요.

다음 단계가 확인되지 않았다면 해당 문장을 다음으로 바꾸세요. “아직 확인된 다음 단계가 없습니다. 업데이트를 확인하려면 추적 페이지를 확인하거나 지원팀에 문의하세요.” 실제로 검토가 배정된 경우에만 팀에서 조사 중이라고 말하세요.

배송 완료 이메일

제목: 배송 완료로 표시되었습니다

[carrier_name]에서 주문 [order_number]의 배송을 [delivery_date]에 배송 완료로 표시했습니다. 이용 가능한 배송 세부 정보는 여기에서 확인하세요: [tracking_link]. 찾을 수 없다면 [support_link]로 문의해 주세요. 다음 단계를 확인하는 데 도움을 드리겠습니다.

분할 주문에는 배송 단위의 표현을 사용하세요. 다른 소포가 아직 배송 중일 때 “주문이 도착했습니다”라고 하면 오해를 불러일으킬 수 있습니다. 운송사 이름, 날짜 또는 고객 이름을 사용할 수 없다면 빈 필드를 표시하지 말고 테스트된 대체 문장을 사용하세요.

5. 중복되고 오래되었거나 오해를 불러일으키는 메시지 방지 장치 추가하기

자동화에는 이미 수행한 작업에 대한 기록이 필요합니다. 이벤트가 도착할 때마다 메시지를 보내기만 하는 워크플로는 재시도 후 알림을 반복하거나 새로운 주요 단계 이후 오래된 소식을 전달할 수 있습니다.

  • 중복 처리 방지: 가능한 경우 안정적인 이벤트 식별자를 사용하세요. 그렇지 않으면 배송, 이벤트 유형 및 이벤트 발생 시간과 같은 적절한 필드로 중복 제거 키를 정의하세요. 해당 알림이 이미 예약되었거나 발송되었는지도 별도로 기록하세요.
  • 상태 반복 억제: 동일한 고객 대상 상태로 매핑되는 여러 스캔이 자동으로 여러 메시지를 생성해서는 안 됩니다.
  • 발송 전 이벤트 관련성 확인: 보내기 전에 대기 중인 메시지를 다시 평가하세요. 배송 완료가 이후에 보고되었다면 오래된 배송 중 알림을 억제하세요.
  • 수정 사항을 신중하게 처리: 원래 이벤트 기록을 유지하고 명백한 상태 후퇴를 검토하세요. 나중에 도착한 모든 이벤트가 더 최신이거나 더 정확하다고 가정하지 마세요.
  • 안전하게 재시도: 발송 실패와 결과를 알 수 없는 상태를 구분하세요. 지원되는 경우 제공업체의 멱등성 기능을 사용하여 재시도로 인해 또 다른 메시지가 생성될 가능성을 줄이세요.
  • 수취인 매칭 보호: 검증되지 않은 운송장 번호 일치만을 근거로 배송을 고객과 연결하지 마세요.
  • 해결되지 않은 예외 에스컬레이션: 고객에게 동일한 경고를 반복해서 보내는 대신 운영 담당자를 지정하세요.

사용자 지정 통합의 경우 인증, 이벤트 승인 및 재시도에 대한 제공업체의 문서화된 방식을 따르세요. 불필요한 개인정보를 로그에 복사하지 않으면서 처리 로그를 유용하게 유지하세요. 추적 링크 역시 수취인에게 필요한 범위를 넘어 다른 고객의 주문이나 정보를 노출하지 않아야 합니다.

유용한 처리 순서는 이벤트 검증, 배송 식별, 상태 업데이트, 알림 적격성 확인, 허용된 채널 선택, 템플릿 렌더링, 메시지 대기열 등록 및 결과 기록입니다. 메시지가 대기열에서 기다리는 경우 발송 시 적격성을 다시 확인하세요.

6. 전체 여정을 테스트한 후 점진적으로 출시하기

테스트 이메일의 모양이 올바른지만으로 워크플로를 평가하지 마세요. 실패 사례를 포함하여 배송 이벤트부터 고객 목적지까지 전체 경로를 테스트하세요.

  • 정상 여정: 접수, 배송 중, 배송 출발 및 배송 완료가 의도한 메시지를 생성합니다.
  • 반복 이벤트: 동일한 이벤트를 다시 재생해도 또 다른 알림이 생성되지 않습니다.
  • 순서가 뒤바뀐 이벤트: 지연된 배송 중 스캔이 배송 완료 후 오래된 알림을 트리거하지 않습니다.
  • 분할 주문: 각 메시지가 올바른 배송을 식별하며 모든 상품이 도착한 것처럼 암시하지 않습니다.
  • 필드 누락: 이름, 운송사, 예상일 또는 상품 목록이 없어도 읽기 쉬운 대체 텍스트가 생성됩니다.
  • 연락 제한: 워크플로가 채널 환경설정, 억제 규칙 및 설정된 방해 금지 시간을 준수합니다.
  • 전달 실패: 잘못된 주소, 제공업체 오류 및 재시도가 통제되지 않은 재발송 없이 추적 가능한 결과를 생성합니다.
  • 고객 조치: 모든 추적 및 지원 링크가 모바일에서 의도한 목적지로 연결됩니다.

제한된 배송 그룹부터 시작하고 추적 기록과 함께 메시지 기록을 검토하세요. 지원 직원이 고객이 받은 내용을 확인할 수 있도록 하세요. 배송 추적 자체를 비활성화하지 않고도 잘못된 규칙을 중지할 수 있도록 일시 중지 기능을 유지하세요.

알림 적격성, 발송 시도, 제공업체 수락, 실패, 중복 및 이벤트 수신부터 메시지 발송까지의 지연 시간을 모니터링하세요. 제공업체의 수락은 고객이 메시지를 읽었다는 것을 의미하지 않으며, 열람률만으로 워크플로가 도움이 되었다고 판단할 수도 없습니다.

고객 영향을 평가하려면 일관된 정의와 비교 가능한 배송 그룹을 사용하여 배송 관련 문의율을 비교하세요. 변경 사항을 알림의 결과로 판단하기 전에 운송사 구성, 배송 문제 및 주문량의 변화를 고려하세요.

FAQ

라벨이 생성될 때 배송 확인을 보내야 하나요?

라벨 생성 업데이트를 보낼 수 있지만 정확하게 설명하세요. 배송 정보가 준비되었거나 배송이 준비 중이라고 말하세요. 운송사가 소포를 보관 중임을 확인하는 표현은 이를 뒷받침하는 이벤트가 있을 때만 사용하세요.

API 통합 없이도 배송 알림이 작동하나요?

예. 앱 기반 워크플로는 인터페이스를 통해 연결과 알림 규칙을 처리할 수 있습니다. 선택한 설정에서 이용 가능한 이벤트, 채널, 템플릿 제어 및 예외 처리를 확인하세요. 기존 시스템에 특수한 라우팅이나 의사 결정 로직이 필요한 경우에는 사용자 지정 통합이 더 적합합니다.

각 배송에는 몇 개의 알림을 보내야 하나요?

보편적으로 이상적인 개수는 없습니다. 구분되는 유용한 주요 단계와 실행 가능한 예외부터 시작하세요. 반복되는 배송 중 스캔은 억제하고, 고객에게 필요한 정보를 제공할 때만 메시지를 추가하세요.

추적 업데이트가 중단되면 어떻게 해야 하나요?

배송이 분실되었다고 단정하지 말고 서비스에 적합한 검토 규칙을 적용하세요. 마지막 이벤트, 가능한 경우 배송 예상일 및 관련 운영 프로세스를 확인하세요. 검증된 정보나 유용한 다음 단계를 추가할 때만 고객 업데이트를 보내세요.

배송 완료 알림으로 지원 사례를 자동 종료할 수 있나요?

배송 완료 스캔으로 사례를 업데이트할 수는 있지만, 고객의 미수령 신고를 자동으로 해결 처리해서는 안 됩니다. 운송사의 배송 상태와 고객의 문제를 별도의 기록으로 취급한 다음 조사 절차를 따르세요.

출처