Hindistan'da kargo entegrasyonları: CSV yüklemeleri vs kurye API'leri

Bu işin aslı: daha az kargo takibiyle daha az takip talebi

Sipariş hacmi küçükken, kargo güncellemeleri hızlı kontroller, bir elektronik tablo ve kurye ile birkaç mesajla halledilebilir. Siparişler büyüdükçe, küçük aksaklıklar toplanır: etiketler geç oluşturulur, alımlar kaçırılır ve takip statüsü güncel kalmaz.

Denklem tanıdık: müşteriler "Siparişim nerede?" diye sorar. Destek operasyonu sorar. Operasyon bir portala bakar. Birisi otomatik güncellenmesi gereken bir durumu elle günceller.

Entegrasyon, sisteminizin gönderi verilerini (adres, ağırlık, COD, fatura değeri) gönderebilmesi ve gönderiye ait verileri (AWB numarası, alım onayı, takip taramaları, teslimat sonuçları) güvenilir şekilde geri çekebilmesi demektir. "Güvenilir" önemli çünkü bu her gün çalışmalı, sadece biri dosya yüklemeyi hatırladığında değil.

İşte bu yüzden bu karşılaştırma önemli:

• CSV yükleme iş akışı temel noktadır. Başlamak kolaydır, ama insanların aynı adımları zamanında tekrarlamasına bağlıdır.
• Tam kurye API entegrasyonu her zaman açık olandır. Gönderi oluşturabilir, takip taramalarını çekebilir ve istisnalara manuel beklemeden tepki verebilir.

Çoğu ekip "daha fazla teknoloji" istemez. Daha az gecikme, daha az manuel düzenleme ve herkesin güvenebileceği bir takip isterler. Takip taleplerini azaltırsanız (müşterilerden ve dahili ekiplerden), genellikle iadeleri, yeniden deneme maliyetlerini ve destek biletlerini de azaltırsınız.

Gerçek operasyonlarda kargo işi nerede yanlış gidiyor

Çoğu ekip basit bir rutinle başlar: alımları ayarla, etiketleri yazdır, takip ID'lerini bir tabloya yapıştır ve müşterilere güncelleme isteyince yanıt ver. Düşük hacimde işler ama Hindistan'da özellikle birden fazla kurye, COD ve tutarsız adres kalitesiyle uğraştığınızda çatlaklar hızlıca görünür.

Manuel adımlar tek başına büyük görünmez. Birisi bir kurye seçer, gönderiyi oluşturur, etiketleri indirir ve doğru paketin doğru airway bill (AWB) ile eşlendiğinden emin olur. Sonra bir başkası sipariş durumunu günceller, takibi paylaşır ve COD için teslim kanıtlarını kontrol eder.

En yaygın hata noktaları şunlardır:

• Yanlış AWB yanlış pakete yapışır ve bu kayıp paket veya iade ile sonuçlanır.
• Yeniden deneme veya bir spreadsheet kopyalama hatası sonrası çift gönderim oluşur.
• Takip zamanında güncellenmez, destek net bir cevap veremez ve müşteriler güvenini yitirir.
• Alım onaylanmaz, bu yüzden siparişler "kargoya hazır" gözükürken kurye hiçbir şey planlanmamış sanır.
• COD tutarları veya ücretler eşleşmez ve sonra mutabakat problemleri çıkar.

NDR, Non-Delivery Report (Teslim Edilememe Raporu) demektir. Teslimat başarısız olduğunda (yanlış adres, müşteri müsait değil, reddetme, ödeme sorunu) oluşur. NDR ekstra iş yaratır çünkü kararlar gerektirir: müşteriyi aramak, adresi güncellemek, yeniden denemeyi onaylamak veya iadeye işaretlemek.

Operasyon ilk baskıyı hisseder. Destek öfkeli mesajları alır. Finans COD mutabakatında takılır. Durumlar değişmediğinde müşteriler sessizliği hisseder.

Seçenek A: CSV yükleme tabanı (elde ettikleriniz ve edemedikleriniz)

CSV yükleme, Hindistan'daki birçok kargo kurulumu için varsayılan başlangıç noktasıdır. Mağazanızdan veya ERP'den bir grup ödenmiş siparişi dışa aktarır, bunları bir kurye veya toplayıcı şablonuna uyarlar ve sonra dashboard'da dosyayı yükleyerek AWB ve etiketleri üretirsiniz.

