Yönetişim
Teklif yaşam döngüsü yönetişimi
Bir teklif; yaşam döngüsü durumunu, uygunluk kurallarını, önceliğini ve tüketim sınırlarını birlikte taşıyan tek bir yapılandırma nesnesi olarak yönetilir. Durumu değiştirmek teklifin gösterilmeye uygun olup olmadığını belirler; aynı yapılandırma her müşteri değerlendirilirken harcama, kullanım ve stok sınırlarını gerçek zamanlı uygular; kimin oluşturup değiştirebileceği rol tabanlı denetlenir.
Bu sayfa şu soruları yanıtlar
- Bir teklifin hangi yaşam döngüsü durumları olabilir?
- Bir teklifi kim oluşturabilir ya da değiştirebilir?
- Bütçe ve stok sınırları nasıl uygulanır?
- Teklif değişikliklerinin denetim izi var mı?
Aç-kapa anahtarından fazlası
Kurumsal teklif programları bir teklifin tanımlı durumlardan geçmesini, kimin değiştirebileceğinin yönetilmesini ve bütçe, kullanım ya da stok sınırına ulaşıldığı anda kendini göstermeyi bırakmasını ister; müşteriye işletmenin artık karşılayamayacağı bir teklif hiç gösterilmeden. Durum, hedefleme ve yığınlama kuralları, öncelik ve sınırlar tek nesnede olduğundan durumu değiştirmek teklifin gösterilebileceği her yerdeki uygunluğu denetler; eşitlenmesi gereken ayrı bir sistem yoktur.
Yaşam döngüsü durumları
- TaslakYapılandırma kuruluyor; sunuma uygun değil. Tasarım güncellemeleri serbestçe uygulanır.
- PlanlandıYapılandırıldı ve gelecekteki bir tarih ve saatte etkinleşmek üzere kuyrukta; hâlâ düzenlenebilir.
- EtkinGösterilmeye uygun; her müşteri için hedefleme kuralları, öncelik ve sınırlara göre değerlendirilir.
- DuraklatıldıYapılandırmayı, geçmişi ya da birikmiş tüketim sayısını yitirmeden uygunluktan geçici olarak çekildi.
- Süresi dolmuşUygunluk penceresi kalıcı olarak geçti; raporlama ve denetim için tutulur ama artık değerlendirilmez.
Dışarıda tanımlanan teklifler
Bir teklifin yaşam döngüsü dış bir sadakat ya da teklif yönetim sisteminde yaşıyorsa durum geçişlerini o sistem yönetir ve platform güncel durumu API ile yansıtır; hedefleme ve mesajlaşma kayıt sistemiyle tutarlı kalır.
Onay kapısı ve rol tabanlı denetim
Bir teklif yapılandırmasını kimin oluşturup düzenleyip kaldırabileceği rol tabanlı izin modeliyle yönetilir. Roller, bir kullanıcının kuralları, sınırları ya da durumu değiştirmeden teklifin yapılandırmasını ve performansını görebileceği biçimde kapsamlanabilir. Değişiklikler sürümlenir ve zaman damgalıdır: ne değişti, ne zaman, kim tarafından.
Belirli durum geçişlerinden önce resmi çok aşamalı bir onay kapısı, örneğin Taslak'tan Etkin'e geçmeden üst düzey imza, bu rol ve sürümleme temelinin üstüne uygulamada kapsamlanabilir. Bugün yerleşik, hazır bir iş akışı değildir.
Bütçe ve stok korkulukları
| Korkuluk | Nasıl çalışır |
|---|---|
| Harcama ya da kullanım sınırı | Toplam teklif kullanımına yapılandırılmış sınır; her müşteri değerlendirmesinde güncel sayıyla karşılaştırılır. |
| Stok sınırı | Kullanılabilir stoğa bağlı sınır; stok gerçeği dış bir sistemdeyse gerçek zamana yakın bir akıştan alınır. |
| Gerçek zamanlı tüketim görünürlüğü | Teklif gösterildikçe ya da kullanıldıkça güncel sayı güncellenir; bir sonraki değerlendirme en son durumu yansıtır. |
| Otomatik bastırma | Sınıra ulaşıldığında teklif sonraki uygunluk denetimlerinden kendiliğinden çıkarılır; elle adım gerekmez. |
Geçersiz kılma ve denetim izi
Teklifin yapılandırmasındaki, durumundaki, kurallarındaki, önceliğindeki ya da sınırlarındaki her değişiklik sürümlenir ve zaman damgalanır; bir sınırı yükseltmek ya da duraklatılmış teklifi yeniden etkinleştirmek gibi elle geçersiz kılmalar dahil. Sınıra yaklaşan tüketim sert kesimden önce uyarı olarak gösterilebilir; teklif sahibi ancak sunum durunca öğrenmek yerine önceden görür.
TemasCRM'de
Her iddia bu ürünle karşılaştırılır: canlı olan, kısmen olan, planlı olan ve bu ürünün tasarımı gereği uygulanmayan.
1 Canlı2 Kısmi3 Planlı
- Tek yapılandırma nesnesinde yaşam döngüsü durumuKısmi
Kampanya önce taslaktır, sonra çalışıyor, sonra tamamlandı olur; yalnız taslak değiştirilir ya da silinir ve hiçbir şey onu zamanlamaz, duraklatmaz ya da sürdürmez. Ayrı bir teklif nesnesi yok.
Kampanyalar - Etkinleştirmeden önce onay kapısıCanlı
Şablon, bir ADMIN ya da MANAGER onaylayana kadar taslaktır ve şablonu onaylanmamış kampanya gönderimde reddedilir (template_not_approved); onu yalnız bir ADMIN ya da MANAGER gönderir. Kampanyanın kendi onay isteği yoktur ve onaylar ekranı örnek katmandadır.
Şablonlar - Her değerlendirmede denetlenen tüketim sınırlarıPlanlı
Bir kupon listesi kalanı sayar; sayı istendiğinde kodlardan ve dağıtım defterinden hesaplanır. Hiçbir kampanya havuz kullanmaz ve teklif üzerinde harcama sınırı modellenmedi.
Kupon listeleri - Dış akıştan stok sınırlarıPlanlı
Bağlı bir stok akışı yok; stoğa duyarlı bastırma bir ticaret entegrasyonunu bekliyor.
- Sürümlü, zaman damgalı değişiklik denetim iziKısmi
Denetim günlüğü campaign.create, campaign.update, campaign.delete ve campaign.dispatch kaydeder; yalnız taslak değiştirilir, dolayısıyla gönderilmiş kampanya bir kayıttır.
Kampanyalar - Kesimden önce sınır uyarılarıPlanlı
Tanılama panosu tükenmiş havuzları sonradan bildirir; yaklaşan sınır uyarısı henüz üretilmiyor.