Bigcommerce Kargo Entegrasyonları: Ücretler, Etiketler ve Takip için Seçenekler

BigCommerce gönderim entegrasyonları üç farklı işi yerine getirir: ödeme sırasında gönderim ücretlerini hesaplamak, sipariş karşılama için etiket satın almak ve gönderimden sonra paketleri takip etmek. Satıcılar için doğru kurulum, her şeyi vaat eden tek bir uygulama olmak zorunda değildir. Ödeme yöntemlerinin, depo işlemlerinin, gönderi kayıtlarının ve müşteri güncellemelerinin tutarlı kaldığı bağlantılı bir iş akışıdır.

Bugün gönderimin hangi bölümünde sorun yaşandığıyla başlayın. Beklenmeyen ödeme ücretleri, ücretlerin gözden geçirilmesini gerektirir. Yavaş paketleme ve gönderim, etiket iş akışının incelenmesini gerektirir. Eksik teslimat güncellemeleri ise daha iyi takip gerektirir. Bu sorunlar sipariş verilerini paylaşabilir, ancak birini çözmek diğerlerini otomatik olarak çözmez.

Her gönderim entegrasyonu gerçekte ne yapar?

Bir entegrasyon seçmeden önce müşteriye sunulan gönderim seçeneğini, onu yerine getirmek için gereken operasyonel çalışmadan ayırın. Ödeme sırasında alınan gönderim ücreti, daha sonra bir etiket için ödeyeceğiniz tutarla aynı olmak zorunda değildir ve takip numarası, taşıyıcının paketi teslim aldığına dair kanıt değildir.

Entegrasyon katmanı	Ana sorumluluk	Doğrulanması gerekenler
Ödeme ücretleri	Alışveriş yapanların hangi teslimat yöntemlerini ve ücretlerini göreceğini belirlemek.	Gönderim çıkış noktaları, varış noktaları, ürün verileri, hizmet uygunluğu ve geri dönüş davranışı.
Etiketler ve sipariş karşılama	Siparişleri gönderilere dönüştürmek ve gönderim için gereken belgeleri oluşturmak.	Taşıyıcı hesapları, paket seçimi, yazıcı uyumluluğu ve gönderi bilgilerinin geri yazılması.
Satın alma sonrası takip	Teslimat olaylarını toplamak ve gönderi ilerlemesini erişilebilir kılmak.	Takip numarası alma, taşıyıcı tanımlama, güncelleme iletimi ve istisna yönetimi.

BigCommerce’in resmî uygulama pazaryeri, paketlenmiş entegrasyonları bulmak için başlangıç noktasıdır. Geliştirici belgeleri, özel bir bağlantıyı doğrulamak için başlangıç noktasıdır. Yalnızca bir pazaryeri listesine bakarak bir uygulamanın kullandığınız her ülkeyi, taşıyıcı hizmetini, ödeme yapılandırmasını veya sipariş karşılama iş akışını desteklediği sonucuna varılmamalıdır.

Entegrasyon yolunu iş akışınıza göre seçin

Kurallar basitse platform gönderim ayarlarını kullanın

Gönderim teklifiniz basitse öncelikle mağazanızda zaten mevcut olan gönderim yapılandırmasını inceleyin. Başka bir sistem eklemeden önce hizmet verdiğiniz varış noktalarını, müşterilerin görmesi gereken yöntemleri ve bu yöntemlerin arkasındaki ticari kuralları tanımlayın.

Örneğin, standart yurt içi gönderim ücreti sunan bir mağazanın harici bir ücret motoru yerine daha net gönderim bölgelerine ve istisnalara ihtiyacı olabilir. Birden fazla konumdan büyük boyutlu ürünler gönderen bir mağazanın sorunu ise farklıdır: basit bir ücret, sipariş karşılama maliyetindeki önemli farklılıkları gizleyebilir.

En uygun olduğu durum: Öngörülebilir paketlere, sınırlı sipariş karşılama karmaşıklığına ve mevcut yapılandırmalarının ifade edebildiği gönderim kurallarına sahip satıcılar. Gerekli mantık güvenilir biçimde ifade edilemiyorsa bu yöntemin ötesine geçin; yalnızca başka bir uygulamanın daha fazla ayarı var diye değil.

Tekrarlanabilir sipariş karşılama işleri için paketlenmiş bir entegrasyon kullanın

Çalışanlar adresleri tekrar tekrar kopyalıyor, hizmetleri seçiyor, etiket satın alıyor veya takip numaralarını giriyorsa paketlenmiş bir gönderim entegrasyonu değerlendirilmeye değerdir. Değeri, el değiştirmeleri azaltmasından ve sipariş kaydını gerçekten gönderilenlerle uyumlu tutmasından gelir.

