Pazaryeri Sipariş Adresi: Kanalları Tek Formatta Toplamak

Bir e-ticaret işletmesine aynı gün içinde web sitesinden, mobil uygulamadan, bir ya da birkaç pazaryerinden ve çağrı merkezinden sipariş gelir. Ürün ve ödeme bilgisi bu kanallarda birbirine benzer şekilde taşınır. Adres ise genellikle her kanalda farklı bir kalıpla gelir. Pazaryeri sipariş adresi bir yapıda gelir, web formundan gelen adres başka bir yapıda gelir, telefonla alınan adres de operatörün yazdığı serbest metin olarak sisteme kaydedilir. Bu yazıda farklı kanallardan gelen adresleri tek bir modelde toplamanın neden önemli olduğu, depo ve kargo süreçlerine nasıl yansıdığı ve bu dönüşümün işleri durdurmadan nasıl kademeli olarak yapılabileceği ele alınıyor.

Kanal başına farklı adres formatları

Her satış kanalı adresi kendi ihtiyacına göre toplar. Tek tek bakıldığında her biri makul görünür. Sorun, bu adreslerin depoda, kargo etiketinde ve müşteri kayıtlarında bir araya geldiği anda başlar.

Basit bir senaryo düşünün. Aynı müşteri bir ay içinde üç farklı kanaldan sipariş veriyor. Sisteminizde şu üç kayıt oluşuyor:

• Caferağa Mah. Moda Cad. No:12 Kadıköy
• CAFERAGA MH MODA CD 12 KADIKOY
• moda caddesi 12 caferağa

Üç kayıt da aynı kapıyı tarif ediyor. Ancak sistem bunları üç ayrı adres olarak, kimi zaman da üç ayrı müşteri olarak görür. Çok kanallı satış yapan bir işletmede bu durum yalnız kargo hatalarına yol açmaz. Müşteri tekilleştirme, bölge bazlı satış raporları, kampanya hedefleme ve depo planlaması da aynı dağınık veri üzerine kurulmuş olur.

Tek bir adres modeli: ortak bir dil kurmak

Çözüm her kanalı aynı ekrana zorlamak değildir. Kanallar adresi farklı yollarla toplamaya devam edebilir. Önemli olan, depoya, kargoya ve CRM'e giden kaydın her zaman aynı biçimde olmasıdır. Bu ortak biçime adres modeli denebilir.

Pratik bir adres modeli şu alanları içerir:

Bu modeli kurarken dört ilkeye dikkat edin:

1. Ham metni silmeyin. Standart hâli ayrı alanlarda tutun, orijinal metni de saklayın. Müşteri itirazlarında, pazaryeriyle mutabakatta ve hatalı eşleşmeleri geriye dönük incelerken bu metne ihtiyaç duyarsınız.
2. Adla değil, kimlikle eşleştirin. Aynı mahalle adı farklı yerleşimlerde bulunabilir. Kayıtları adlarına göre birleştirmek yanlış eşleşmelere yol açar. API Türkiye'deki her kayıt sürümden bağımsız bir stableId taşır ve entegrasyonların referans olarak bu değeri saklaması önerilir.
3. Serbest alanları yapısal alanlardan ayırın. "Apartman yönetimine bırakın" gibi bir not, sokak alanına yazılmamalıdır.
4. Durumu görünür kılın. Bir adresin doğrulanıp doğrulanmadığı depo ve müşteri hizmetleri ekranlarında açıkça görünmelidir.

Depo ve kargo süreçlerine etkisi

Adres standartlaştırma en somut karşılığını depoda ve sevkiyatta verir. Adres verisi tek modelde toplandığında süreçlerde şu değişiklikler olur:

