Tersine Lojistiği Kontrol Altına Almak: İade Süreçlerinin Uçtan Uca Dijitalleştirilmesi

1. Giriş: Satmak Kolay, İade Almak Kaotik

E-ticaret altyapısına yapılan yatırımların büyük çoğunluğu aynı yönü işaret eder: müşterinin sepete eklemesinden ödeme adımına kadar olan deneyimi mümkün olduğunca sürtünmesiz hâle getirmek. Ürün listeleme, fiyatlandırma, kampanya yönetimi, checkout akışı — bunların hepsinde ciddi bir olgunluk seviyesine ulaşılmış olmakla birlikte, operasyonun diğer yüzü çoğu zaman görmezden gelinir: müşteri ürünü iade etmek istediğinde ne olur?

Kâğıt üzerinde süreç basit görünür. Müşteri iade talebini açar, kargoya verir, depo teslim alır, ürün kontrol edilir, para iadesi yapılır. Gerçekte bu adımların her biri arasında bilgi kopukluğu, manuel müdahale ve bekleyiş vardır.

Türkiye'deki pek çok e-ticaret operasyonunda gözlemlediğimiz tablonun özeti şudur:

• Müşteri iade talebini açar, kargoya verir. Kargo nereye gitti? Depo bilmez.
• Kargo depoya ulaşır. İçinden ne çıkacak? Kimse bilmez.
• Ürün açılır, incelenir, "sağlam" kararı verilir. Bu bilgi nasıl muhasebeye iletilir? WhatsApp mesajıyla.
• Muhasebe para iadesini yapmak ister. Depoyu arar mı, yazar mı? İkisi de; ama zaman kaybı kaçınılmazdır.
• Stok sistemi güncellendi mi? Belki. Birisi unuttu mu? Muhtemelen. Bu tabloda belki tek bir kişi bile kötü niyetli değildir. Problem, sürecin sistematik bir zemine oturtulmamasından kaynaklanır. Ve bu zemin olmadığında, yük tamamen bireysel dikkat ve hafızaya yüklenir — her ikisi de güvenilmez kaynaklardır.

Bu vaka çalışması, söz konusu kaosun bir n8n tabanlı otomasyon katmanıyla nasıl yapılandırıldığını ve e-ticaret altyapısı, depo, ERP ile iletişim araçlarının tek bir tutarlı süreçte nasıl birleştirildiğini aktarmaktadır.

2. Mevcut Durumun Analizi: Nerede, Ne Kırılıyordu?

Projeye başlamadan önce operasyonu gözlemlemek ve mevcut akışı haritalandırmak için yaklaşık üç hafta harcadık. Tespit ettiğimiz kırılma noktaları birbirinden bağımsız değil, zincirleme bir yapıdaydı.

2.1 Depoya Gelen Sürpriz Paketler

İade kargolarının depoya gelişi, öncesinde hiçbir bildirim olmadan gerçekleşiyordu. Depo personeli kolinin üzerine yapıştırılmış kargo barkodunu taradığında elde ettiği bilgi yalnızca kargo firmasının kendi sistemindeki taşıma kaydıydı — hangi müşteriye ait, hangi sipariş numarasıyla ilişkili, hangi ürünlerin içeride olması gerektiği hakkında hiçbir veri yoktu.

Bu durum iki somut sorunu doğuruyordu. Birincisi, depo personeli kolinin içinde ne olacağını bilerek açmak yerine her paketi sıfırdan bir keşif süreci olarak ele almak zorunda kalıyordu. İkincisi, aynı gün birden fazla iade geldiğinde hangi paketin hangi müşteriye ait olduğunu eşleştirmek için sipariş geçmişinin manuel olarak aranması gerekiyordu.

2.2 ERP'ye Manuel Veri Girişindeki Gecikmeler

Ürün kontrolü tamamlandıktan sonra "sağlam" olduğuna karar verilen ürünlerin yeniden satışa açılması için ERP sistemine manuel giriş yapılması gerekiyordu. Bu adım, iş yoğunluğuna bağlı olarak bazen birkaç saat, bazen bir iş günü bekleyebiliyordu.

Bu gecikmenin faturasını iki taraf ödüyordu. Birincisi, ürün aslında depoda hazır olmasına karşın pazaryerinde stok sıfır gösterdiği için kaçırılan satışlar yaşanıyordu. İkincisi, stok güncelleme işlemi yapılırken birden fazla ERP kullanıcısının paralel çalışması zaman zaman mükerrer girişlere ve stok şişmelerine yol açıyordu.

