Pazaryeri Projesi Nasıl Planlanır?

Pazaryeri Kurulumuna Yazılımdan Değil, Proje Tanımından Başlayın

Pazaryeri projesi yalnız bir e-ticaret sitesi kurma işi değildir. Aynı sistem içinde müşteri, satıcı, ürün veya hizmet, ödeme, sipariş, komisyon, hakediş, teslimat, iade, güven ve destek süreçleri birlikte çalışır.

Bu nedenle ilk karar tema, ekran veya teknoloji olmamalıdır. Önce hangi ticari problemi çözdüğünüzü, kimleri bir araya getirdiğinizi ve işlemin nasıl tamamlanacağını tanımlayın.

1. Pazaryerinin Tek Cümlelik Tanımını Yazın

Projenizi şu yapıyla tanımlayın: Kim, kimden, neyi, hangi temel fayda nedeniyle, nasıl satın alacak veya talep edecek?

Bu cümle hedef kullanıcıyı, arzı ve temel değer önerisini aynı anda sınırlar.

2. Alıcıyı Somutlaştırın

• B2C son tüketici mi?
• B2B işletme satın almacısı mı?
• Belirli sektör veya meslek grubu mu?
• Belirli şehir/bölge mi?
• Tek seferlik mi, tekrar satın alma potansiyeli yüksek mi?

Hedef müşteri tanımı ne kadar somutsa kategori, arama, ödeme, teslimat ve destek gereksinimleri o kadar doğru çıkar.

3. Satıcı Profilini Tanımlayın

• Üretici.
• Marka.
• Distribütör.
• Toptancı.
• Perakendeci.
• Hizmet sağlayıcı.
• Bireysel satıcı.

Satıcı tipi doğrulama, sözleşme, ürün aktarımı, fiyatlama, vergi ve operasyon akışlarını doğrudan etkiler.

4. İşlem Nesnesini Belirleyin

Platformda ne işlem göreceğini açıkça tanımlayın.

• Fiziksel ürün.
• Dijital ürün.
• Hizmet.
• Rezervasyon.
• Teklif/RFQ.
• İkinci el ürün.
• Abonelik veya tekrar sipariş.

Fiziksel ürün pazaryeri ile hizmet pazaryerinin katalog, stok, teslimat ve uyuşmazlık mantığı aynı değildir.

5. Platformun Rolünü Tanımlayın

Platform yalnız satıcıları listeleyen bir alan mı, işlemi uçtan uca yöneten bir pazaryeri mi?

• Satıcı kabul/doğrulama.
• Ürün moderasyonu.
• Checkout ve ödeme.
• Sipariş ayrıştırma.
• Kargo entegrasyonu.
• Komisyon/hakediş.
• İade ve uyuşmazlık.
• Müşteri desteği.

Üstlendiğiniz her rol yazılım, operasyon ve sorumluluk kapsamını büyütür.

6. İşlem Akışını Bir Cümleden Sürece Dönüştürün

1. Müşteri platforma gelir.
2. Arama/kategoriyle ürünü bulur.
3. Satıcı teklifini değerlendirir.
4. Sepete ekler.
5. Teslimat ve ödeme seçer.
6. Ödeme tamamlanır.
7. Sipariş satıcı bazında ayrışır.
8. Satıcı hazırlar ve gönderir.
9. Müşteri teslim alır.
10. İade/uyuşmazlık gerekirse yönetilir.
11. Satıcı hakedişi sonuçlanır.

Bu akışın her adımı daha sonra kabul testi senaryosuna dönüşecektir.

7. Gelir Modelini Baştan Tanımlayın

• Kategori veya satıcı bazlı komisyon.
• Sabit işlem ücreti.
• Satıcı aboneliği.
• Listeleme veya ek hizmet.
• Reklam/görünürlük.
• Lojistik veya diğer katma değerli hizmetler.

İlk sürümde tüm gelir modellerini aynı anda kurmak yerine ana gelir motorunu seçin. Komisyon kullanılıyorsa matrah ve ters kayıt mantığı proje gereksinimine eklenmelidir.

8. Operasyon Sınırlarını Belirleyin

Kurulum öncesi hangi işleri platform ekibinin, satıcının ve dış sağlayıcının yapacağını yazın.

• Ürün girişi kimde?
• Stok/fiyat kimden gelir?
• Kargo sözleşmesi kimde?
• İade adresi kimde?
• Müşteri desteğini kim verir?
• Uyuşmazlıkta kim karar verir?
• Satıcı ödemesini hangi yapı yürütür?

Sorumluluk belirsizliği yazılım ekranlarında ve destek operasyonunda çakışma yaratır.

9. Coğrafi Kapsamı Sınırlayın

İlk günden her şehir veya ülkeyi hedeflemek zorunda değilsiniz.

• Hedef ülke.
• Hedef şehir/bölge.
• Teslimat kapsamı.
• Para birimi.
• Dil.
• Yerel ödeme/kargo ihtiyaçları.
• Kategoriye özgü mevzuat gereksinimleri.

Yeni ülke, yalnız çeviri değil; ödeme, lojistik, vergi, sözleşme ve destek açısından ayrı proje olabilir.

10. Kategori Kapsamını Tanımlayın

Kategori sayısını katalog görünümü için değil, arz-talep yoğunluğu için planlayın.

11. Minimum Çalışabilir Pazaryeri Kapsamı

