Teslimat ücreti, platform ekonomisinde en çok basitleştirilen kalemdir. Tek bir sayı belirlenir ve herkese uygulanır. Sorun şu ki bu sayı iki yönlü olarak yanlıştır: 500 metre ötedeki müşteri için gereğinden pahalı olduğu için sipariş kaybettirir, 6 kilometre ötedeki müşteri için gereğinden ucuz olduğu için her siparişte zarar yazdırır. Dinamik teslimat ücreti bu iki ucu birlikte düzeltmeyi hedefler; ancak yanlış kurulduğunda müşteride güven kaybı yaratma potansiyeli de yüksektir.
Önce maliyeti bilmek: bir teslimat gerçekte ne kadar tutuyor?
Fiyatlandırma tartışmasına maliyet bilinmeden girilemez. Bir teslimatın maliyeti tek bir kalem değildir ve mesafeyle doğrusal artmaz. Gerçek maliyet en az beş bileşenden oluşur.
| Bileşen | Davranışı | Not |
|---|---|---|
| Kurye zamanı | Süreyle artar | Mesafeden çok trafiğe ve bina içi süreye bağlı |
| Yakıt / enerji | Mesafeyle artar | Toplam maliyette sanılandan küçük pay |
| Mutfakta bekleme | Atama zamanlamasına bağlı | Kötü atama, maliyeti sessizce büyütür |
| Boş dönüş | Bölge yoğunluğuna bağlı | Seyrek bölgelerde en büyük gizli kalem |
| Başarısız teslimat | Olasılıksal | Adres kalitesi ve iletişimle azalır |
Bu tablodaki en öğretici satır "boş dönüş"tür. Yoğun bir mahallede kurye teslimat sonrası hemen yeni siparişe başlar; seyrek bir bölgede ise merkeze dönmek zorunda kalır ve bu süre hiçbir siparişe faturalanamaz. Bu yüzden teslimat maliyeti mesafenin değil, bölgesel sipariş yoğunluğunun fonksiyonudur.
Modelin girdileri: hangi değişken hangi ağırlıkta?
Dinamik ücret modelini kurarken en büyük tehlike, girdiyi çoğaltmaktır. On beş değişkenli bir model teoride hassastır, pratikte açıklanamaz hâle gelir ve müşteri güvenini kaybeder. Sahada dört girdi işin büyük kısmını çözer.
- 1
Mesafe kademesi
Sürekli bir formül yerine kademe kullanın: 0–2 km, 2–4 km, 4–7 km gibi. Kademe, müşteriye açıklanabilir olduğu için itiraz üretmez.
- 2
Bölge yoğunluğu çarpanı
Bölgenin geçmiş sipariş yoğunluğuna göre 0,9–1,3 aralığında bir çarpan. Bu, boş dönüş maliyetini fiyata yansıtan bileşendir.
- 3
Anlık arz/talep dengesi
Bekleyen sipariş sayısının müsait kurye sayısına oranı. Yalnızca yukarı değil aşağı da çalışmalı: kurye fazlaysa ücret düşer.
- 4
Sepet tutarı eşikleri
Belirli tutarın üzerinde ücretin kademeli düşmesi. Bu, hem sepet büyütür hem de birim başına teslimat maliyetini seyreltir.
Hava durumu beşinci bir girdi olarak eklenebilir ama dikkatli olmak gerekir. Yağışta ücretin artması operasyonel olarak doğrudur — kurye arzı düşer, süreler uzar. Müşteri tarafında ise bu artış kolayca "kötü havada fırsatçılık" olarak okunur. Uygulanabilir çözüm, artışı müşteriye değil kurye primine yansıtmak ve farkı platform payından karşılamaktır.
Şeffaflık olmadan dinamik fiyat çalışmaz
Dinamik fiyatlandırmanın başarısızlık nedenlerinin başında matematik değil iletişim gelir. Aynı restorandan dün 15 TL, bugün 24 TL teslimat ücreti gören müşteri, sistemin bozuk veya kendisinin kandırıldığını düşünür. Bu algı, ücretin doğru hesaplanmış olmasından bağımsız olarak sipariş kaybettirir.
- Ödeme ekranında ücret dökümü gösterilir: temel ücret, mesafe kademesi, yoğunluk durumu, indirimler.
- Artış nedeni tek cümleyle açıklanır: "şu anda bölgende sipariş yoğunluğu yüksek".
- Ücretin düşeceği eşik gösterilir: "sepetine 40 TL daha eklersen teslimat ücretsiz".
- Üst sınır tanımlanır ve iletilir; sınırsız artan bir ücret hiçbir açıklamayla kabul görmez.
- Fiyat, sepete ürün eklendikçe değil yalnızca tanımlı eşiklerde değişir — her tıklamada oynayan fiyat güven kırar.
Kampanya motoru: kuralların çatışmasını yönetmek
Teslimat ücreti tek başına durmaz; kampanyalarla aynı sepette buluşur. "İlk siparişte 60 TL indirim", "ücretsiz teslimat rozeti", "iki alana bir bedava" ve "200 TL üzeri kargo bedava" aynı anda geçerli olduğunda hangisinin uygulanacağı belirsizse sonuç ya müşteri şikâyeti ya beklenmedik zarar olur.
Bu yüzden kampanya motoru, indirim listesi değil bir öncelik ve birleşebilirlik modeli olarak tasarlanmalıdır. Her kampanya için üç özelliğin tanımlanması gerekir: uygulama sırası, başka kampanyalarla birleşebilir mi, ve hangi tutar üzerinden hesaplanır.
| Kampanya tipi | Uygulama sırası | Birleşebilir mi | Hesap tabanı |
|---|---|---|---|
| Ürün bazlı indirim (2 al 1 öde) | 1 | Evet | Kalem tutarı |
| Sepet yüzde indirimi | 2 | Kısıtlı | İndirimli kalem toplamı |
| Kupon (tutar indirimi) | 3 | Kısıtlı | Sepet ara toplamı |
| Ücretsiz teslimat | 4 | Evet | Teslimat ücreti kalemi |
| Cüzdan/puan kullanımı | 5 | Evet | Genel toplam |
Sıranın önemi bir örnekle netleşir: %20 sepet indirimi ile 60 TL kupon birlikte kullanıldığında, kuponun indirimden önce mi sonra mı uygulandığı nihai tutarı değiştirir. Bu kural sistemde açıkça tanımlanmazsa her geliştirici farklı varsayımla kod yazar ve tutarsızlık kaçınılmaz olur.
Nasıl test edilir: A/B olmadan yayına alma
Fiyatlandırma değişiklikleri, etkisini yalnızca dönüşüm oranında değil sepet tutarında, sipariş sıklığında ve iptal oranında da gösterir. Bu yüzden tek metriğe bakan bir test yanıltıcıdır: dönüşüm düşerken sepet tutarı arttığı için toplam kâr yükselmiş olabilir.
- Bölge bazlı kademeli açılım: modeli tek bir ilçede açın, benzer bir ilçeyi kontrol grubu olarak bırakın.
- En az iki hafta bekleyin: hafta içi/hafta sonu ve maaş dönemi etkilerini görmek için gerekli minimum süre.
- Metrik setini birlikte izleyin: dönüşüm, ortalama sepet, sipariş başına katkı, iptal oranı, tekrar sipariş oranı.
- Müşteri destek taleplerini kodlayarak sayın: "teslimat ücreti" gerekçeli talep sayısı en hızlı uyarı sinyalidir.
- Geri alma planı hazır olsun: modeli tek anahtarla eski sabit ücrete döndürebilmek zorunludur.
- modelde yeterli olan girdi sayısı
- 4modelde yeterli olan girdi sayısı
- anlamlı test için minimum süre
- 2 haftaanlamlı test için minimum süre
- birlikte izlenmesi gereken metrik
- 5birlikte izlenmesi gereken metrik
Dinamik fiyatlandırmada asıl ürün fiyat değil, fiyatın açıklanabilirliğidir.
Kapanışta pratik bir öneri: modeli kurmaya mesafe kademeleri ve sepet eşikleriyle başlayın, yoğunluk çarpanını ancak elinizde bölge bazlı en az iki aylık veri olduğunda ekleyin. Anlık arz/talep bileşeni ise en son gelmeli — çünkü en çok açıklama gerektiren ve en hızlı güven kaybettirebilen bileşen odur.
Kendi operasyonunda uygulamak ister misin?
Sektörüne özel otomasyon senaryolarını inceleyebilir veya mevcut verinizin nasıl kullanılabilir hâle getirileceğini birlikte planlayabiliriz.