Network Marketing
Network Marketing Platformu
Plan kuralı tek başına bir sistem değildir. Üyelik, ağaç, sipariş, dönem, hakediş ve entegrasyon katmanları aynı çekirdekte çalıştığında saha ve yönetim aynı kaydı okur.
Bayi backoffice — ekip ve kazanc
Bayinin kendi ekibini, siparislerini ve hakedisini gormesi
Gerçek ürün ekranı bekleniyor — yayın izni onaylanınca bu alana yerleşecek.
Gerçek ürün ekranı bekleniyor.
Platform omurgası
Bir katmanı seçin: hangi veri girer, ne işlenir, hangi role görünür ve hangi çıktıya gider. Katmanların kapsamı kurguya bağlı olarak değişir.
Katmanlar
Seçim yalnız renkle değil; işaret ve kenarlık biçimiyle de gösterilir. Katman sırası genel bir anlatımdır; gerçek kurgu projede tanımlanır.
Katman 01
Üye ve kimlik
Hangi veri girer
Kayıt formu, davet linki, sözleşme onayı, vergi/kimlik alanları ve rol ataması.
Ne işlenir
Tek üye kaydı oluşturulur; müşteri, bayi ve yönetici rolleri aynı kaydın üzerine yetki olarak bağlanır.
Hangi role görünür
Müşteri kendi hesabını, bayi kendi ekibini, yönetim tüm kayıtları tanımlı yetki sınırında görür.
Hangi çıktıya gider
Diğer tüm katmanların referans aldığı tekil üye kimliği.
Tek kayıt, üç farklı görünüm
Aynı olay müşteri, bayi ve yönetim tarafında farklı biçimlerde okunur; kaynak kayıt tektir. Açıklayıcı sistem şeması — ürün ekranı değildir.
Müşteri sipariş verir
Müşteri
Sipariş özeti, ödeme sonucu ve teslimat durumu kendi hesabında görünür.
Bayi
Bağlı olduğu hatta yeni hareket olarak düşer; dönem içi ekip görünümü güncellenir.
Yönetim
Sipariş operasyon kuyruğuna girer; ödeme ve stok tarafı burada izlenir.
Sipariş hacim kaydına dönüşür
Müşteri
Müşteri tarafında değişen bir şey yoktur; kayıt arka planda oluşur.
Bayi
Kişisel ve ekip hacmi, kurguya bağlı olarak ilgili bacak veya seviyede görünür.
Yönetim
Hacmin hangi siparişten geldiği tek kaynaktan izlenir.
Dönem kapanır, kural motoru çalışır
Müşteri
Süreç müşteriye yansımaz.
Bayi
Kariyer durumu ve hakediş özeti dönem sonucuna göre güncellenir.
Yönetim
Kural çalışma kaydı, uygunluk ve cap sonuçları dönem raporunda toplanır.
İade veya düzeltme gelir
Müşteri
İade sonucu ve tutar hesabında görünür.
Bayi
İlgili hacim düzeltmesi kendi özetine yansır; gerekçe kayıtlıdır.
Yönetim
Düzeltme ayrı kayıt olarak işlenir; dönem sonucu geriye doğru izlenebilir kalır.
Rol ve cihaz orkestrasyonu
Üç rol aynı çekirdeği kullanır; gördükleri yüz ve kullandıkları cihaz farklıdır.
Mobil öncelikli
Müşteri
Ürün, sipariş, ödeme ve teslimat takibi. Ağaç ya da plan mantığı müşteriye gösterilmez.
Mobil + masaüstü karışık
Bayi
Ekip, davet, kişisel/ekip hacmi, kariyer durumu ve hakediş özeti. Sahada mobil, detaylı analizde backoffice.
Masaüstü öncelikli
Yönetim
Kural tanımı, operasyon, dönem kapanışı, entegrasyon durumu ve denetim izi.
Gerçek ürün ekranı bekleniyor.
Bayi mobil — platform ozeti
Uyelik, ekip, siparis ve donem ozetinin ayni cekirdekten tek mobil ekranda okunmasi
Gerçek ürün ekranı bekleniyor.
Bayi mobil — ekip ve sponsor agaci
Bayinin mobilde kendi ekibini, sponsor bagini ve yeni katilimlari gormesi
Gerçek ürün ekranı bekleniyor.
Musteri mobil — urun ve siparis
Son musterinin bayiye bagli magazada urun secip siparis vermesi
Gerçek ürün ekranı bekleniyor.
Musteri mobil — hesap ve siparis takibi
Siparis gecmisi, teslimat durumu ve hesap bilgilerinin gorunmesi
Yönetim tarafı destekleyicidir
Kural tanımı, yetki, dönem kapanışı ve entegrasyon durumu yönetim tarafında tek yerde tutulur. Sahanın gördüğü sonuç aynı kayıttan okunur; ayrı bir hesap yapılmaz.
Operasyon konsolu — genel bakis
Siparis, bayi ve hakedis durumunun tek ekranda izlenmesi
Gerçek ürün ekranı bekleniyor — yayın izni onaylanınca bu alana yerleşecek.
Plan motoru ortak katmana nasıl bağlanır?
Plan farklılıkları parametre düzeyinde kalır; üyelik, sipariş, kariyer ve rapor katmanı ortak kalır. Açıklayıcı sistem şeması — ürün ekranı değildir.
Plan parametreleri
Ortak servisler
- Üye ve rol kaydı
- Sponsor / yerleşim ağacı
- Sipariş ve hacim kaydı
- Kariyer (rank) omurgası
- Dönem takvimi ve snapshot
- Hakediş kaydı ve rapor
Plan detayları ilgili plan sayfalarında anlatılır; burada yalnız ortak katmana bağlanma mantığı gösterilir.
Dönem kapanışı ve izlenebilirlik
Sonuçtan kaynağa geri gidebilmek, itiraz ve denetim anında en çok ihtiyaç duyulan yetenektir. Açıklayıcı sistem şeması — ürün ekranı değildir.
- 01
Olay
Sipariş, iade, kayıt veya statü değişikliği tekil kayıt olarak oluşur.
- 02
Snapshot
Dönem kapanışında ilgili veri dondurulur; sonraki değişiklik ayrı kayıt olur.
- 03
Kural çalışması
Plan parametreleri tanımlı sırayla çalışır; her satır hangi kuraldan geldiğini taşır.
- 04
Cap ve uygunluk
Üst sınırlar ve dönem uygunluğu uygulanır; elenen satır da kayıtta kalır.
- 05
Hakediş
Sonuç dönem kaydına yazılır ve saha tarafında özet olarak okunur.
- 06
Rapor ve denetim
Sonuçtan kaynağa doğru geri izleme mümkün olacak şekilde saklanır.
Modüller neye bağlı?
Bir modülün açılması, bağlı olduğu ortak kaynakların tanımlı olmasını gerektirir.
- Bayi backoffice
- Üye kaydı, ağaç, hakediş kaydı
- Ağaç ve dönem kaydı olmadan anlamlı çalışmaz.
- Entegre e-ticaret
- Üye kaydı, ürün/stok, ödeme
- Hacim kaynağı burada üretilir; kural motoru bunu okur.
- Mobil uygulama
- Üye kaydı, sipariş, ekip ve dönem özeti
- Yeni veri üretmez; aynı çekirdeği farklı yüzle gösterir.
- Raporlama
- Dönem kaydı, kural izi, sipariş kaydı
- Rapor ayrı hesap yapmaz; kaydı okur.
- Entegrasyonlar
- Sipariş, ödeme, belge, hakediş
- Her akış için kaynak sistem projede tanımlanır.
- Yönetim paneli
- Tüm katmanlar
- Kural ve yetki tanımı tek yerde tutulur.
Platform yaklaşımı ne zaman anlamlı, ne zaman zorlaşır?
Anlamlı olabilir
- Üyelik, ağaç, sipariş ve hakediş aynı veri kaynağından yürütülecekse.
- Saha ve yönetim aynı dönem sonucunu farklı yüzlerden okuyacaksa.
- Plan kurgusu zamanla değişebilecek ve kural motorunun parametrik kalması isteniyorsa.
- Muhasebe, ödeme veya lojistik tarafıyla veri alışverişi kalıcı olacaksa.
Zorlaşabilir
- Hangi sistemin hangi veride kaynak olduğu yazılı değilse entegrasyon tarafı belirsizleşir.
- Plan kuralları sözlü kaldığında dönem kapanışı ve denetim tartışmaya açık hale gelir.
- Mevcut veri farklı yerlerde ve farklı formatlarda tutuluyorsa taşıma kapsamı ayrıca netleşmelidir.
- Ağaç geçmişi eksikse geriye dönük hesap izlenebilirliği sınırlı kalır.
- Rol ve yetki sınırları tanımlanmadan panel tasarımı sağlıklı ilerlemez.
Sık sorulanlar
Kısa yanıtlar
- Plan, kazancın hangi kuralla hesaplanacağını tanımlar. Platform ise üyelik, ağaç, sipariş, dönem, hakediş, rapor ve entegrasyon katmanlarının ortak omurgasıdır. Plan genellikle bu omurganın parametresi olarak çalışır; plan değişse de üye, sipariş ve dönem kaydı aynı çekirdekte kalır.
- Amaç budur. Sipariş, hacim, ağaç ve kariyer gibi kayıtların tek kaynağı olur; paneller ve mobil uygulama bu kaydı okur, kendi kopyasını üretmez. Dış sistemler devredeyse hangi verinin kaynağının hangi sistem olduğu projede tanımlanır.
- Kurguya bağlıdır. Çoğu modül üyelik, ağaç ve sipariş katmanına bağlı olduğu için bu ortak katmanlar olmadan tek başına anlamlı çalışmaz. Kapsam belirlenirken hangi modülün hangi ortak kaynağa bağlı olduğu birlikte netleştirilir.
- Genellikle kalabilir. Bu durumda hangi tarafın sipariş, stok, fiyat ve belge için kaynak olduğu ve verinin hangi yönde aktığı yazılı olarak tanımlanır. Entegrasyonun kapsamı ve teknik uygunluğu her projede ayrıca değerlendirilir.
- Kurguya bağlı olarak yapılabilir. Sağlıklı yaklaşım, kapanan dönemin sonucunu değiştirmek yerine düzeltmeyi ayrı bir kayıt olarak işlemektir; böylece hem eski sonuç hem düzeltmenin gerekçesi geriye doğru izlenebilir kalır.
- Değişikliğin hangi dönemden itibaren geçerli olacağı, geçmiş dönemlerin nasıl korunacağı ve yeni kuralın mevcut cap/kariyer tanımlarıyla nasıl etkileşeceği önce belirlenir. Uygulama öncesinde test senaryolarıyla karşılaştırma yapılması genellikle tercih edilir.
Platform kapsamını birlikte netleştirelim
Hangi katmanların devrede olacağını, hangi verinin kaynağının hangi sistem olduğunu ve dönem kapanışının nasıl işleyeceğini konuşalım.