B2B satış operasyonlarında en çok zaman kaybettiren alanların başında onay süreçleri gelir. Teklif hazırlanır, indirim talebi açılır, ödeme vadesi konuşulur, sözleşme revize edilir. Sonrasında süreç e-posta zincirlerine, Excel dosyalarına ve mesajlaşma uygulamalarına dağılır. Ortaya çıkan tablo da tanıdıktır: geciken dönüşler, kaybolan versiyonlar ve kimin neyi ne zaman onayladığının belirsizleşmesi.

Onay akışı dijitalleştirme, bu dağınık yapıyı kurallı, izlenebilir ve ölçülebilir bir düzene dönüştürür. Buradaki amaç yalnızca bir form ekranı açmak değildir. Asıl hedef, satış, finans, hukuk ve operasyon ekiplerinin belirli koşullara göre otomatik ilerleyen bir süreç içinde çalışmasını sağlamaktır. İyi kurgulanmış bir yapı; örneğin yüzde 12’nin üzerindeki indirim taleplerini otomatik olarak bölge müdürüne yönlendirebilir, 250.000 TL üstü teklifleri finans kontrolüne alabilir ya da standart sözleşme dışı maddeleri hukuk kuyruğuna düşürebilir.

Bu yazıda, B2B satışta onay süreçlerinin nasıl dijitalleştirileceğini teknik ve operasyonel açıdan ele alacağız. Nereden başlanmalı, hangi adımlar otomasyona alınmalı, hangi entegrasyonlar kritik, hangi metrikler takip edilmeli; hepsini somut örneklerle açıklayacağız.

B2B satışta en çok dijitalleşen onay akışları hangileri?

Her satış süreci aynı değildir. Yine de çoğu B2B şirkette benzer düğüm noktaları vardır. İlk adım, tüm süreci bir anda otomasyona taşımak değil, en fazla gecikme yaratan adımları belirlemektir. Pratikte 4 başlık öne çıkar.

  • Teklif onayı: Fiyat, iskonto, teslim süresi ve kapsam kontrolü.
  • İndirim onayı: Belirli oran eşiklerine göre yönetici eskalasyonu. Örnek: %10 altı otomatik, %10-%20 satış müdürü, %20 üstü genel müdür.
  • Ödeme ve vade onayı: 30 gün, 60 gün, 90 gün gibi farklı vadelerde finans onayı.
  • Sözleşme onayı: Standart taslak dışındaki maddeler için hukuk süreci.

Buradaki kritik nokta, her onayı aynı ağırlıkta değerlendirmemektir. 50.000 TL’lik standart bir yenileme teklifi ile 2 milyon TL’lik özel fiyatlandırmalı bir çerçeve anlaşma aynı iş akışından geçmemelidir. Dijital tasarım tam da burada değer üretir: koşullu dallanma.

Örneğin bir CRM kaydı üzerinden çalışan akışta şu mantık kurgulanabilir:

IF discount <= 10% THEN auto_approve
ELSE IF discount <= 20% THEN route_to_sales_manager
ELSE route_to_regional_director

Bu kadar basit görünen kurallar bile manuel takibe kıyasla ciddi fark yaratır. Çünkü süreç kişiye bağlı olmaktan çıkar, kurala bağlı hale gelir.

Mevcut süreci haritalamadan otomasyona geçmek neden risklidir?

Dijitalleştirme projelerinde sık görülen hatalardan biri, bozuk süreci doğrudan yazılıma taşımaktır. Bu durumda analog karmaşa, dijital karmaşaya dönüşür. Önce mevcut akışın net biçimde ortaya çıkarılması gerekir. En az 2 haftalık bir gözlem periyodu genellikle yeterlidir. Bu sürede şu soruların yanıtı toplanmalıdır:

  • Bir teklif ortalama kaç kişiden onay alıyor?
  • En sık gecikme hangi adımda yaşanıyor?
  • Geri dönen kayıtların ana nedeni fiyat mı, sözleşme mi, eksik veri mi?
  • Onay sürecinde kullanılan veri kaynakları nerede tutuluyor?

Buradan bir süreç haritası çıkar. İdeal yaklaşım, BPMN düzeyinde detaylı modelleme yapmak ya da en azından karar ağacını açıkça belgelemektir. Örnek bir akış şöyle olabilir: satış temsilcisi teklifi oluşturur, sistem müşteri segmentini kontrol eder, iskonto oranı eşiği aşılırsa müdür onayı ister, müşteri risk skoru belirli seviyenin üzerindeyse finans adımı eklenir, standart sözleşme seçilmediyse hukuk kuyruğu açılır.