2.3 Muhasebe–Depo İletişiminin WhatsApp Üzerinden Yürütülmesi

Para iadesi adımı, sürecin en kırılgan noktasıydı. Muhasebe departmanı, para iadesi yapabilmek için deponun "ürün geldi ve sağlam" onayını alması gerektiğini biliyordu. Ancak bu onay için kurumsal bir kanal yoktu.

Gözlemlediğimiz akış şuydu: Depo sorumlusu, kontrolü tamamlayınca muhasebeye WhatsApp üzerinden mesaj atıyordu. Muhasebe bu mesajı görüp ERP'de ilgili siparişi bularak para iadesi işlemini başlatıyordu. Mesaj gözden kaçtığında ya da muhasebe yoğunken gecikmeler oluşuyordu.

Denetim açısından da bu yapı sorunluydu. "Kim ne zaman hangi onayı verdi?" sorusunun yanıtını bulmak için WhatsApp geçmişini taramak gerekiyordu. Bu, hem zaman kaybı hem de hata riskiydi.

2.4 Müşteri Hizmetleri Üzerindeki Baskı

Müşteri, "iadem ne oldu?" sorusunun yanıtını merak ettiğinde başvurabileceği otomatik bir bildirim yoktu. Bu boşluğu telefon görüşmeleri ve destek talepleri dolduruyordu. Müşteri hizmetleri temsilcileri ise her sorgu için depoyu aramak ya da ERP'de takip etmek zorunda kalıyordu.

Ölçeği büyüdükçe bu baskı lineer değil, katlanarak artıyordu. Günde 30 iade varken yönetilebilir olan süreç, 150 iadeye çıktığında tamamen bunalmaya dönüşüyordu.

3. Mimari Karar: Neden n8n ve Neden Merkeze Aldık?

3.1 Neden iPaaS veya Custom Yazılım Değil?

Sorunun teknik çözümünü tasarlarken üç seçeneği değerlendirdik.

Birinci seçenek: Zapier / Make gibi bulut tabanlı iPaaS araçları. Bu araçlar hız avantajı sunmakla birlikte her adım için lisans maliyeti doğuruyordu ve özellikle Türkiye'deki bazı ERP sistemleriyle entegrasyon konusunda esneklik sınırlıydı. Veri egemenliği de bir endişeydi; iadelere ait ticari verinin üçüncü parti bulut sistemlerinden geçmesi kabul edilemezdi.

İkinci seçenek: Custom otomasyon servisi yazmak. Bu, tam kontrol sağlardı ancak bakım yükünü ve geliştirme süresini önemli ölçüde artırırdı. Her iş kuralı değişikliğinde yazılım geliştirme sürecini tetiklemek, operasyonel çevikliği yok eder.

Üçüncü seçenek: Self-hosted n8n. Açık kaynaklı, self-hosted yapısı sayesinde veri dışarı çıkmaz. Görsel iş akışı editörü, iş kurallarının geliştiriciye bağlı kalmadan güncellenmesine imkân tanır. Webhook desteği, zamanlayıcılar, koşullu dallanma ve yerleşik hata yönetimi, ihtiyaç duyulan tüm temel bileşenleri kapsar. Türkiye'de yaygın kullanılan ERP sistemleri (Netsis, Logo Tiger, Mikro) için özel HTTP Request node'ları üzerinden entegrasyon yazılabilir.

Kararımız n8n oldu.

3.2 Genel Mimari

Sistemin temel tasarım ilkesi şuydu: her karar noktası insan gözünden geçmeli, ama bilgi taşıma işini insan yapmamalı.