• Sorunlu adresler sevkiyattan önce ayrılır. Doğrulanamayan adresli siparişler toplama listesine girmeden ayrı bir kuyruğa düşer. Müşteri hizmetleri alıcıyla iletişime geçer, paket ancak adres netleştikten sonra hazırlanır. Böylece sorun kargo yola çıktıktan sonra değil, çıkmadan önce yakalanır.
• Etiket tek şablondan basılır. Hangi kanaldan gelirse gelsin etiket aynı alan sırasıyla basılır. Depo personeli ve kargo çalışanı her pakette aynı düzeni görür.
• Bölge gruplaması kolaylaşır. Siparişler ilçe ve mahalle kimliğine göre gruplanabilir. "Kadıköy" ile "KADIKOY" yazımlarının aynı yer olup olmadığını tahmin eden kurallar yazmanız gerekmez.
• Teslim edilemeyen gönderiler analiz edilebilir. Dönen paketleri kanala ve hata türüne göre ayırabilirsiniz. Örneğin sorunun belirli bir pazaryerinden gelen siparişlerde mi, yoksa telefon siparişlerinde mi yoğunlaştığını görebilirsiniz.
• Müşteri hizmetleri aynı kaydı görür. Temsilci, siparişin hangi kanaldan geldiğinden bağımsız olarak aynı biçimdeki adresle çalışır.

Lojistik tarafındaki etkileri daha ayrıntılı incelemek isterseniz lojistikte adres yönetimi ve standart verinin faydaları yazısına göz atabilirsiniz.

Pazaryeri sipariş adresi nasıl standartlaştırılır?

Kanalları iki gruba ayırmak işi kolaylaştırır.

Kendi kontrolünüzdeki kanallar (web, mobil, çağrı merkezi): Burada adres, giriş anında yapısal olarak alınabilir. Müşteri ya da operatör il, ilçe ve mahalleyi listeden seçer, sokak adını yazarken öneriler görür. API Türkiye'nin akıllı adres araması yazım hatalarına ve Türkçe karakter farklarına toleranslıdır. "Bagdat cadessi" yazan bir operatör, doğru sokak önerisini görebilir. Kapı numarası ise seçilen sokağın dış kapı listesinden aranır. Çağrı merkezinde serbest metin girişini bu seçimli ekranla değiştirmek, telefon kanalındaki hataların önemli bir kaynağını ortadan kaldırır.

Dış kanallar (pazaryerleri): Adres size hazır gelir, girişi değiştiremezsiniz. Bu nedenle standartlaştırma, sipariş içe aktarılırken yapılır. Adres doğrulama ucu (Pro ve üzeri paketlerde) il, ilçe, mahalle, cadde/sokak ve dış kapı numarasını ayrı alanlar olarak alır ve katalogda kontrol eder. Teknik ekibinize iletebileceğiniz örnek bir istek şöyledir:

curl "https://api.apiturkiye.com/v1/addresses/validate" \
  -H "X-API-Key: apt_live_..." \
  -H "Content-Type: application/json" \
  --data '{"province":"İstanbul","district":"Kadıköy","neighborhood":"Caferağa Mahallesi","street":"Moda Caddesi","doorNumber":"12"}'

Operasyon açısından yanıtın iki sonucu vardır:

• Eşleşme var (valid: true): Standart adres metni ve her bileşenin kalıcı kimliği döner. Bu bilgiler adres modelinize yazılır ve sipariş normal akışına devam eder.
• Eşleşme yok ya da belirsiz (valid: false): Yanıt, sorunun hangi seviyede olduğunu (failedAt, örneğin mahalle ya da sokak) ve varsa aynı kapsamdaki adayları gösterir. Bu siparişler istisna kuyruğuna alınır. Önerileri bir kişinin onaylaması, sistemin sessizce uygulamasından daha güvenlidir.

Burada önemli bir ayrıntı var. Doğrulama ucu bileşenleri ayrı ayrı bekler. Pazaryerinden mahalle, sokak ve kapı numarası tek satırda geliyorsa, bu metni bileşenlere ayırmak sizin tarafınızda ayrı bir iş adımıdır. Güvenle ayrıştırılamayan kayıtları tahminle doldurmak yerine doğrudan kuyruğa almak daha sağlıklıdır. API anahtarı yalnız sunucu tarafında kullanılmalı, tarayıcı veya mobil uygulama koduna konmamalıdır. Teknik ekibinizin entegrasyon ayrıntıları için siparişten önce adres doğrulama entegrasyonu yazısı iyi bir başlangıçtır.