Haritalama sırasında çoğu zaman sürprizler ortaya çıkar. Kimi şirketlerde aynı onay iki farklı kanaldan yeniden alınıyor olabilir. Bazen de karar yetkileri yazılı değildir; ekipler kişisel alışkanlıklarla ilerler. Yazılım tarafına geçmeden önce bu belirsizlikleri azaltmak gerekir. Aksi halde kullanıcı kabulü düşer.

Onay akışı dijitalleştirme mimarisi nasıl kurgulanır?

Sağlam bir kurgu için tek bir ekran yeterli değildir. En az 5 bileşen düşünülmelidir: veri kaynağı, iş kuralları motoru, görev yönetimi, bildirim altyapısı ve kayıt/iz katmanı. Bunların hepsinin ayrı ürünler olması gerekmez; özel yazılım içinde birlikte tasarlanabilir.

1. Veri kaynağı ve ana kayıt yapısı

Onay sürecinin beslendiği ana sistem çoğu zaman CRM veya ERP’dir. Teklif tutarı, müşteri tipi, ödeme koşulu, ürün grubu, para birimi gibi alanlar burada tutulur. Akışın manuel veri girişiyle başlaması hata riskini artırır. Mümkün olan her veri kaynağından bilgiler otomatik çekilmelidir.

2. Kural motoru

Kural motoru akışın kalbidir. Örnek: “Brüt marj %18’in altına düşerse satış direktörü onayı zorunlu” gibi koşullar burada tanımlanır. Başlangıçta 10-15 ana kural ile ilerlemek daha sağlıklıdır. Yüzlerce istisna ile açılan projeler bakım maliyetini büyütür.

3. Görev ve SLA yönetimi

Her onayın bir süre hedefi olmalıdır. Örneğin satış müdürü onayı için 4 saat, finans için 1 iş günü, hukuk için 2 iş günü tanımlanabilir. SLA süresi dolduğunda otomatik hatırlatma, ikinci seviye eskalasyon veya vekil kullanıcıya yönlendirme devreye girmelidir.

4. Denetim izi

Kim, ne zaman, hangi veriye bakarak karar verdi? Bu soru, özellikle yüksek hacimli satış ekiplerinde büyük önem taşır. İyi bir sistem her aksiyonu zaman damgası ile kaydeder. En az şu alanlar loglanmalıdır: kullanıcı, rol, karar tipi, önceki değer, yeni değer, tarih-saat, yorum.

Bu mimari yaklaşım hem günlük operasyonu hızlandırır hem de iç denetim ve uyumluluk ihtiyaçlarına yanıt verir.

CRM, ERP ve e-imza entegrasyonları neden kritik?

Onay akışı dijitalleştirme tek başına çalışmaz. Değer, sistemler arası veri akışında ortaya çıkar. B2B satış operasyonlarında en sık entegrasyon yapılan alanlar CRM, ERP, doküman yönetimi, e-imza ve kimlik doğrulama servisleridir.

Somut bir senaryo düşünelim. Satış ekibi CRM üzerinde bir teklif oluşturuyor. Teklif kaydedildiği anda akış motoru devreye giriyor. Tutar 500.000 TL’yi geçtiği için finans onayı açılıyor. Finans onayından sonra sistem ERP’de ön sipariş kaydı oluşturuyor. Sözleşme PDF’i doküman yönetim sistemine aktarılıyor. Son adımda e-imza platformu üzerinden müşteriye imza talebi gönderiliyor. Tüm bu zincir tek bir panelden izlenebiliyorsa operasyonel görünürlük ciddi biçimde artar.

Burada API tasarımı belirleyicidir. Örnek bir webhook olayı şöyle olabilir:

{
  "event": "quote.submitted",
  "quoteId": "Q-2026-0142",
  "amount": 500000,
  "currency": "TRY",
  "discountRate": 14,
  "customerSegment": "enterprise"
}

Bu tür olay bazlı mimari, onay sürecini sistemlerden bağımsız ama onlarla uyumlu hale getirir. Özellikle bulut tabanlı yapılarda bakım ve ölçeklenebilirlik açısından avantaj sağlar.

Mobil onay, yetki matrisi ve vekalet mekanizması nasıl tasarlanmalı?

Birçok onay gecikmesi teknik zorluktan değil, erişim eksikliğinden kaynaklanır. Yönetici seyahattedir. Müdür toplantıdadır. Hukuk ekibi ofis dışındadır. Bu nedenle mobil uyum artık ek özellik değil, temel bir gereksinimdir.

