B2B Portalda İskonto Onay Süreci Nasıl Kurgulanır?

Kısa cevap: B2B portalda iskonto onay süreci; müşteri tipi, ürün grubu, sipariş toplamı ve satış rolüne göre hangi indirimin otomatik uygulanacağını, hangisinin ek onay isteyeceğini önceden tanımlayan bir iş kurgusudur. Amaç sadece fiyatı düşürmek değil; marjı korurken satış ekibini yavaşlatmadan teklif ve sipariş akışını yönetmektir.

Birçok şirkette iskonto kararları hâlâ e-posta, telefon veya mesajlaşma üzerinden ilerler. Bu da aynı müşteri için farklı fiyatlar verilmesine, siparişin beklemesine ve finans ile operasyonun son anda devreye girmesine neden olabilir. B2B portal kullanan işletmeler için daha güvenli yaklaşım; kuralları portal, CRM ve gerekiyorsa ERP tarafında netleştirmek, istisna gerektiren durumları görünür bir onay akışına taşımaktır.

Bu çerçeveyi kurarken önce müşteri verisi ve satış süreci standardını netleştirmek faydalıdır. Eğer müşteri kartları, teklif akışı ve yetki mantığı hâlâ dağınıksa önce CRM sistemi seçimi ve kurulum yaklaşımını oturtmak işleri kolaylaştırır.

B2B portalda iskonto onay süreci ne zaman gerekli?

Her B2B portal aynı seviyede onay kurgusuna ihtiyaç duymaz. Ancak bayi, toptan müşteri veya kurumsal hesaplara özel fiyat çalışılıyorsa; satış temsilcileri manuel indirim tanımlıyorsa; kampanya, ödeme vadesi ve ürün bazlı istisnalar sık yaşanıyorsa iskonto onayı kritik hale gelir. Çünkü sorun yalnızca fiyatın ne olduğu değil, o fiyatın kim tarafından, hangi sınırlar içinde ve hangi kayıtla verildiğidir.

• Standart fiyat listesi var ama bazı müşteriler farklı oran talep ediyorsa
• Ürün gruplarına göre kârlılık değişiyor ve her indirim aynı etkiyi yaratmıyorsa
• Satış, finans ve operasyon aynı sipariş üzerinde farklı yorum yapıyorsa
• Portalda görünen fiyat ile arka ofiste onaylanan fiyat arasında kopukluk yaşanıyorsa

Bu tip durumlarda portalın sadece katalog gösteren bir yapı olmaktan çıkıp ticari kural motoru gibi çalışması gerekir. Benzer şekilde stok, sipariş ve veri akışları zaten karmaşıksa stok yönetimi disiplinini de aynı proje içinde düşünmek daha sağlıklı olur.

Kurallar tanımlanırken hangi değişkenler netleştirilmeli?

Sağlıklı bir iskonto onay akışı, yazılım ekranından önce iş kuralı seviyesinde tanımlanmalıdır. “Gerekirse yönetici onaylasın” gibi genel bir ifade çoğu zaman yetmez. Kimin hangi senaryoda onay vereceği ve hangi sınırların otomatik çalışacağı açık olmalıdır.

Müşteri grubu ve iskonto limitleri

İlk karar katmanı müşteri segmentidir. Bayi, alt bayi, kurumsal müşteri, proje hesabı veya yüksek hacimli alıcı için aynı indirim mantığı kullanılmayabilir. Bu nedenle her segment için:

• varsayılan fiyat listesi
• maksimum otomatik iskonto oranı
• hangi eşiğin üstünde satış müdürü veya finans onayı gerektiği
• özel anlaşmalı müşteri istisnaları

ayrı ayrı tanımlanmalıdır.

Ürün, kategori ve kampanya istisnaları

Tüm ürünlerde aynı indirim serbestliği verilirse yüksek hacimli ama düşük marjlı kalemlerde sorun çıkabilir. Bu yüzden kural seti ürün ailesi, marka, kategori veya kampanya dönemi bazında ayrılmalıdır. Örneğin hızlı dönen ürünlerde sınırlı indirim serbestliği, proje bazlı ürünlerde ise teklif bağlı özel onay akışı gerekebilir.

Eğer sipariş akışı kampanya, ödeme veya teslimat senaryoları ile birlikte yönetiliyorsa; kuralları tek ekranlık bir portal işi gibi değil, daha geniş bir operasyon tasarımı olarak ele almak gerekir. Bu bakış açısı için otomasyon çözümlerinde süreç tasarımına odaklanmak faydalıdır.

Onay akışı hangi rollerle kurgulanmalı?

İskonto kurgusunda en sık hata, herkese aynı yetkiyi vermek ya da tam tersine tüm istisnaları tek kişide toplamak olur. Pratikte rol bazlı bir yapı daha sürdürülebilirdir:

