마켓플레이스 다섯 곳에 리스팅할 때 과다 판매를 막는 방법

과다 판매란 하나뿐인 켤레에 대해 두 마켓플레이스에서 주문을 받는 것입니다. 사소한 관리 실수가 아닙니다. 취소가 불가피해지고, 취소에는 무거운 불이익이 따릅니다. 판매자 평점 하락, 수수료나 페널티, 일부 플랫폼에서는 정산 일시 보류까지 있습니다. 몇 번 반복되면 의존하는 플랫폼에서 계정 등급이 떨어집니다.

과다 판매는 장사가 잘될수록 늘어납니다. 넓게 리스팅하고 재고가 빨리 돌수록, 두 구매자가 몇 분 간격으로 같은 재고를 사는 일이 잦아집니다. 수동으로 판매하는 사람에게 문제는 속도가 아니라 구조입니다.

본능적인 해법은 더 빨라지는 것입니다. 탭을 새로 고치고, 무언가 팔리는 순간 다른 리스팅을 지웁니다. 이 방법은 같은 분에 판매 두 건이 들어오거나, 잠들어 있거나, 발매일에 주문 스무 건을 한꺼번에 확인해야 할 때까지만 통합니다.

초 단위로 갈리는 경주는 탭을 지켜봐서는 이길 수 없습니다. 연결된 재고와 지원되는 자동 정리가 위험을 줄입니다. 마켓플레이스 반영 시점 때문에 대조 작업은 여전히 필요합니다.

과다 판매 방지는 재고를 어떻게 모델링하느냐에서 시작합니다. RestocksAIO는 대부분의 스프레드시트가 뒤섞는 두 가지를 분리합니다:

• 재고: 보유한 실물 한 단위당 한 행이며 원가, 사이즈, 상태, 박스 구성, SKU가 들어갑니다. 이것이 기준 데이터입니다.
• 리스팅: 각 마켓플레이스의 활성 리스팅 하나당 한 행입니다. 여러 리스팅이 하나의 재고 단위에 연결됩니다.

모든 리스팅은 특정한 보유 재고 단위에 묶여 있습니다. 그래서 시스템은 StockX 리스팅, WeTheNew 리스팅, Alias 리스팅이 세 켤레가 아니라 같은 한 켤레라는 것을 늘 압니다.

자동 삭제는 리스팅들이 같은 켤레에 속한다는 것을 알기 때문에 작동합니다. 그 연결은 Controller가 관리합니다. Bricker는 가격 책정과 수명 주기를 두 단위로 구성합니다. Task는 한 상품에 대해 한 플랫폼을 자동화합니다. Controller는 같은 SKU와 사이즈의 Task를 묶습니다. Controller가 "이 다섯 리스팅은 한 단위"라고 알려 주기 때문에, 판매가 감지된 뒤 나머지 네 리스팅의 삭제를 요청할 수 있습니다.

카테고리끼리 충돌하는 것도 막습니다. 같은 켤레에 대해 Resale, Direct(StockX Buyer-Direct), Consign / Flex가 각자의 가격 책정과 수명 주기를 가진 별도의 Controller로 운영됩니다. 그래서 Resale 판매를 확인해도 Consign 리스팅이 잘못 내려가지 않습니다. 이 모델에서는 과다 판매를 피하는 일이 경주에서 이기는 능력에 덜 좌우됩니다. 시스템은 보유 재고 한 단위, Controller 하나, 그리고 함께 오르내리고 함께 사라지는 여러 개의 연결된 Task를 관리합니다. 연결된 재고 덕분에 지원되는 자동 정리가 가능하지만, 업데이트가 지연될 때는 여전히 판매와 리스팅 상태를 확인해야 합니다.

이 모델은 바쁠 때 가장 큰 도움이 됩니다. 발매일에는 몇 분 안에 주문 스무 건을 확인할 수도 있습니다. 실행 중인 자동화가 대상 판매를 감지하면, 지원되는 연결 경로에서 감지된 판매마다 정리 요청이 뒤따릅니다. 수동 판매로는 이 속도를 따라갈 수 없습니다. Controller 단위로 작동하는 구조는 판매가 한꺼번에 몇 건 들어오든 영향을 받지 않습니다.

도구를 거치지 않은 판매도 처리합니다. RestocksAIO가 실행하지 않은 곳에서 켤레가 팔리면 Sync Data에 사라진 리스팅이 표시됩니다. 행의 체크박스로 판매 완료 처리하면 Controller가 대조되고, 남아 있던 다른 리스팅이 두 번째 주문을 받는 것을 막습니다. 현실이 도구보다 앞서 나가도 대조 한 번이면 재고 단위가 일관된 상태로 돌아옵니다.

결국 과다 판매의 해답은 더 빨리 일하는 데가 아니라 데이터를 구성하는 방식에 있습니다. 판매 후 연결된 리스팅을 대조할 수 있도록 데이터를 구성하세요.

판매 처리 자동화가 판매를 감지하면, 지원되는 마켓플레이스에서 연결된 다른 리스팅의 삭제를 요청할 수 있습니다. 작업이 실행 중이어야 하고, 리스팅이 올바르게 연결되어 있어야 하며, 연결된 각 계정이 해당 작업을 허용해야 합니다. 마켓플레이스 응답이나 판매 감지가 지연되면 다른 주문이 들어올 틈이 생길 수 있으므로, 자동화는 과다 판매를 완전히 없애 주는 것이 아니라 이중 판매 위험을 줄여 줍니다.