Elde ettiğiniz şey sadeliktir. Genellikle mühendislik çalışması gerekmez ve bir gün içinde yayında olabilirsiniz. Düşük hacim veya öngörülebilir gönderimler (aynı alım adresi, az sayıda SKU, az istisna) için günlük bir CSV "yeterli" ve eğitmesi kolay olabilir.

Sorun, yüklemeden sonraki her şeydir. Çoğu ekip her gün aynı temizleme işlerini yapar: pin kodu veya telefon formatı şablona uymadığı için başarısız satırları düzeltmek, düzeltilmiş dosyaları tekrar yüklemek, kazara çoğaltmaları kontrol etmek ve takip numaralarını mağaza yönetimine geri kopyala‑yapıştır yapmak.

Sonra karmaşık kısım gelir: istisnaları (adres sorunları, ödeme problemleri, RTO riski) e‑posta, arama ve kurye portalları arasında kovalama ve durumu birden çok yerde güncelleme, çünkü kurye panosu sizin kayıt sisteminiz değildir.

Gizli maliyet zaman ve tutarsızlıktır. Farklı kuryeler farklı sütunlar ve kurallar bekler, bu yüzden "tek CSV" birden fazla versiyona ve spreadsheet geçici çözümlerine dönüşür. Ve güncellemeler gerçek zamanlı olmadığı için, destek genellikle gecikmeleri sadece bir müşteri şikayet ettiğinde öğrenir.

Seçenek B: tam kurye API entegrasyonu (neyi mümkün kılar ve maliyeti nedir)

Tam bir kurye API kurulumu, sisteminiz ile kurye sistemlerinin doğrudan konuşması demektir. Dosya yüklemek yerine sipariş ve adres detaylarını otomatik gönderirsiniz, bir etiket alırsınız ve kimse birçok portalı kontrol etmeden takip güncellemelerini çekmeye devam edersiniz. Bu genellikle kargonun günlük bir operasyon görevi olmaktan çıkıp güvenilir altyapı gibi davranmaya başladığı noktadır.

Neyi mümkün kılar

Çoğu ekip kurye API entegrasyonuna üç temel işlem için başlar: rezervasyon, etiketler ve takip. Tipik yetenekler arasında gönderi oluşturup anında AWB almak, kargo etiketi ve fatura verisi üretmek, alım talep etmek (destekleniyorsa) ve takip taramalarını neredeyse gerçek zamanlı çekmek bulunur.

Bu temel işlemlerden sonra NDR durumu ve adres sorunları gibi istisnaları da daha temiz ele alabilirsiniz.

Getiri basittir: daha hızlı sevk, daha az kopyala‑yapıştır hatası ve daha net müşteri güncellemeleri. Bir sipariş saat 14:00'te ödendiyse, sisteminiz siparişi otomatik olarak rezerve edebilir, etiketi yazdırabilir ve dakikalar içinde takip numarasını gönderebilir; CSV dışa aktarma ve yeniden yükleme beklemeden.

Maliyeti nedir

API entegrasyonları "kur ve unut" değildir. Kurulum, test ve devamlı bakım için zaman planlayın.

Yaygın emek kaynakları:

• Kurye‑özel kurallar (pincode servis durumu, ağırlık dilimleri, COD limitleri)
• Durum kodu uyumsuzlukları (bir kuryenin "RTO başlatıldı" dediği diğerinin "iade yolda" dediğiyle farklılık olabilir)
• Webhook güvenilirliği ve kaçırılan etkinlikler için yeniden deneme mantığı
• Etiket formatları ve belge gereksinimlerinin zamanla değişmesi
• Sandbox ortamlarının prod ile tam uyuşmaması

Bu tuhaflıklara erken plan verirseniz, kurulum düzgün ölçeklenir. Vermezseniz, rezervasyon yapılmış ama alınmamış gönderiler veya izleme olayları yanlış eşlendiği için müşterilerin kafa karışıklığı yaşadığı durumlar oluşabilir.

Ne otomatikleştirilmeli, ne manuel bırakılmalı (pratik bir ayrım)

Basit bir kural işe yarar: günde birçok kez gerçekleşen ve küçük bir hatanın büyük yeniden iş yaratmasına neden olduğu görevleri otomatikleştirin.