Her etiket entegrasyonunun ödeme ücretlerini de sağladığını varsaymayın. Aynı şekilde, siparişleri içe aktaran bir uygulamanın gönderi ayrıntılarını BigCommerce’e geri yazabildiğini varsaymayın. Sağlayıcıdan, iş akışınızı kullanarak gereken her veri hareketi yönünü göstermesini isteyin.

En uygun olduğu durum: Kendi entegrasyonlarını sürdürmeden yerleşik bir operasyon arayüzü isteyen ekipler. Temel depo kuralları, zaman tasarrufunu ortadan kaldıran manuel çözümler gerektiriyorsa uygun değildir.

Başka bir sistem sipariş karşılamayı yönetiyorsa özel bağlantı kullanın

Sipariş yönetim sistemi, depo platformu veya üçüncü taraf lojistik sağlayıcısı gönderimi zaten kontrol ediyorsa özel entegrasyon anlamlı olabilir. Bu düzenlemede BigCommerce, her gönderim işlemi için operasyonel gerçeklik kaynağı olmaktan ziyade satış kanalı olabilir.

Adreslerin, paket kararlarının, etiket satın alımlarının, gönderi oluşturmanın ve takip güncellemelerinin hangi sisteme ait olduğunu belirleyin. Ardından ilgili belgelerde gerekli API işlemlerini, kimlik doğrulama gereksinimlerini, izinleri ve platform kısıtlamalarını doğrulayın.

En uygun olduğu durum: Gerçek bir iş akışı gereksinimi ve bunu sürdürebilecek teknik kapasiteye sahip satıcılar. İzleme, destek ve gelecekteki değişiklikler hesaba katıldığında özel geliştirme otomatik olarak en ucuz yol değildir.

Ücretler: ödeme sırasındaki vaadi gönderim operasyonuyla eşleştirin

Bir ücret entegrasyonu yalnızca bir sayı döndürmemeli, yerine getirebileceğiniz bir teslimat seçeneği sunmalıdır. Sağlayıcıları test etmeden önce hizmet uygunluğunu ve maliyeti belirleyen çıkış noktası, varış noktası, ürün ve paketleme girdilerini belgeleyin.

• Çıkış noktaları: Siparişi hangi depo veya sipariş karşılama ortağı gönderecek?
• Ürün verileri: Ağırlıklar ve boyutlar doğru mu, birimleri tutarlı mı?
• Paketleme: Hesaplama tek tek ürünleri, seçilmiş bir koliyi veya tahmini bir paketi mi kullanıyor?
• Varış noktaları: Uzak bölgeler, posta kutuları ve hizmet alanınız dışındaki konumlar için ne oluyor?
• Ticari kurallar: Hesaplanan tutarı mı alacaksınız, gönderimi sübvanse mi edeceksiniz veya promosyon eşiği mi uygulayacaksınız?

Ödeme ücretleri ile etiket maliyetleri farklı olabilir; çünkü sipariş karşılama sırasında kullanılan paket, hizmet, çıkış noktası veya hesap, ödeme sırasındaki varsayımlardan farklı olabilir. Ücret hesaplamasının yanlış olduğu sonucuna varmadan önce test siparişinin her iki tarafını karşılaştırın.

Hata davranışını da belirleyin. Bir ücret isteği başarısız olursa ödeme sayfası yapılandırılmış bir alternatifi mi göstermeli, etkilenen yöntemi mi kaldırmalı veya siparişi durdurmalı? Uygun seçim, ekibinizin alternatifi yerine getirip getiremeyeceğine bağlıdır. Gönderilemeyecek bir siparişi kabul eden yedek ücret başarılı bir kurtarma değildir.

Uluslararası siparişlerde taşıma ücretini gümrük vergileri ve vergilerden ayırın. Sorumlu hizmet ilgili ücretleri açıkça hesaplamıyor ve sipariş karşılama süreci belirtilen ödeme düzenlemesini desteklemiyorsa bir ücreti tüm masraflar dahil teslim maliyeti olarak tanımlamayın.

Etiketler: tüm gönderim döngüsünü değerlendirin

Etiket satın alma, yalnızca ilk başarılı yazdırma işlemine kadar değil, siparişin içe aktarılmasından iptale kadar test edilmelidir. Operasyonel soru, entegrasyonun depo çalışmalarını ve mağaza kayıtlarını senkronize tutup tutmadığıdır.

Şu kabul kontrollerini kullanın:

1. Sipariş içe aktarma: Doğru siparişlerin sipariş karşılama için kullanılabilir olduğunu ve düzenlemelerin öngörülebilir biçimde işlendiğini doğrulayın.
2. Paket oluşturma: Tek paket, birden fazla paket ve yalnızca bazı ürünleri gönderilen bir siparişi test edin.
3. Hizmet seçimi: Müşterinin ödeme sırasında seçtiği yöntemin depo çalışanlarının satın aldığı hizmetle nasıl eşleştiğini kontrol edin.
4. Yazdırma: Etiket boyutunun, dosya biçiminin ve yazdırma ayarlarının gerçek depo ekipmanıyla çalıştığını doğrulayın.
5. Gönderi bilgilerinin geri yazılması: Doğru takip bilgilerinin ve gönderilen ürünlerin BigCommerce siparişine ulaştığını doğrulayın.
6. Yeniden yazdırma ve geçersiz kılma: Çalışanların yinelenen satın alımları nasıl önleyeceğini ve kullanılmayan etiketlerin geçerli sağlayıcı kuralları kapsamında nasıl ele alınacağını belirleyin.

Özellikle yararlı bir test, etiket satın alımının başarılı olduğu ancak sonraki sipariş güncellemesinin başarısız olduğu durumdur. Çalışanların başka bir etiket satın almadan siparişi güncellemesini sağlayacak bir kurtarma yolu olmalıdır. İşte iyi hazırlanmış bir tanıtım ile güvenilir bir üretim iş akışı arasındaki fark burada ortaya çıkabilir.

Müşteri bildirimlerinin kime ait olduğunu da kontrol edin. Hem bir gönderim entegrasyonu hem de bağlı başka bir sistem gönderim mesajları gönderiyorsa müşteriler yinelenen veya çelişkili güncellemeler alabilir.

Takip: gönderi kayıtlarını teslimat görünürlüğünden ayırın

Bir siparişe takip numarası yazmak kayıt tutma sorununu çözer. Daha sonraki taşıyıcı olaylarını toplamak ise görünürlük sorununu çözer. İşletmenizin her ikisine de ihtiyacı olabilir, ancak bunlar ayrı ayrı değerlendirilmelidir.

Yararlı bir takip iş akışı; sipariş, gönderi, paket, taşıyıcı ve takip numarası arasındaki ilişkiyi korur. Bir siparişte birden fazla paket olduğunda veya bir paket birden fazla teslimat operatöründen geçtiğinde bu ilişki önemlidir.

Geliştirici odaklı bir takip katmanı için 17TRACK Tracking API değerlendirilebilecek uygun bir seçenektir. resmî API belgeleri, özel bir iş akışında takip kaydı ve olay iletimini değerlendirmek için temel sağlar. Bu bir takip kullanım alanıdır; ödeme ücreti hesaplama veya etiket satın alma yerine geçmez.

API kullanılabilirliğinin kullanıma hazır bir BigCommerce bağlantısının dahil olduğu anlamına geldiğini varsaymayın. Gönderi ayrıntılarının mağazanızdan veya sipariş karşılama sisteminizden takip hizmetine nasıl aktarılacağını, güncellemelerin hedeflerine nasıl ulaşacağını ve bağlantıyı kimin sürdüreceğini belirleyin.

Uygulamadan önce gerçek taşıyıcılarınız ve hizmetleriniz için desteği, ilgili abonelik koşullarını ve güncelleme iletim yapılandırmasını doğrulayın. Ardından gecikmiş taramaları, tanınmayan numaraları, yinelenen güncellemeleri ve teslimat istisnalarını test edin. Bir takip entegrasyonu, gerçekleşmemiş fiziksel bir taşıyıcı taraması oluşturamaz.

İşletme içinde bir takip sorumlusu da seçin. Takılı kalan gönderileri araştırmaktan ve taşıyıcıyla veya müşteriyle ne zaman iletişime geçileceğine karar vermekten biri sorumlu olmadıkça istisna panosunun operasyonel değeri sınırlıdır.

Toplam maliyeti başlık fiyatlarına güvenmeden karşılaştırın

Bu entegrasyon katmanları farklı işler yaptığı için maliyetleri tek bir reklamı yapılan abonelik tutarına göre değil, ihtiyaç duyduğunuz iş akışına göre karşılaştırın.

• Yazılım ücretleri: Abonelikleri, kullanım limitlerini, aşım ücretlerini ve ayrı faturalandırılan özellikleri belirleyin.
• Gönderim ücretleri: Posta ücretlerini ve taşıyıcı düzenlemelerini yazılım ücretinden ayırın.
• Uygulama: Kurulumu, veri temizliğini, hizmet eşleştirmesini, testleri ve personel eğitimini dahil edin.
• Süregelen operasyonlar: Manuel düzeltmeleri, başarısız senkronizasyonları ve destek sorumluluğunu hesaba katın.
• Çıkış gereksinimleri: Açık siparişleri aksatmadan gönderi kayıtlarını nasıl alabileceğinizi ve bağlantıyı nasıl kaldırabileceğinizi kontrol edin.