MVP, eksik veya güvensiz ürün demek değildir. İlk ticari döngüyü uçtan uca güvenilir biçimde tamamlayan en küçük kapsamdır.

• Müşteri üyelik/checkout.
• Satıcı başvuru ve panel.
• Ürün/kategori.
• Sepet.
• Ödeme.
• Sipariş ayrıştırma.
• Komisyon/hakediş.
• Kargo/teslimat.
• İptal/iade.
• Admin operasyon.
• Temel raporlama.

İlk sürümde ileri seviye sadakat, reklam platformu veya karmaşık kişiselleştirme gibi özellikler sonraki fazlara bırakılabilir.

12. Must / Should / Later Önceliklendirmesi

Must

Canlı ticari döngünün çalışması için zorunlu.

Should

İlk sürümde yüksek değerli fakat geçici süreçle yönetilebilecek.

Later

Gerçek kullanım verisi geldikten sonra geliştirilecek.

Her talebe 'neden ilk sürümde gerekli?' sorusunu sorun.

13. Hazır Platform mu Özel Geliştirme mi?

Kararı özellik listesinden önce süreç uyumuna göre verin.

• Çok satıcılı yapı hazır mı?
• Satıcı paneli olgun mu?
• Tek sepet/sipariş ayrıştırma var mı?
• Komisyon/hakediş destekleniyor mu?
• Ödeme/kargo entegrasyonları uygun mu?
• API ve entegrasyon yeteneği var mı?
• Ölçeklenebilir mi?
• Veri erişimi ve sahipliği net mi?
• Destek ve sürüm yönetimi nasıl?

Hazır altyapı çekirdek gereksinimlerin büyük bölümünü karşılıyorsa sıfırdan geliştirme süresi ve riskinden kaçınılabilir.

14. Gereksinim Matrisi Oluşturun

Her gereksinimi kullanıcı, süreç ve kabul kriteriyle birlikte yazın.

Bu yaklaşım 'satıcı paneli olsun' gibi belirsiz maddeleri test edilebilir hale getirir.

15. Entegrasyon Haritası

• Ödeme sağlayıcısı.
• Kargo firmaları.
• ERP/ön muhasebe.
• E-fatura/e-dönüşüm.
• CRM.
• Pazarlama iletişimi.
• Analitik.
• Arama veya diğer servisler.

Her entegrasyon için veri yönü, ana veri kaynağı, hata davranışı ve manuel yedek süreç tanımlanmalıdır.

16. Veri Sahipliğini Baştan Belirleyin

Ürün, stok, fiyat, sipariş ve müşteri verisinin hangi sistemde ana kayıt olduğunu belirleyin.

17. Proje Rolleri

• Proje sahibi.
• Ticari model sorumlusu.
• Kategori/satıcı operasyonu.
• Müşteri operasyonu.
• Finans/hakediş.
• Teknik/entegrasyon.
• İçerik/katalog.
• Hukuk/uyum danışmanlığı.
• Test ve kabul sorumlusu.

Küçük ekipte bir kişi birden fazla rol üstlenebilir; ancak sorumluluğun adı yine de açık olmalıdır.

18. Risk Kaydı

• Yetersiz satıcı arzı.
• Ödeme entegrasyonu gecikmesi.
• Kargo sözleşmesi hazır değil.
• Ürün verisi düşük kaliteli.
• Hakediş kuralı belirsiz.
• Hukuki metinler gecikiyor.
• Satıcı entegrasyonları hazır değil.
• Test için yeterli gerçekçi veri yok.

Her risk için olasılık, etki, sorumlu ve azaltma aksiyonu yazın.

19. Başarı Kriterlerini Yayından Önce Yazın

• Minimum aktif satıcı.
• Minimum satışa hazır ürün/teklif.
• Ödeme başarı hedefi.
• Sipariş ayrıştırma testi.
• Kargo takip başarısı.
• Finansal mutabakat.
• Kritik hata sayısı.
• İlk dönem likidite hedefleri.

Başarı kriteri yayın sonrası keyfî biçimde değiştirilmemelidir; başlangıç hipotezinizle karşılaştırılmalıdır.

20. Proje Yol Haritası

1. İş modeli ve kapsam.
2. Altyapı seçimi.
3. Bilgi mimarisi/katalog.
4. Satıcı onboarding.
5. Ödeme ve finans.
6. Kargo/teslimat.
7. Entegrasyonlar.
8. İçerik ve politikalar.
9. Uçtan uca test.
10. Pilot satıcı ve müşteri.
11. Canlıya geçiş.
12. İlk 30/90 gün optimizasyon.

Uygulama: Pazaryeri Proje Özeti

1. Pazaryerinizi tek cümlede tanımlayın.
2. Alıcı ve satıcı profilini yazın.
3. İşlem nesnesini belirleyin.
4. Platformun üstleneceği rolleri seçin.
5. İlk kategori ve coğrafi kapsamı yazın.
6. Ana gelir modelini belirleyin.
7. MVP için Must/Should/Later listesi oluşturun.
8. Entegrasyonları listeleyin.
9. Proje rollerini atayın.
10. En önemli beş riski yazın.
11. Yayın öncesi beş başarı kriteri belirleyin.

KMK Pazaryeri Platformunu İnceleyinHazır çok satıcılı altyapının proje gereksinimlerinizle nasıl eşleşebileceğini inceleyin.

Proje kapsamını oluşturduk. Sonraki derste bu kapsamı gerçek bir kategori, ürün, satıcı ve katalog mimarisine dönüştüreceğiz.