Hindistan'da bu genellikle rezervasyon, etiket ve takip güncellemeleri anlamına gelir. Bir yazım hatası veya kaçırılan bir tarama, takip eden birçok iletişime yol açabilir.

Manuel adımların hala yeri vardır. Hacim düşük olduğunda, istisnalar sık olduğunda veya kurye süreçleri otomasyon için yeterince tutarlı değilse bir şeyi manuel bırakın.

İş akışına göre pratik bir ayrım:

• Önce otomatikleştirin: sipariş sisteminizden gönderi rezervasyonu, etiket oluşturma ve yazdırma, takip durumu çekmeleri veya webhooklar, NDR uyarıları ile iç kuyruk, destek ekibine teslimat onayı mesajları.
• Manuel bırakın (hacim olana kadar): kenar durumlar için kurye seçimi, telefonda alım değişiklikleri pazarlığı, riskli COD yeniden denemelerini onaylama ve yargı gerektiren tek seferlik adres düzeltmeleri.

Bir kararı hızlıca vermek için tablo:

Basit bir kontrol noktası: ekibiniz aynı veriye iki kez dokunuyorsa (siparişi kurye portalına kopyala‑yapıştır, sonra tekrar tabloya), o adım güçlü bir otomasyon adayıdır.

Takip olayları kontrol listesi: alım, taşınma, NDR, teslim

Daha az "siparişim nerede?" mesajı istiyorsanız, takibi tek bir durum olarak değil bir olay zaman çizelgesi olarak ele alın. Bu Hindistan'da önemlidir; aynı gönderi hub'lar, yeniden denemeler ve iadeler arasında gidip gelebilir.

Ekip ve müşterilerin aynı hikayeyi görmesi için bu aşamaları yakalayın:

• Pickup: alımın ne zaman planlandığı, deneme yapılıp yapılmadığı ve nihai sonuç (alındı veya başarısız). Başarısız olursa, kuryenin başarısızlık nedenini saklayın ki sürücü aramaya gerek kalmadan harekete geçebilesiniz.
• In-transit: ilk tarama (genellikle gerçek başlangıç), ana hub taramaları, istisna veya gecikme bayrakları ve "dağıtıma çıkıyor". Bunlar en çok destek sorusunu tetikleyen noktalardır.
• NDR (Non-Delivery Report): bir NDR oluştuğunda, sebep kodu, müşterinin aranıp aranmadığı ve sonraki adım (yeniden deneme planlandı mı yoksa iade mi başlatıldı). Burada saat işliyor.
• Delivered (veya değil): teslimat zamanı ve mevcutsa teslim kanıtı (isim, imza, fotoğraf referansı). Ayrıca "teslim başarısız" ile "iade"yı ayrı tutun; müşteriler bunları çok farklı sonuçlar olarak algılar.

Her olay için aynı temel alanları saklayın: timestamp, location (şehir ve hub varsa), raw status text, normalized status, reason code ve courier reference/AWB. Hem ham hem normalleştirilmiş değerleri saklamak denetimler ve kurye itirazlarında işleri kolaylaştırır.

Entegre etmeden önce ihtiyaç duyduğunuz veriler (sonradan hiçbir şey bozulmasın diye)

Birçok kargo entegrasyonu sıkıcı nedenlerle başarısız olur: eksik telefon numaraları, tutarsız ağırlıklar veya hangi sistemin "gerçeğin kaynağı" olduğuna dair net karar eksikliği. Bir API'ye dokunmadan önce, her sipariş için her zaman sahip olacağınız asgari verileri kilitleyin.

CSV ile de çalışacak bir tabanla başlayın. Bu alanları güvenilir şekilde dışa aktaramazsanız, bir API yalnızca hataların daha hızlı olmasını sağlar:

• Sipariş ID (benzersiz ve asla tekrar kullanılmayan)
• Tam teslimat adresi (isim, pincode, şehir, eyalet, landmark varsa)
• Telefon numarası (doğrulanmış format) ve e‑posta (opsiyonel)
• Ürün ve gönderi bilgisi (SKU, adet, net ağırlık, varsa ebatlar)
• Ödeme detayları (COD tutarı, ön ödemeli bayrak)