• Satış temsilcisi: belirli limitlere kadar indirim uygulayabilir, üstünü onaya gönderir.
• Satış yöneticisi: müşteri ilişkisi ve ciro hedefi açısından istisnaları değerlendirir.
• Finans: vade, açık risk, cari durum ve tahsilat disiplini açısından kontrol sağlar.
• Operasyon veya ürün yönetimi: stok, tedarik veya teslimat etkisi olan durumlarda devreye girer.

Buradaki amaç onay zincirini uzatmak değil, kararın neden alındığını görünür hale getirmektir. Portal içinde “beklemede”, “ek bilgi gerekli”, “onaylandı”, “reddedildi” gibi durumların kayıt altında tutulması; sonradan fiyat tartışmalarını azaltır ve müşteri iletişimini netleştirir.

B2B portal, CRM ve ERP arasında hangi veriler eşleşmeli?

İskonto onay süreci yalnızca portal ekranında kurgulanırsa bir süre sonra veri kopukluğu yaşanır. Portalda görülen müşteri sınıfı, CRM'deki hesap yapısı veya ERP'deki cari koşullar farklıysa onay kararı güvenilir olmaz. Bu nedenle en az şu alanların sistemler arasında tutarlı ilerlemesi gerekir:

• müşteri tipi ve hesap segmenti
• yetkili kullanıcı ve hesap sahibinin rolü
• fiyat listesi ve özel iskonto tanımı
• sipariş toplamı, ürün kırılımı ve kampanya bilgisi
• ödeme şekli, vade ve gerekiyorsa açık risk notu
• onay durumu, açıklama notu ve zaman damgası

Özellikle sipariş sonrası tahsilat veya ödeme akışı etkileniyorsa, portal tasarımını online ödeme altyapısı ile birlikte düşünmek gerekir. Böylece onaylı fiyatın hangi ödeme şartıyla ilerleyeceği daha net hale gelir.

Gecikme ve hata riskini azaltmak için hangi kontroller gerekli?

İyi bir iskonto onay süreci sadece kural tanımlamaz; kuralın işletilmesini de kolaylaştırır. Bunun için şu kontroller faydalıdır:

• Onay bekleyen kayıtlar için rol bazlı liste ekranı
• İskonto sebebi seçimi veya kısa açıklama alanı
• Limit aşımı olduğunda otomatik bildirim
• Aynı müşteri için tekrarlanan istisnaların raporlanması
• Onaysız siparişin sevk veya tahsilat akışına geçmesini engelleyen durum kontrolü

Bu kontroller sayesinde ekip, tek tek fiyat tartışmak yerine hangi müşteride hangi kuralın sık kırıldığını görebilir. Süreç çok sık istisna üretiyorsa sorun bazen ekipte değil, baştan yanlış tanımlanmış fiyat segmentasyonundadır.

Sık sorulan sorular

Tüm iskontolar yönetici onayına mı gitmeli?

Hayır. Küçük ve tekrar eden indirimlerin otomatik sınırlar içinde ilerlemesi genelde daha verimlidir. Onay akışı daha çok limit aşımı, özel müşteri anlaşması veya yüksek etkili istisnalar için kullanılmalıdır.

İskonto kuralları sadece portal içinde tutulabilir mi?

Tutulabilir; ancak müşteri verisi, ödeme koşulu veya cari limit farklı sistemlerde yönetiliyorsa tek başına portal kurgusu yetersiz kalabilir. Bu durumda CRM ve ERP ile veri eşleşmesi planlamak gerekir.

İlk kurulumda hangi senaryolar önceliklenmeli?

En sık kullanılan müşteri segmentleri, en çok sipariş gören ürün grupları ve en çok manuel onay gerektiren istisnalar genelde ilk faz için en doğru başlangıç noktasıdır. Tüm istisnaları aynı anda modele taşımak yerine en çok tekrar eden akışı düzenlemek daha güvenlidir.

Sonraki adım

Eğer satış ekibiniz farklı müşterilere farklı iskonto kuralları uyguluyor, onaylar mesajlaşma veya e-posta üzerinden ilerliyor ve sipariş sonrası finans/operasyon tarafında tekrar kontrol ihtiyacı doğuyorsa; B2B portal kurgusunu tek başına ekran tasarımı olarak değil süreç entegrasyonu olarak ele almak gerekir. Ekolaykod, portal, CRM ve arka ofis akışlarını birlikte planlamak isteyen ekipler için entegrasyon odaklı çözüm yaklaşımı sunar.

Bu yazıdaki temel amaç, indirim kararlarını kişiden bağımsız bir kurala bağlamak ve sipariş sürecini daha izlenebilir hale getirmektir. Doğru kurgu; satış esnekliğini korurken fiyat, onay ve operasyon disiplinini aynı çatı altında toplar.