마이그레이션 중 CS 조회·배송·반품 연결

플랫폼을 전환해도 이전 주문에 대한 문의는 계속 들어옵니다. 새 주문은 글로벌 플랫폼에서 처리하고 과거 주문은 기존 시스템에 남아 있다면, CS에서는 고객의 주문이 어디에 있는지부터 확인해야 합니다.

배송 확인과 반품 처리도 그 주문을 기준으로 이어집니다. 그래서 조회 화면만 준비하는 것으로 끝내지 않고 주문 출처와 배송 갱신, 환불 경로를 함께 살펴봤습니다.

주문 출처와 상담 정보

같은 고객의 주문이 두 시스템에 나뉠 수 있었습니다. 고객이 주문 시점을 정확히 알고 문의한다는 전제로 도구를 만들 수는 없었습니다.

CS에서 필요한 정보도 고객용 주문 목록과는 달랐습니다. 주문 상태뿐 아니라 결제 상세와 배송 추적, 운영 메모 등을 확인해야 했습니다. 하나의 화면에서 합쳐 보여줄지, 연결된 도구로 이동할지는 구현 범위를 정할 때 함께 볼 사항이었습니다.

기존 주문의 배송 상태

전환 전에 배송이 시작된 주문은 기존 시스템의 상태 갱신 경로가 남아 있었습니다. 신규 주문의 배송 경로만 연결하면 이전 주문의 배송이 멈춘 것처럼 보일 수 있습니다.

물류 상태를 어느 시스템에 갱신할지와 CS에서 그 정보를 어떻게 조회할지를 함께 맞춰야 했습니다. 고객에게 보이는 주문 상태와 상담원이 확인하는 상태가 서로 다른 시점에 머물지 않도록 보는 작업입니다.

결제 경로에 따른 반품 처리

반품에서는 원래 주문이 어느 결제 경로에서 처리됐는지 확인해야 했습니다. 기존 시스템에서 결제한 주문은 그 시스템의 환불 처리가 필요한 경우가 있어, 신규 주문을 전환했다고 기존 결제 연동을 즉시 없앨 수는 없었습니다.

기존 결제 연동을 중단할 시점은 반품 가능 기간뿐 아니라 진행 중인 배송과 반품, 후속 정산 상태까지 함께 보고 정해야 합니다.

연결해서 확인할 순서

각 기능은 다른 시스템에서 구현할 수 있지만, 상담 흐름에서는 이어져야 합니다. 조회가 가능해도 배송을 설명할 수 없거나 환불 처리를 찾을 수 없다면 CS에서 해야 할 일이 남습니다.

다음 글에서는 주문 이관 배치와 검증을 다룹니다.