Sonra kuryeden ne beklediğinizi tanımlayın, çünkü bunlar her şeyin "kulp"ları olur. En azından saklayın: gönderi ID'si, AWB numarası, kurye adı veya kodu, etiket referansı ve alım tarihi veya penceresi.

Bir kararı netleştirmek haftalarca süren karışıklığı önler: gönderi durumu için tek bir doğruluk kaynağı seçin. Ekip kurye portalını kontrol edip sisteminizi geçersiz kılarsa, müşteriler bir şeyi görürken destek başka bir şeyi söyleyecektir.

Herkesi hizada tutacak basit bir eşleme planı:

• Kullanacağınız iç durumları seçin (örneğin: Created, Picked Up, In Transit, Out for Delivery, Delivered, NDR).\n- Her kurye durumunu tek bir iç duruma eşleyin (detay kaybı gibi gelse bile).\n- Denetimler için ham kurye durum metnini ayrı saklayın.\n- Hangi olayların otomatik olarak durumu değiştirebileceğini, hangilerinin sadece insan müdahalesiyle değişeceğini belirleyin.

Bunu Koder.ai gibi bir araç içinde inşa ediyorsanız, bu alanları ve eşlemeleri erken aşamada birinci sınıf modeller olarak ele alın ki dışa aktarım, takip ve geri alma ikinci kurye eklediğinizde bozulmasın.

Adım adım: CSV'den API'ye kaosa yol açmadan geçiş

En güvenli yükseltme yolu, tek bir büyük kesinti yerine bir dizi küçük geçiştir. Entegrasyon sıkılaşırken operasyon gönderimi yürütmelidir.

1) Kod yazmadan önce kapsamı kilitleyin

Gerçekten kullanacağınız kuryeleri seçin, sonra hangi eylemlere şimdi ihtiyaç duyduğunuzu ve hangilerinin sonra geleceğini doğrulayın: gönderi rezervasyonu, takip, NDR yönetimi ve iadeler (RTO). Bu önemli çünkü her kurye durumları farklı adlandırır ve farklı alanlar sağlar.

2) Önce takip entegrasyonunu yapın (salt okunur)

Rezervasyon veya etiket oluşturmadan önce takip olaylarını sisteminize çekin ve sipariş yanında gösterin. Bu düşük risklidir çünkü paketlerin nasıl oluşturulduğunu değiştirmez.

AWB ile olayları çekebildiğinizden emin olun ve AWB eksik veya yanlış olduğunda ne yapacağınızı yönetin.

3) Durumları eşleyin, ama ham gerçeği saklayın

Küçük bir iç durum modeli oluşturun (pickup, in‑transit, NDR, delivered) ve kurye durumlarını buna eşleyin. Ayrıca alınan her ham olay yükünü tam olarak olduğu gibi kaydedin.

Müşteri "teslim gösteriyor ama almadım" dediğinde, ham olaylar desteğin hızlı yanıt vermesine yardımcı olur.

4) NDR otomasyonunu dikkatle ekleyin

Kolay kısımları otomatikleştirin: NDR'ı tespit edin, bir kuyruğa atayın, müşteriyi bilgilendirin ve yeniden deneme pencereleri için zamanlayıcılar ayarlayın.

Adres değişiklikleri ve özel durumlar için manuel geçersiz kılma bırakın.

5) Ancak bundan sonra rezervasyon, etiket ve alım zamanlamasını ekleyin

Takip kararlı hale geldikten sonra API rezervasyonunu, etiket üretimini ve alım isteklerini ekleyin. Bunu kurye bazında yayınlayın ve birkaç hafta CSV yolunu bir yedek olarak bırakın.

Gerçek senaryolarla test edin:

• NDR sonrası adres değişikliği\n- Yeniden deneme istendi ama yapılmadı\n- RTO tetiklendi sonra iptal edildi\n- Kısmi teslimat veya bölünmüş gönderi\n- OTP veya POD detayları olmadan gelen teslimat taraması

Destek biletlerine ve gecikmelere yol açan yaygın hatalar

Çoğu kargo bileti sadece "siparişim nerede?" değildir. Bunlar uyuşmayan beklentilerdir: sisteminiz bir şey söylüyor, kurye başka bir şey, müşteri üçüncü bir şeyi görüyor.