Bu ilke, depo personelinin ürün durumunu sisteme gireceği anlamına gelir — ama bu girişin ardından tetiklenen tüm akışlar (stok güncellemesi, muhasebe bildirimi, müşteri SMS'i) otomatik çalışır.

[Pazaryeri / Site]
        │
        │ İade talebi açıldı (webhook)
        ▼
   [n8n Orchestrator]
        │
   ┌────┴────────────────────────────┐
   │                                 │
   ▼                                 ▼
[Depo Terminali]               [Müşteri Bildirimi]
 "Beklenen İade" kaydı          "İadeniz alındı" SMS/E-posta
        │
        │ Ürün geldi + kalite kontrol
        ▼
   [n8n Karar Ağacı]
        │
   ┌────┴────────────────┐
   │                     │
   ▼                     ▼
[Sağlam]           [Kusurlu]
   │                     │
   ├─ ERP +1 stok        └─ Karantina stoğu
   ├─ Pazaryeri sync     └─ Tedarikçi bildirim akışı
   ├─ Muhasebe bildirimi
   └─ Müşteri onay SMS/E-posta

4. Bileşen 1: Otomatik İade Talebi Yönetimi ve Depo Ön Bilgilendirmesi

4.1 Tetikleyici: Pazaryeri Webhook'u

Trendyol, Hepsiburada ve sitenin kendi checkout altyapısı (Shopify ya da custom Next.js) her iade talebi açıldığında bir webhook eventi fırlatır. n8n bu event'i karşılayan bir Webhook node'u üzerinden süreci başlatır.

Gelen payload tipik olarak şu bilgileri içerir:

{
  "event": "return_request_created",
  "order_id": "ORD-2025-48291",
  "customer": {
    "id": "USR-19204",
    "name": "Ahmet Kaya",
    "phone": "+905XXXXXXXXX",
    "email": "ahmet@ornek.com"
  },
  "items": [
    {
      "sku": "PRD-LAPTOP-001",
      "name": "15.6 İnç Laptop Çantası",
      "quantity": 1,
      "return_reason": "Ürün beklentimi karşılamadı"
    }
  ],
  "return_tracking_number": "TY1234567890",
  "marketplace": "trendyol",
  "created_at": "2025-05-28T09:14:33Z"
}

4.2 n8n İş Akışı — İlk Adımlar

Webhook tetiklendiği anda n8n şu adımları sırayla yürütür:

Adım 1 — Kayıt oluşturma: Gelen payload PostgreSQL veritabanındaki return_requests tablosuna yazılır. Durum alanı pending_arrival olarak işaretlenir.

Adım 2 — Depo terminali bildirimi: Depo ekibinin kullandığı dahili web uygulamasına (Next.js tabanlı depo terminali) bir POST isteği gönderilir. Terminal, yeni bir "Beklenen İade" kartı oluşturur. Kart üzerinde iade kargo takip numarası, sipariş detayları ve hangi ürün(ler)in gelmesi beklendiği görünür.

Bu adımdan itibaren depo personeli, her sabah "bugün ne gelebilir?" sorusunu sormak yerine terminaldeki listeye bakarak bekleyen iadelerin tamamını görebilir.

Adım 3 — Müşteri bilgilendirmesi: Müşteriye "İade talebinizi aldık. Kargonuzu takip ediyoruz." içerikli bir SMS ve e-posta gönderilir. Bu, müşteri hizmetlerine "talebim alındı mı?" sorusunu soran çağrıların önemli bir bölümünü önceden yanıtlar.

4.3 Kargo Takip Entegrasyonu

n8n'de tanımlı bir Cron node, her 2 saatte bir aktif iade takip numaralarını tarar ve ilgili kargo API'sına (Yurtiçi, PTT Kargo, Aras vb.) sorgu atar. Kargo durumu "teslim edildi" olarak güncellendiğinde:

• İlgili return_request kaydının durumu arrived olarak güncellenir.
• Depo terminalindeki kart rengi değişir (sarıdan turuncuya), personele görsel uyarı verir.
• Müşteriye "Kargonuz depomuza ulaştı, kalite kontrolü başlatıyoruz." bildirimi gider.

5. Bileşen 2: Kalite Kontrol ve Otomatize Karar Ağacı

5.1 Depo Terminali Arayüzü

Depo personeli, terminaldeki "Arrived" statüsündeki iade kartını açar. Ekranda şu bilgiler görünür:

• Sipariş numarası ve müşteri adı

• Beklenen ürün(ler) ve barkod(lar)

• Pazaryerinden gelen iade sebebi

• Ürünün orijinal sipariş tarihi ve değeri Personel paketi açar, ürünü inceler ve barkodu okutarak iki seçenekten birini seçer:

• ✅ Sağlam / Satılabilir: Ürün orijinal ambalajında ya da yeniden paketlenebilir durumda, satışa açılabilir.

• ❌ Kusurlu / Hurda: Ürün hasar görmüş, eksik parçalı ya da kullanılmış; yeniden satış mümkün değil. Bu iki seçim, farklı n8n iş akışlarını tetikler.

5.2 "Sağlam" Kararı — Stok ve Muhasebe Akışı

Personel "Sağlam" seçeneğini onayladığı anda terminal, n8n'e bir POST isteği gönderir. n8n aşağıdaki adımları paralel olarak yürütür:

ERP Stok Güncellemesi:

n8n, ERP sisteminin REST API'sına (Netsis veya Logo Tiger için özel HTTP Request node'u) bir stok artış talebi gönderir. İlgili SKU için depo konumu belirtilerek stok +1 (ya da iade miktarı kadar) artırılır.