바쁜 발매 이후나 수동으로 변경한 뒤에는 판매와 다른 리스팅의 상태를 확인하세요. Sync Data를 정기적으로 실행하고, 필요하면 Shift-클릭으로 전체 새로 고침을 하고, 사라진 리스팅은 판매 완료 또는 삭제로 대조하세요. 스니커 크로스리스팅 작업 흐름에서 지원 채널과 계정별 한계를 설명합니다.

과다 판매와 관련된 문제가 하나 더 있습니다. 성사되어야 했던 판매가 확인이 늦어 구매자가 떠나면서 무산되는 경우입니다. 특히 Alias에서는 판매자가 확인하기 전까지 구매자가 취소할 수 있으므로, 미확인 상태로 있는 동안 주문은 언제든 사라질 수 있습니다. 취소된 판매는 이미 팔린 것으로 계산한 재고를 다시 떠안게 만들어 기록을 또 어긋나게 합니다.

Confirm Sales는 두 문제를 모두 해결합니다. Load Unconfirmed는 연결된 모든 플랫폼의 대기 주문을 한 화면으로 불러오므로 대시보드를 오갈 필요가 없습니다. Auto-Confirm은 활성화한 사이트의 주문을 오 분마다 자동으로 수락합니다. 빠른 확인은 판매를 지켜 줍니다. 자동 삭제도 더 빨리 실행되므로, 지원되는 다른 리스팅의 정리도 더 빨리 요청됩니다.

지원되는 자동 정리는 실시간 판매 위험을 줄여 줍니다. 과다 판매를 피하는 나머지 절반은 시간이 지나도 재고와 리스팅을 일치시키는 것입니다. RestocksAIO가 실행하지 않은 플랫폼에서 리스팅이 팔리거나, 수동 수정이 누락되면 둘이 어긋납니다.

두 가지 습관으로 그 틈을 막을 수 있습니다. 첫째, Sync Data를 정기적으로 실행하세요. 증분 동기화는 새 리스팅과 사라진 리스팅을 불러오고, Shift-클릭은 처음부터 전체 새로 고침을 합니다. 둘째, 리스팅이 사라지면 행의 체크박스로 판매 완료 또는 삭제 처리해 재고 화면과 리스팅 화면을 일치시키세요. 어차피 한 판매처에서 가장 많이 남는 SKU라면 Price Comparator로 한 플랫폼에만 보내 중복 위험을 아예 피할 수 있습니다.

eBay와 자체 Shopify 스토어는 켤레마다 리스팅 하나가 아니라 수량으로 작동합니다. RestocksAIO에서 그 수량은 오퍼에 연결한 Inventory 단위 수와 같습니다. 연결된 단위가 StockX나 Alias에서 팔리면 앱이 eBay와 Shopify 수량을 줄입니다. 0이 되면 리스팅이 종료되거나 철회됩니다.

두 가지 한계가 있습니다. 앱이 열려 있어야 합니다. 그리고 Shopify나 eBay의 판매는 다음 조회 때에야 확인됩니다. Shopify는 약 10분마다, eBay는 약 15분마다 조회합니다. 그 사이에 두 구매자가 모두 결제할 수 있습니다. 그러면 두 번째 판매는 Review 받은편지함에서 판매자의 결정을 기다립니다. Marketplace tab 페이지에서 연결 방식을 확인하세요.

스토어 판매는 리셀 쪽도 정리합니다. eBay나 Shopify 주문이 들어오면 해당 켤레의 각 Bricker Mode 작업이 StockX, Alias 및 기타 리셀 마켓플레이스의 리스팅을 삭제합니다. Bricker 작업이 없는 리스팅은 그대로 유지되고 Review에 표시됩니다. 단, Also delete listings without a Bricker task를 켜면 삭제됩니다. 위탁 판매 및 Flex 리스팅은 절대 삭제되지 않습니다. 판매된 켤레와 일치하는 리스팅이 여러 개이고 그중 어느 것도 연결되어 있지 않으면, 앱은 아무것도 삭제하지 않고 Review에서 판매자에게 묻습니다.

안전장치는 작동하는 모습을 볼 수 있어야 더 믿을 수 있습니다. 이벤트별 Discord 웹훅은 판매가 들어오고 다른 리스팅이 삭제되는 순간 바로 발송되므로, 실시간으로 작동 과정을 지켜볼 수 있습니다. 삭제가 실패하면(네트워크 끊김, 플랫폼 오류 등) 이벤트로 표시됩니다. 두 번째 주문이 들어온 뒤에야 알게 되는 일이 없습니다.

양방향 Telegram 봇은 같은 이벤트를 휴대폰으로 보내고, 바로 대응할 수 있게 해 줍니다. 바쁜 발매일에도 무엇이 팔리는지 보고 어디서든 개입할 수 있습니다. 시스템이 정리를 요청하고, 알림이 무슨 일이 있었는지 보여 줍니다. 이중 판매를 잡으려고 탭을 지켜볼 필요가 없습니다. 연결된 리스팅이 삭제될 때와 삭제가 실패할 때 알림을 받습니다.

모든 마켓플레이스 리스팅을 해당 실물 재고 단위에 연결하세요. 지원되는 곳에서는 판매 처리 작업을 활성 상태로 두고, 정리 결과를 확인하고, Sync Data를 실행해 외부 변경이나 지연된 변경을 대조하세요. 이렇게 하면 이중 판매 위험이 줄어들지만, 마켓플레이스에서 동시에 들어오는 주문을 불가능하게 만들 수는 없습니다.

채널을 하나 더 추가하기 전에 스니커 재고 관리 작업 흐름에서 재고 연결, 휴대폰에서 데스크톱으로 입고, 대조 방법을 확인하세요.