Yaygın bir tuzak durum metninin standart olduğunu varsaymaktır. Aynı kilometre taşı bölgeler, hizmet tipleri veya hub ifadeleri boyunca farklı ifadelerle görünebilir. Tam metne göre eşleme yaparsanız, gösterge panonuz ve müşteri mesajlarınız sapar.

Gecikme ve ekstra takip yaratan hatalar:

• Sadece en son durumu kaydetmek: olay geçmişini üzerine yazmak olan biteni açıklayan zaman çizelgesini kaybettirir. Tam geçmişi zaman damgası ve konumla saklayın.
• NDR'ı tek bir durum gibi ele almak: NDR bir süreçtir. Sebebi, alınan aksiyon ve sonraki deneme tarihi gerekir.
• Geç veya sıra dışı gelen olaylara karşı önlem olmaması: kuryeler olayları yığın halinde veya garip sırayla gönderebilir. Uzlaştırma ve güvenli güncellemeler olmadan sisteminiz durumları ileri geri çevirebilir.
• Yeniden deneme mantığı ve oran limit davranışının eksikliği: API çağrıları başarısız olur. Güvenli şekilde yeniden denemezseniz güncellemeleri kaçırırsınız. Çok agresif yeniden denerseniz oran limiti alırsınız.
• Operasyonel bir yedek planı yok: API kapandığında ne olacağına karar verin. Bir günlüğüne CSV'ye geçebilir misiniz, bildirimleri durdurabilir misiniz veya siparişleri manuel inceleme için işaretleyebilir misiniz?

Basit bir örnek: bir müşteri paketin "iade edildiğini" söylüyor. Sisteminiz sadece "NDR" gösteriyorsa, NDR sebebini ve yeniden deneme geçmişini saklamış olsaydınız müşteri temsilcisi tek bir mesajla cevap verebilirdi.

Entegrasyonu “tamam” demeden önce hızlı kontroller

Başarı ilan etmeden önce entegrasyonu operasyon ve destek ekibinin yoğun kullandığı şekilde test edin. Bir kurye durum güncellemesi gecikmeli gelirse veya doğru detayları içermeden gelirse, güncelleme olmamasıyla aynı sorunu yaratır.

Farklı pincode ve ödeme tiplerinde en az 10 gerçek siparişte "bir gönderi, uçtan uca" tatbikatı yapın. Bir sipariş seçin ve şu soruların yanıtlanma süresini ölçün:

• Şu an nerede?\n- Önce ne oldu?\n- Sonraki adım ne?

Çoğu boşluğu yakalayan hızlı kontrol listesi:

• Alım kanıtı hızlı görünür: alım beklenen sürede onaylanmış olmalı ve "etiket oluşturuldu" ile "fiziksel olarak alındı" arasındaki farkı söyleyebilmelisiniz.
• NDR işe yarar olmalı, sadece bir durum değil: NDR sebep kodu ve sonraki adımı (yeniden deneme, arama veya RTO) saklamalı ve bu kararı değiştirebilmelisiniz.
• Zaman çizelgesi kolay bulunmalı: bir temsilci bir AWB için tam olay geçmişini 30 saniye içinde çekebilmeli, zaman damgaları ve konumlar dahil.
• Teslim edilen ile para ve iade eşleşmeli: teslim edilen gönderiler COD ödeme raporları ve iade/RTO verileriyle uzlaşmalı, böylece finans hafta sonunda eşleşmeler için koşmasın.
• Güvenli bir manuel geçersiz kılma olmalı: adres düzeltebilir, teslimatı yeniden planlayabilir veya gerektiğinde başka bir kurye atayabilirsiniz; her manuel değişim loglanmalıdır.

İç ekranlar inşa ediyorsanız, ilk versiyonu sıkıcı tutun: bir gönderi arama kutusu, temiz bir zaman çizelgesi ve iki buton (manuel not ve geçersiz kılma).

Koder.ai gibi araçlar bu operasyon panosunu hızlıca prototiplemenize ve hazır olduğunuzda kaynak kodunu dışa aktarmanıza yardımcı olabilir. Eğer sonra keşfetmek isterseniz, koder.ai olarak görünür.

Örnek: 20'den 150 sipariş/gün'e ölçeklenen bir D2C ekibi