Her sağlayıcıdan hangi olayın faturalandırılabilir kullanıma dahil olduğunu açıklamasını isteyin. Siparişler, etiketler, paketler, kaydedilmiş takip numaraları ve API istekleri birbirinin yerine kullanılabilecek birimler değildir. Maliyeti tahmin ederken kendi operasyonunuzdan temsilî bir dönemi kullanın.

Geçiş yapmadan önce küçük bir uçtan uca pilot çalıştırın

En güçlü seçim yöntemi, gerçekçi siparişlerle kontrollü bir pilot uygulamadır. Sıradan bir yurt içi paketi, çok ürünlü bir siparişi, bölünmüş bir gönderiyi ve işletmeniz için önemli olan uluslararası veya alışılmadık gönderi türlerini dahil edin.

Her test için ödeme teklifini, seçilen hizmeti, etiket sonucunu, gönderi kaydını, takip hedefini ve müşteri bildirimlerini kaydedin. Reddedilen bir adres veya kesintiye uğramış senkronizasyon gibi en az bir hata durumu ekleyin.

Sorumluluğu net biçimde dağıtın: e-ticaret ekibi ödeme davranışını, depo çalışanları paketleme ve yazdırmayı, müşteri desteği gönderi görünürlüğünü, teknik sorumlu ise izinleri ve kurtarma prosedürlerini onaylasın. Her bağlantının hangi müşteri verilerini aldığını inceleyin ve yalnızca işi için gereken erişimi verin.

Pratik öneri: Kurulumu operasyonunuzun izin verdiği ölçüde basit tutun. Gereksinimi karşıladığı yerde mevcut gönderim yapılandırmasını kullanın, tekrarlayan işleri ortadan kaldırdığı yerde bir sipariş karşılama entegrasyonu ekleyin ve gönderi görünürlüğünün kendi iş akışına ihtiyaç duyduğu durumda özel bir takip katmanı ekleyin. Varsayılan olarak örtüşen yetenekleri satın almak yerine katmanları bilinçli biçimde birbirine bağlayın.

SSS

Ücretler, etiketler ve takip için ayrı entegrasyonlara ihtiyacım var mı?

Şart değil. Bir entegrasyon birden fazla işlevi kapsayabilirken diğeri yalnızca birini yerine getirebilir. Siparişleri okuyup okumadığı, gönderi bilgilerini geri yazıp yazmadığı ve daha sonraki takip güncellemelerini iletip iletmediği dahil olmak üzere gereken her işlevi ayrı ayrı doğrulayın.

Bir etiket entegrasyonu ödeme sırasındaki gönderim ücretlerini otomatik olarak değiştirir mi?

Bunu varsaymayın. Etiket satın alma sipariş karşılama sırasında gerçekleşirken ödeme ücretleri sipariş verilmeden önce sunulur. Entegrasyonun ödeme ücreti işlevi sağlayıp sağlamadığını ve mağazanızın yapılandırmasıyla çalışıp çalışmadığını doğrulayın.

Kendi taşıyıcı hesaplarımı bağlayabilir miyim?

Bu durum entegrasyona, taşıyıcıya, hesap uygunluğuna ve gönderim bölgesine bağlıdır. Hangi hesapların ve hizmetlerin desteklendiğini, hesap ücretlerinizin kullanılıp kullanılamayacağını ve posta ücretleri ile sonraki düzenlemeleri kimin faturalandırdığını sorun.

17TRACK, BigCommerce etiket aracının yerini alabilir mi?

Tracking API, etiket satın almanın yerine geçecek bir araç olarak değil, takip görünürlüğü için değerlendirilmelidir. Özel bir iş akışı, ödeme hesaplamalarını ve etiket oluşturmayı bu görevlerden sorumlu sistemlerde bırakırken gönderi bilgilerini bir takip hizmetine bağlayabilir.

Bir müşteri takip numarasını aldıktan sonra neden hiçbir hareket göremeyebilir?

Bir takip numarası, paket ilk taşıyıcı taramasını almadan önce mevcut olabilir. Diğer olasılıklar arasında yanlış numara, taşıyıcı tanımlama sorunu veya olayların gecikmeli kullanılabilir olması bulunur. Güncellemelerin yokluğunu bir yazılım hatası olarak değerlendirmeden önce sipariş karşılama aktarımını ve taşıyıcı bilgilerini kontrol edin.

Kaynaklar

• BigCommerce Uygulama Pazaryeri — paketlenmiş entegrasyonları belirlemek ve tek tek listeleri kontrol etmek için resmî başlangıç noktası.
• BigCommerce Geliştirici Belgeleri — platform entegrasyonu gereksinimlerini ve API uygulama ayrıntılarını doğrulamak için resmî kaynak.
• 17TRACK Tracking API — bu kılavuzda ele alınan takip API’si seçeneği için resmî ürün kaynağı.
• 17TRACK API Belgeleri — özel bir takip iş akışını değerlendirmek için teknik kaynak.