// ERP'ye gönderilen örnek payload
{
  "action": "stock_increase",
  "sku": "PRD-LAPTOP-001",
  "warehouse_id": "WH-01",
  "quantity": 1,
  "reason": "customer_return_approved",
  "reference": "ORD-2025-48291"
}

Pazaryeri Stok Senkronizasyonu:

ERP güncellemesi onaylandıktan sonra n8n, Trendyol ve Hepsiburada'nın stok API'larına güncel stok değerini yayınlar. Bu adım sayesinde ürün, depoya geldikten dakikalar içinde pazaryerlerinde tekrar satışa açılır.

Muhasebe Bildirimi:

n8n, Slack veya Discord'daki muhasebe kanalına otomatik bir mesaj gönderir:

💰 Para İadesi Onayı Gerekli Sipariş: ORD-2025-48291 | Müşteri: Ahmet Kaya Ürün: 15.6 İnç Laptop Çantası (x1) Durum: Depo onayladı — Sağlam ✅ İade Tutarı: ₺349,00 ERP'de Görüntüle →

Eğer ERP sistemi iade faturası taslağı oluşturmayı destekliyorsa (Logo Tiger gibi bazı sistemler destekler), n8n bu taslağı da otomatik oluşturur ve muhasebeciye yalnızca onaylama adımını bırakır.

Müşteri Onay Bildirimi:

Tüm bu adımlar tamamlanırken eş zamanlı olarak müşteriye şu içerikli SMS ve e-posta gönderilir:

Merhaba Ahmet Bey, [Sipariş No: ORD-2025-48291] için iade ettiğiniz ürün depomuza ulaştı ve kalite kontrolünü geçti. Para iadeniz en geç 3 iş günü içinde ödeme yönteminize yansıyacaktır.

5.3 "Kusurlu" Kararı — Karantina Akışı

Personel "Kusurlu" seçeneğini seçtiğinde farklı bir dallanma devreye girer:

• Ürün ERP'de karantina deposuna (WH-QUARANTINE) atanır. Satışa açılmaz.
• n8n, ilgili tedarikçi bilgisi mevcutsa bir bildirim akışı başlatır (isteğe bağlı): tedarikçiye hasar tespiti için kayıt açılır.
• Muhasebe yine bilgilendirilir, ancak bu kez para iadesi kararı farklı bir değerlendirme sürecine bırakılır (örneğin, ürün hasarının müşteriden mi yoksa nakliyeden mi kaynaklandığı araştırılır).
• Müşteriye ise "İadeniz inceleme aşamasındadır, en kısa sürede bilgilendireceğiz." içerikli bir bildirim gider. Karantina stoğu her hafta periyodik bir n8n akışıyla raporlanır ve operasyon yöneticisine haftalık özet e-postası gönderilir: kaç ürün karantinada, toplam değer nedir, açık kaç adet inceleme talebi var?

6. Bileşen 3: Muhasebe Otomasyonu ve Müşteri İletişimi

6.1 Para İadesi Akışının Tasarımı

Geleneksel yapıda para iadesi sürecinde iki kritik bekleme noktası vardı: deponun muhasebeyi haberdar etmesi ve muhasebenin ERP'de ilgili siparişi bulup işlemi başlatması. Bu iki adımın arasındaki süre öngörülemezdi.

Yeni yapıda muhasebe, depo onayı tamamlanır tamamlanmaz bilgilendirilir — insan aracısı olmaksızın. Slack bildirimi içindeki "ERP'de Görüntüle" bağlantısı doğrudan ilgili sipariş kaydına gider, muhasebeci sıfırdan arama yapmak zorunda kalmaz.

Daha ileri seviye entegrasyona gidilen müşterilerde ise bu adım da otomatize edilmiştir: muhasebe yalnızca iade işleminin doğruluğunu onaylar, ERP'deki tüm form doldurma işlemini n8n halleder.