Orta ölçekli bir D2C marka günde yaklaşık 20 siparişle başlar, çoğunlukla bir metro bölgesine gönderim yapar. İki kurye ortağı kullanırlar. Süreç basittir: siparişleri dışa aktar, CSV'yi günde iki kez yükle, ardından takip numaralarını mağaza yönetimine kopyala‑yapıştır yap.

150 sipariş/gün ve üç kurye ile bu rutin çatlamaya başlar. Müşteriler "paketim nerede?" diye sorar ve destek üç portalı kontrol etmek zorunda kalır.

En kötü kısım NDR'lar. Teslimat denemesi başarısız olur, kurye birisi arar ve takip WhatsApp zincirine dönüşür. Yeniden denemeler kaçırılır ve küçük bir gecikme iptaller ve iadelerle sonuçlanır.

Otomatik olarak olayları senkronize eden bir kurulumla değişirler. Artık her gönderi güncellemesi tek bir yerde iner ve ekip ekran görüntüleri yerine tek bir kuyruğun üzerinden çalışır.

Günlük değişiklikler:

• Takip olayları otomatik olarak siparişe senkronize olur (alım, taşınma, dağıtıma çıkış, teslim edildi).\n- NDR'lar açıklamalı bir kuyruğa dönüşür (adres sorunu, müşteri ulaşılamıyor, ödeme problemi).\n- Yeniden deneme hatırlatıcıları belirlenmiş zamanda tetiklenir, böylece hiçbir şey iki gün durmaz.\n- Destek en son durumu kurye portallarına girmeden görür.

Her şey otomatik değil. Kenar PIN kodlar veya yoğun sezonda kapasite sorunları için hâlâ manuel kurye değiştirme yaparlar. Müşteri adres düzeltmesi için aradığında, bir insan doğrulama yapar ve sonra yeniden deneme tetiklenir.

Sonraki adımlar: kapsam seçin ve basit bir ilk sürüm oluşturun

İlk 2–4 hafta içinde neye ihtiyacınız olduğunu kararlaştırın. En büyük kazanç genellikle güvenilir takip ve daha az "siparişim nerede?" biletinden gelir, her özelliği ilk günde yapmak değil.

Ağrılarınızla eşleşen bir başlangıç kapsamı seçin:

• Sadece takip: kuryeden olayları çekin ve müşteriyi ile destek ekibini senkronize tutun.\n- Rezervasyon + etiket: gönderi oluşturun, etiket üretin ve AWB numaralarını otomatik saklayın.\n- Rezervasyon + etiket + alım: alım zamanlaması ve alım onayı ekleyin, böylece operasyon sürücüleri kovalamaz.

Kod yazmadan önce dahili olarak kullanacağınız dili kilitleyin. Olay kontrol listenizi yazın (pickup, in‑transit, NDR, delivered) ve her kurye durumunu kendi durumlarınızdan birine eşleyin. Bunu atlarsanız, beş farklı "in transit" varyantı ve müşteri bildirimleri, NDR görevleri veya sipariş tamamlama kuralları için net olmayan kurallar elde edersiniz.

Aşamalar halinde yayınlayın (ve sıkıcı tutun)

Güvenli bir yayım şöyle görünür: bir kurye, bir hat (veya bir depo), sonra genişletme.

Yeni akışınızı kısa süre CSV ile paralel çalıştırın ki operasyon AWB, etiket ve takip güncellemelerini karşılaştırabilsin. Basit bir geri dönüş planı tutun: API çağrısı başarısız olursa, dispatch'i engellemek yerine manuel rezervasyon için bir görev oluşturun.

Köşeye sıkışmadan hızlı inşa edin

Hızlı ilerlemek isterseniz, kurye API entegrasyonunu Koder.ai ile prototipleyin: olay depolama tablosunu, durum eşleme kurallarını ve küçük bir operasyon panosunu (sipariş veya AWB ile arama, son olay, sonraki aksiyon) tanımlayın. Ekip beklendiği şekilde davranınca kaynak kodunu dışa aktarın ve yeniden denemeler, loglama ve erişim kontrolleri ile sertleştirin.

İyi bir ilk versiyon "tam" olan değil. Tek kuryeyle uçtan uca çalışan, temiz olayları olan, NDR için net sahiplik belirlenmiş ve operasyonun şu anda neye dikkat etmesi gerektiğini gösteren günlük bir görünümü olan sürümdür.