Mobil onay ekranında her bilgi gösterilmemelidir. Küçük ekranda karar için gerekli minimum veri sunulmalıdır: müşteri adı, toplam tutar, indirim oranı, marj, risk notu, sözleşme istisnası, ek dosyalar. 30 saniyede karar verilebilen ekranlar daha yüksek kullanım üretir.

Yetki matrisi de en az bunun kadar önemlidir. Örnek bir yapı:

  • 0 - 100.000 TL: takım lideri
  • 100.001 - 500.000 TL: satış müdürü
  • 500.001 TL ve üstü: direktör
  • Standart dışı ödeme vadesi: finans ek onayı
  • Standart dışı sözleşme maddesi: hukuk ek onayı

İzin, hastalık veya görev değişimi durumları için vekalet mekanizması şarttır. Başlangıç ve bitiş tarihi tanımlı vekil atama özelliği yoksa akışlar kolayca kilitlenir. Bu detay küçük görünebilir, ancak canlı kullanımda en kritik maddelerden biridir.

Başarı hangi metriklerle ölçülür?

Dijitalleşmenin etkisi hissiyatla değil, metriklerle izlenmelidir. İlk 90 günde takip edilebilecek bazı temel göstergeler vardır.

  • Ortalama onay süresi: Örneğin 26 saatten 6 saate düşüş.
  • SLA ihlal oranı: Hedef süreyi aşan kayıt yüzdesi.
  • Tekrar açılan kayıt oranı: Eksik veri veya yanlış yönlendirme nedeniyle geri dönen talepler.
  • Manuel temas sayısı: E-posta, telefon veya mesajla yapılan ek takip miktarı.
  • Onay darboğazı yoğunluğu: En çok bekleme yaratan rol veya departman.

Bu ölçümler için en az 8-12 haftalık baz veriyle karşılaştırma yapmak daha anlamlıdır. Ayrıca yalnızca hız değil, kalite de izlenmelidir. Çok hızlı onay veren ama sonradan revizyon gerektiren bir yapı, iyi tasarlanmış sayılmaz.

Raporlama ekranlarında günlük işlem adedi, aşama bazlı bekleme süresi, rol bazlı iş yükü ve reddedilme nedenleri net biçimde görünmelidir. Bu görünürlük, süreç iyileştirmenin ikinci fazını mümkün kılar.

Uygulama sırasında sık yapılan hatalar

Projelerde tekrar eden bazı problemler vardır. Bunları en başta görmek, yatırımın geri dönüşünü hızlandırır.

  • Her istisnayı ilk sürüme koymak: İlk versiyon fazla karmaşık olursa kullanıcı benimsemesi düşer.
  • Yalnızca IT projesi gibi yürütmek: Satış, finans ve hukuk aynı masada olmadığında kurallar eksik kalır.
  • E-posta onayını tamamen kaldırmadan geçiş yapmak: Çift kanal, veri tutarsızlığı üretir.
  • Log ve raporlamayı sona bırakmak: Görünmeyen süreç iyileştirilemez.
  • Rol bazlı yetkiyi netleştirmemek: Özellikle ciro eşiği ve indirim oranlarında çatışma çıkar.

Daha güvenli yaklaşım, 6 ila 8 haftalık bir pilot uygulamayla başlamaktır. Tek ürün grubu, tek bölge veya tek satış ekibi seçilir. Kurallar gerçek kullanım verisiyle test edilir. Ardından ikinci faza geçilir.

Kapanış: dijital onay akışı satış hızını kadar kontrol kalitesini de artırır

B2B satışta hız önemlidir, ancak kontrolsüz hız maliyet üretir. Onay akışı dijitalleştirme, bu iki ihtiyacı birlikte ele alır. Satış ekipleri daha hızlı hareket ederken finansal risk, sözleşme riski ve operasyonel belirsizlik daha yönetilebilir hale gelir.

En doğru başlangıç, mevcut süreci ölçmek ve dar boğazları görünür kılmaktır. Sonrasında kural bazlı, entegre ve izlenebilir bir yapı kurulur. İyi tasarlanmış bir sistem yalnızca onay vermeyi kolaylaştırmaz; kurum hafızası oluşturur, denetim izi sağlar ve ölçeklenebilir satış operasyonlarının temelini güçlendirir.

Özel yazılım yaklaşımı burada önemli avantaj sağlar. Çünkü her şirketin teklif yapısı, yetki matrisi, ERP/CRM kurgusu ve hukuk akışı farklıdır. Hazır araçlar bazı ihtiyaçları karşılar; ancak yüksek hacimli, çok katmanlı B2B süreçlerde çoğu zaman kuruma özel model daha sürdürülebilir sonuç verir.