Kademeli geçiş planı

Bütün kanalları aynı gün yeni modele geçirmek risklidir. Aşağıdaki sıra, işi durdurmadan ilerlemenizi sağlar:

1. Envanter çıkarın. Her kanaldan örnek siparişler toplayın, adres alanlarını ve sık görülen hata türlerini listeleyin. Hangi kanalın en çok düzeltme gerektirdiğini belirleyin.
2. Ortak modeli tanımlayın. Alanları, zorunlulukları ve doğrulama durumlarını operasyon, CRM ve teknik ekiplerle birlikte netleştirin. Ham metnin saklanacağını baştan karar altına alın.
3. Gözlem modunda başlayın. Yeni siparişleri doğrulayın, ancak sonucu akışı durdurmak için kullanmayın, yalnız raporlayın. Bu aşama, kuyruğa ne kadar iş düşeceğini görmenizi ve ekip kapasitesini planlamanızı sağlar.
4. Kendi kanallarınızı dönüştürün. Web, mobil ve çağrı merkezi formlarında seçimli girişe geçin. Bu kanallarda değişiklik tamamen sizin kontrolünüzdedir.
5. Pazaryeri siparişlerinde istisna kuyruğunu açın. Doğrulanamayan siparişleri sevkiyattan önce ayırın. Kuyruğun kimde olduğunu, ne kadar sürede ele alınacağını ve alıcıyla nasıl iletişim kurulacağını yazılı hâle getirin.
6. Depo ve kargo kurallarını yeni alanlara bağlayın. Bölge gruplamasını, etiket şablonunu ve raporları ham metin yerine yapısal alanlardan besleyin.
7. Geçmiş kayıtları aşamalı dönüştürün. Müşteri adres defterini, en çok sipariş verilen adreslerden başlayarak partiler hâlinde işleyin.

İlerlemeyi nasıl izlersiniz?

Rakamsal hedefleri kendi verinize göre belirleyin. İzlenecek göstergeler şunlar olabilir:

• Kanal bazında istisna kuyruğuna düşen siparişlerin zaman içindeki eğilimi
• Adres kaynaklı teslim edilemeyen ve iade dönen gönderiler
• Müşteri hizmetlerine gelen adres düzeltme talepleri
• Tekilleştirme sonrasında müşteri kayıtlarındaki değişim

Dikkat edilmesi gerekenler

• Pazaryeri kurallarını kontrol edin. Bazı pazaryerlerinde teslimat adresinin değiştirilmesi belirli kurallara bağlı olabilir. Düzeltmeyi kendi sisteminizde not olarak tutun, gerektiğinde alıcıyla teyit edin.
• Teslimat ve fatura adresini ayırın. İki adresin farklı olabileceğini modelde baştan öngörün.
• Otomatik düzeltmeyi sınırlayın. Arama sonuçlarındaki skor sıralama içindir. Bir adresin geçerli olduğunu ya da teslimat yapılabileceğini kanıtlamaz.
• Kişisel veriye özen gösterin. Adres ve alıcı bilgisi kişisel veridir. Saklama süresi, erişim yetkileri ve üçüncü taraflarla paylaşım konularında hukuk danışmanınızın görüşünü alın.

Sonraki adım

İşe kanal envanteriyle başlayabilir, ardından teknik ekibinizle küçük bir gözlem çalışması planlayabilirsiniz. Uçların ayrıntılarını API dokümantasyonu sayfasında bulabilirsiniz. Denemeye başlamak için ücretsiz kayıt olarak bir API anahtarı alabilirsiniz. Adres doğrulama içeren paketleri karşılaştırmak için paketler bölümüne göz atabilirsiniz.