Çoğu satıcı logları teknik bir çöplük sanır. Açar, ekranı dolduran satırlara bakar, hiçbir şey anlamadan kapatır ve müşteriye "kontrol ediyoruz" yazar. Oysa teslimat logu bir hata dökümü değildir; her siparişin kendi kendine tuttuğu ifade tutanağıdır. Doğru okumayı öğrendiğinde, "kodum gelmedi" diyen bir müşteriyle konuşmanı otuz saniyede kanıta dayandırırsın.
Bu yazıda logları baştan sona okumayı değil, doğru sırayla okumayı anlatıyorum. Hangi dört alan kanıt sayılır, hangi durum kodu neyi söyler, hangi zaman farkı kimin suçlu olduğunu gösterir. Bunları bilen bir satıcı, iyi bir e-pin satış scripti ile destek süresini yarıya indirir; bilmeyen satıcı ise elindeki bütün kanıta rağmen tartışmayı kaybeder.
Bir teslimat logunda gerçekten hangi alanlar kanıt sayılır?
Log satırı uzundur ama hepsi işine yaramaz. Kanıt değeri taşıyan dört alan vardır ve bir vakayı kapatmak için genellikle bu dördü yeter. Birincisi olay zamanı, saniye hassasiyetinde ve tek bir saat diliminde. İkincisi olay türü: ayrıldı, gönderildi, görüntülendi, iade edildi. Üçüncüsü aktör: sistem mi, hangi yönetici mi, yoksa müşterinin kendisi mi. Dördüncüsü sonuç: başarılı mı, hangi hata koduyla başarısız mı.
Bu dördü dışındaki her şey bağlam bilgisidir. IP, tarayıcı, oturum kimliği güzeldir ama karar vermez. Karar veren alan her zaman "görüntülendi" olayıdır, çünkü müşterinin kodu kendi hesabında açtığı an tartışmayı bitirir. Panelinde bu olay kayıtlı değilse, elinde yalnızca "biz gönderdik" ifadesi var demektir ki bu tek taraflı bir cümledir.
Bir de değişmezlik meselesi var. Log satırı sonradan düzenlenebiliyorsa kanıt değeri düşer. İyi kurgulanmış bir epin yazılım tarafında teslimat kayıtları yalnızca eklenir, hiç güncellenmez; yönetici bir şeyi düzeltmek istediğinde eski satır silinmez, üstüne yeni bir düzeltme satırı yazılır.
Vakayı hangi sırayla okumalısın?
Log okumada en büyük zaman kaybı, en son satırdan başlamaktır. En son satır genellikle mail sunucusuyla ilgili gürültüdür ve seni yanlış yöne çeker. Doğru sıra ödemeden başlar ve müşteriye doğru ilerler: ödeme onayı, stok ayrımı, kod yazımı, bildirim gönderimi, müşteri görüntülemesi.
Bu beş halkayı sırayla okuduğunda kopuk halkayı bulmak birkaç saniye sürer. Ödeme onayı yoksa sorun teslimatta değil ödemededir. Stok ayrımı yoksa kod yoktu. Kod yazımı varsa ama görüntüleme yoksa müşteri panelini hiç açmamıştır ve yapılacak şey ona giriş bağlantısını göndermektir. Her kopuk halka farklı bir cevap cümlesi üretir ve doğru cümle, doğru halkadan gelir.
| Log kaydı | Ne anlatır | Gerçek neden | İlk hamle |
|---|---|---|---|
| stock.reserve.fail | Kod ayrılamadı | Stok tükenmiş | Kod yükle, satırı yeniden çalıştır |
| delivery.write.ok + notify.fail | Kod yazıldı, mail gitmedi | Spam filtresi veya hatalı adres | Panel bağlantısını paylaş |
| delivery.duplicate.blocked | İkinci teslim engellendi | Butona iki kez basılmış | Aksiyon gerekmez |
| payment.pending > 15 dk | Ödeme askıda | Sağlayıcı bildirimi gelmedi | Sağlayıcı panelinden doğrula |
| delivery.write.ok + view.ok | Teslim ve görüldü | Müşteri kodu açmış | Zaman damgasını paylaş |
| provider.timeout | API yanıt vermedi | Sağlayıcı arızası | Yeniden dene, olmazsa iade |
Zaman damgaları kimin haklı olduğunu nasıl söyler?
Log okumanın en güçlü aracı süre farkıdır. Tek bir olayın zamanı bir şey anlatmaz, iki olay arasındaki boşluk her şeyi anlatır. Ödeme onayı ile stok ayrımı arasındaki boşluk sistem yükünü gösterir. Kod yazımı ile bildirim arasındaki boşluk mail altyapısını gösterir. Bildirim ile görüntüleme arasındaki boşluk müşteri davranışını gösterir.
Pratik bir kural: ilk iki boşluk saniyelerle ölçülmeli, üçüncüsü dakikalarla. Birinci boşluk dakikalara çıkıyorsa kuyruk tıkanmıştır. İkinci boşluk dakikalara çıkıyorsa gönderim sırası birikmiştir. Üçüncü boşluk saatlere çıkıyorsa hiçbir sorun yoktur, müşteri sadece geç bakmıştır ve senin yapacağın şey sakin bir bilgilendirmedir.
Bir de saat dilimi tuzağı var ve şaşırtıcı derecede sık can yakar. Sunucu UTC, panel yerel saat, mail sağlayıcısı bambaşka bir dilim gösterdiğinde üç saatlik hayalet gecikmeler ortaya çıkar. Kurulumda tek bir dilim belirle ve raporların hepsini o dilimde göster; aksi halde kendi logunla tartışırsın.
"Kodum gelmedi" vakalarının log sonrası dağılımı
- Teslim edilmiş, müşteri bakmamış 44%
- Mail gitmemiş, panelde duruyor 27%
- Stok yok, sipariş beklemede 18%
- Gerçek teslimat arızası 11%
Logda kesinlikle görünmemesi gereken şey nedir?
Burada bir güvenlik uyarısı yapmam gerekiyor, çünkü bu hata çok yaygın ve sonucu ağır. Teslim edilen kodun kendisi log satırında açık metin olarak durmamalıdır. Log dosyaları kopyalanır, destek ekibine gösterilir, yedeklenir, bazen hata izleme servislerine gider. Kodun kendisi orada yazıyorsa envanterin her kopyayla birlikte çoğalmış olur.
Doğru yöntem kodun yerine referans yazmaktır: stok kaydının kimliği, son dört karakter ve bir özet değeri. Bu üçü destek konuşmasında kimliklendirmeye yeter ve kimse kodu logdan okuyup kullanamaz. Aynı mantık müşteri bilgileri için de geçerlidir; tam adres veya kart bilgisi teslimat logunda hiç bulunmamalıdır.
Pinova tarafında bu ayrım baştan kurulu gelir: teslimat kaydı referansla tutulur, kodun kendisi yalnızca şifreli stok alanında yaşar ve müşteri paneline çözülerek gösterilir. Bir dijital ürün satış scriptini değerlendirirken log örneği istemek, güvenlik olgunluğunu ölçmenin en hızlı yoludur.
Müşteriye "kontrol ediyoruz" yazmak yerine görüntüleme zamanını paylaş. Saat ve dakika içeren tek bir cümle, uzun bir özür paragrafından daha hızlı kapatır.
Logu sadece vaka çıkınca değil, düzenli olarak neden okumalısın?
Logun asıl gücü olaydan sonra değil, olaydan önce ortaya çıkar. Haftada bir on dakika ayırıp üç sayıya bakmak, seni gelecek haftanın şikâyetlerinden kurtarır. Birinci sayı bildirim başarısızlık oranı; yükseliyorsa mail itibarın düşüyor demektir. İkinci sayı stok ayrım hataları; yükseliyorsa tükenmek üzere olan ürünler var. Üçüncü sayı sağlayıcı zaman aşımları; yükseliyorsa tedarik tarafında bir sıkıntı başlıyor.
Bu üç eğilim, sorunları müşteri fark etmeden görmeni sağlar. Satıcıların çoğu bu okumayı yapmadığı için, altyapı sorunlarını ilk kez olumsuz bir yorumla öğrenir. Oysa aynı bilgi, iki gün önce logda duruyordu ve kimse bakmamıştı.
Bir de saklama süresi kararı var. Uyuşmazlık süreçleri ve sağlayıcı itirazları düşünüldüğünde teslimat kayıtlarını doksan günden az tutmak risklidir. Disk maliyeti düşük, kanıtsız kalmanın maliyeti yüksek. Ayrıntılı teknik kayıtları otuz günde arşivleyip, teslimat olay kayıtlarını daha uzun saklamak dengeli bir tercihtir.
Otuz saniyelik vaka kapatma listesi
Aşağıdaki sırayı ezberlersen, destek kutuna düşen "kodum gelmedi" mesajlarının büyük kısmını tek mesajda kapatırsın. Sıra önemli; aşağıdan yukarı okumak seni her seferinde yanlış cevaba götürür.
| Sıra | Bakılacak kayıt | Var ise | Yok ise |
|---|---|---|---|
| 1 | Ödeme onayı | Devam et | Ödeme tarafını doğrula |
| 2 | Stok ayrımı | Devam et | Kod yükle ve yeniden işle |
| 3 | Kod yazımı | Devam et | Partiyi yeniden çalıştır |
| 4 | Bildirim sonucu | Devam et | Panel bağlantısı gönder |
| 5 | Müşteri görüntülemesi | Zamanı paylaş, kapat | Giriş adımında yardım et |
| 6 | İade veya yinelenen kayıt | Müşteriye açıkla | Vaka temiz, kapat |
Bu altı satır bir destek prosedürü gibi görünüyor ama aslında bir kalite ölçeği: panelin bu kayıtların hepsini tutuyorsa işin sağlam, tutmuyorsa her tartışmada bir adım geride başlıyorsun. Kayıt derinliğini karşılaştırmak için özellikler listesine ve paket sınırları için fiyat sayfasına bakabilirsin.
Her siparişin kendi tutanağı olsun
Referanslı teslimat kaydı, görüntüleme olayı, bildirim denemeleri ve haftalık eğilim raporu tek panelde toplanır.
Müşteri kodu gördüğünü inkâr ederse görüntüleme kaydı yeterli olur mu?
Çoğu durumda evet. Görüntüleme zamanı, oturum bilgisi ve bildirim kaydı birlikte sunulduğunda tartışma genellikle o noktada kapanır. Sağlayıcı itirazlarında da en çok işe yarayan kanıt bu üçlüdür.
Teslimat loglarını ne kadar süre saklamalıyım?
Teslimat olay kayıtlarını en az doksan gün tutmanı öneririm. Ayrıntılı teknik izleri otuz günde arşivleyip yalnızca özet olayları uzun süreli saklamak hem maliyeti hem de kanıt ihtiyacını dengeler.
Logda kodun tamamını görmek istiyorum, sakıncası ne?
Log kopyalanan bir veridir; ekran görüntüsüyle paylaşılır, yedeklenir, dışarı taşınır. Kodun tamamı orada yazıyorsa envanterin her kopyayla çoğalır. Son dört karakter ve stok kimliği kimliklendirme için yeterlidir.
Bildirim başarısızlık oranı kaçın üstünde alarm vermeliyim?
Yüzde ikinin üstü dikkat, yüzde beşin üstü müdahale eşiğidir. Bu seviyede alan adı doğrulama kayıtlarını ve gönderim itibarını kontrol etmek gerekir; sorun neredeyse hep orada olur.
Log okumak, öğrenilmesi bir saat süren ama her ay saatler kazandıran bir beceri. Kendi panelinde bu kayıtların nasıl göründüğünü merak ediyorsan canlı demo üzerinden bir sipariş oluşturup teslimat geçmişini aç; ödeme onayından müşteri görüntülemesine kadar beş halkanın tek ekranda nasıl sıralandığını görmek, anlatılan her şeyi yerine oturtuyor.