6.2 Bildirim Mimarisi

Müşteri iletişimi için çok kanallı bir yapı kuruldu. İade sürecinin her kritik adımında müşteri bilgilendirilir:

Bu yapı, müşteri hizmetlerine gelen "iadem ne oldu?" sorgularının büyük çoğunluğunu ortadan kaldırır. Müşteri, süreci takip etmek için destek hattını aramak zorunda değildir.

7. Teknik Yığın (Tech Stack)

8. Uygulama Sürecindeki Teknik Zorluklar

Her mimari kararın bir bedeli vardır. Bu bölümde karşılaştığımız gerçek teknik engelleri ve nasıl çözdüğümüzü aktarıyoruz.

8.1 ERP API Sınırlılıkları

Bazı ERP sistemleri modern REST API'dan ziyade SOAP ya da XML-RPC tabanlı ara yüzler sunar. n8n bu durumu HTTP Request node'unun XML payload desteğiyle yönetebilmekle birlikte, hata mesajlarının parse edilmesi için özel bir adaptör servis (Node.js/Express) yazmak gerekti.

Bazı ERP örneklerinde ise stok güncellemesi API üzerinden değil, yalnızca veritabanına doğrudan yazma (stored procedure çağrısı) ile yapılabiliyordu. Bu durumlarda n8n doğrudan PostgreSQL node'unu kullanarak ERP'nin kendi stored procedure'larını tetikler.

8.2 Pazaryeri API Rate Limit Yönetimi

Trendyol Seller API'sının dakika bazlı istek sınırlamaları vardır. Yoğun iade dönemlerinde (Büyük indirim sonrası gibi) onlarca eş zamanlı stok güncelleme isteği göndermek bu limitleri aşabiliyordu.

Çözüm olarak n8n iş akışına bir kuyruk mekanizması eklendi. Stok güncelleme talepleri PostgreSQL'deki bir sync_queue tablosuna yazılır; ayrı bir n8n Cron node'u bu kuyruğu belirli aralıklarla drene eder ve rate limit dahilinde kalmayı garanti eder.

8.3 Çift Kayıt Riski

Ağ sorunları nedeniyle webhook event'inin n8n'e iki kez ulaşması durumunda aynı iade için iki kez stok artışı yaşanabilirdi. Bu riski bertaraf etmek için her iade talebine UUID bazlı bir idempotency key atandı. n8n, işlem başlamadan önce bu key'in return_requests tablosunda processed durumunda olup olmadığını kontrol eder.

9. Sonuçlar

Sistem 6 haftalık geliştirme ve 2 haftalık pilot sürecin ardından canlıya alındı. İlk 3 ay sonunda ölçülen metrikler şu tabloyu ortaya koydu:

Operasyonel Metrikler

Müşteri Deneyimi Metrikleri

Ekip Üretkenliği

10. Genel Değerlendirme

Bu projenin teknik olarak en kritik kararı, n8n'i tüm sistemlerin "konuştuğu" merkezi katman olarak konumlandırmaktı. ERP, pazaryerleri, depo terminali ve iletişim araçları zaten kendi işlevlerini yerine getiriyordu; eksik olan, bu sistemlerin birbirleriyle tutarlı ve güvenilir biçimde iletişim kurmasını sağlayan orkestrasyon katmanıydı.

Önemli bir gözlem: otomasyon, çalışanların işini elimine etmedi. Depo personeli hâlâ fiziksel kalite kontrolü yapıyor, muhasebe hâlâ para iadesi işlemini onaylıyor. Değişen şey, bu kararların sisteme giririlmesiyle tetiklenen bilgi akışının artık insan hafızasına ya da dikkatine bağlı olmaması.

Operasyonel süreçlerde otomasyonun değerini en net gösteren ölçüt, "unutulan vaka" sayısıdır. İnsan kaynaklı süreçlerde bu sayı sıfıra asla ulaşamaz — yoğun günler, hastalık, devir teslim kopukluğu kaçınılmaz olarak bir şeylerin gözden kaçmasına yol açar. Sistemin bu projedeki en somut başarısı, "unutulan iade vakası" metriğini üç ay boyunca sıfırda tutabilmiş olmasıdır.

Bu vaka çalışması Hız Dijital portföyünün bir parçasıdır. Benzer bir operasyonel dönüşüm projesi için iletişime geçin.