Yönetici onay kapısı: indirimli teklifi kim onaylar?

Cuma 17:20. Satış temsilcisi çeyreğin son teklifini göndermek üzere. Müşteri sabah aradı ve "bugün karar veriyoruz, ama listenin yüzde yirmi altına inmeniz gerek" dedi. Temsilcinin elinde üç yıllık bir ilişki, bir de bu ay tutmayan bir kota var. Teklifi açıyor, satır indirimini örnek olsun diye yüzde yirmi iki yapıyor, PDF'i üretip gönder tuşuna basıyor. Onay isteyeceği yönetici o saatte uçakta. Pazartesi sabahı finans tarafı tutarı görünce tek bir soru soruyor: bu indirimi kim onayladı? Cevap yok. Çünkü onaylayan kimse yok, yalnızca gönderen var.

Bu yazı "gönder" tuşuyla "onayla" tuşu arasındaki o boşluğu kapatmakla ilgili. Önce indirim yetkisinin neden yazılı bir kurala bağlanması gerektiğini konuşuyoruz; sonra kapının tutar üzerinden mi marj üzerinden mi açılacağına bakıyoruz. Ardından marj tabanının nasıl hesaplandığına, yetki matrisinin kaç kademeli olması gerektiğine, onayın ne kadar sürmesi gerektiğine, bekleyen teklifin görünür bir kuyrukta nasıl tutulacağına, reddedilen teklifin nasıl geri döndüğüne ve kararın izinin nerede saklandığına geçiyoruz. Sonda da "onay kapısı satışı yavaşlatır" itirazını ve otuz günlük bir kurulum sırasını ele alıyoruz.

İndirim yetkisi gerçekte kimde ve bu neden yazıya dökülmeli?

Çoğu ekipte indirim yetkisi yazılı değildir; sözlü bir teamül olarak dolaşır. "Yüzde ona kadar temsilci kendi verir, üstünü müdüre sorar" cümlesini herkes bilir ama kimse bunu bir yerde okumamıştır. Sorun teamülün istisnalarla aşınmasıdır: çeyrek sonunda bir kez daha yüksek bir oran verilir, ertesi ay bir başkası "geçen sefer verilmişti" der, taban sessizce kayar. Altı ay sonra ekibin ortalama indirimi, kimsenin karar vermediği bir yere yerleşmiş olur.

Yazılı olmayan yetkinin ikinci maliyeti, tartışmayı fiyat kararından kişilere taşımasıdır. Onay istemek kişisel bir ricaya dönüşür; yönetici de onayı bir kural uygulaması olarak değil, temsilciye yapılan bir iyilik olarak verir. Kural yazıya döküldüğünde ise kişi devreden çıkar: teklif eşiği aştığı için onaya düşer, temsilci ısrarcı olduğu için değil. Bu ayrım, indirimi hem daha savunulabilir hem de daha tutarlı yapar.

Yetki kuralını yazarken üç şeyi aynı anda tanımlamak gerekir: hangi durumda kapı açılır, kim karar verir, karar ne kadar sürede verilir. Üçünden biri eksikse kural işlemez. Sadece "yüzde onun üstü onaya tabidir" demek, kimin bakacağını ve ne zaman döneceğini söylemediği için pratikte hiçbir şeyi değiştirmez. Teklif akışının bütününü kurarken bu kuralın nereye oturduğunu görmek için teklifi şansa bırakmayan bir süreç tarifine bakmak faydalı olur.

Kapı tutarda mı açılmalı, marjda mı?

İki farklı eşik vardır ve ikisi farklı riski yakalar. Tutar eşiği büyük anlaşmayı yakalar: belirli bir toplamın üstündeki her teklif, indirim olsun olmasın, ikinci bir göze gider. Buradaki gerekçe indirim değil, taahhüdün büyüklüğüdür — kapsam yanlış yazılmış olabilir, ödeme planı riskli olabilir, teslim süresi gerçekçi olmayabilir.

Marj eşiği ise küçük ama para kazandırmayan anlaşmayı yakalar. Toplamı mütevazı bir teklif, içine eklenen kurulum ve özel geliştirme kalemleri yüzünden maliyetin altına inmiş olabilir. Tutara bakan bir kapı bunu hiç görmez. Bu yüzden olgun ekipler iki eşiği birlikte kullanır: tutar tavanı ve marj tabanı. Rocketly'nin Yönetici Onay Kapısı tam olarak bu iki koşulu birlikte değerlendirir; tutar eşiğini aşan ya da marj tabanının altına düşen teklif otomatik olarak onaya düşer ve onaylanmadan müşteriye gönderilemez.

Üçüncü bir eşik daha vardır ve sıklıkla atlanır: sapma eşiği. Teklifteki bir kalem, o kalemin standart fiyatından belirgin biçimde ayrılıyorsa, teklifin toplamı ve marjı iyi olsa bile bu bir emsal yaratır. Aynı müşteri bir sonraki dönemde o kalemi aynı fiyattan ister; rakip müşteriler de duyar. Kalem bazlı sapmayı eşiğe eklemek, listeyi uzun vadede korur.

Marj tabanını neye göre hesaplarsınız?

Marj tabanı, altına inildiğinde anlaşmanın artık ekibin lehine olmadığı çizgidir. Onu hesaplarken en sık yapılan hata yalnızca doğrudan maliyeti saymaktır. Bir yazılım aboneliğinde altyapı maliyeti tablodaki en küçük kalemdir; kurulum saatleri, entegrasyon geliştirmesi, eğitim, ilk üç aydaki destek yoğunluğu ve hesap yönetiminin zamanı çoğu zaman ondan büyüktür.

Pratik bir yaklaşım şudur: son on iki ayda kapanmış anlaşmaların gerçekleşen teslim maliyetini çıkarın, müşteri segmentine göre gruplayın ve her segment için ortalama değil, üst çeyrek maliyeti taban olarak alın. Ortalamayı kullanmak, maliyeti ortalamanın üstünde çıkan anlaşmaların yarısını görünmez kılar. Üst çeyreği kullanmak temkinli bir taban verir; kapı biraz daha sık açılır ama yanlış tarafta hata yapmazsınız.

Tabanı yılda bir kez değil, çeyrekte bir gözden geçirin. Kur, işgücü maliyeti ve ürün kapsamı değiştikçe taban da değişir. Farklı para birimlerinde teklif veren ekipler için bu iş kendi başına bir sorun: aynı indirim oranı, kurun oynadığı bir çeyrekte farklı bir marja denk gelir. Çoklu Para ve Canlı Kur özelliği teklif anındaki kuru mühürlediği için, sonradan marj hesabı yaparken hangi kurun geçerli olduğu tartışması yaşanmaz.

Yetki matrisi kaç kademeli olmalı?

Kademe sayısı, ekibin büyüklüğüne değil, kararın niteliğine göre belirlenir. İki kademe çoğu ekip için yeterlidir: temsilcinin kendi verebildiği bant, bir de yöneticinin baktığı bant. Üçüncü kademe ancak marj tabanının altına inen ya da standart sözleşme şartlarını değiştiren tekliflerde anlamlıdır, çünkü orada karar artık satış kararı değil, ticari risk kararıdır ve finansın da bakması gerekir.

Dörtten fazla kademe kuran ekiplerde kapı işlemez hale gelir. Her kademe bir bekleme süresi ekler; dört kademeli bir zincirde teklif müşteriye ulaşana kadar rakip çoktan sunumunu yapmıştır. Kademe eklemek yerine bandı genişletmek genellikle daha iyi bir çözümdür: temsilciye biraz daha geniş bir alan verip, o alanın dışını tek bir yöneticiye bağlamak.

Aşağıdaki tablo, orta ölçekli bir B2B satış ekibi için örnek bir yetki matrisidir. Oranlar ve süreler sizin marj yapınıza göre değişir; buradaki amaç bantların nasıl kurulduğunu göstermek.

İndirim bandı	Marj durumu	Onay makamı	Hedef yanıt süresi
Liste fiyatı ile taban bandın üstü	Taban üstünde	Onay gerekmez	Anında
Orta bant	Taban üstünde	Satış müdürü	4 saat
Üst bant	Tabana yakın	Satış direktörü	1 iş günü
Üst bandın dışı	Taban altında	Direktör ve finans birlikte	2 iş günü

Matrisi kurarken bandı temsilcinin gerçekten kullanabileceği kadar geniş tutun. Temsilcinin yüzde doksan beş oranında onaya gitmek zorunda kaldığı bir matris, kapı değil bariyerdir; ekip onu aşmanın yollarını arar.

Onay ne kadar sürmeli ve gecikmenin bedeli nedir?

Bekleyen teklif çürüyen tekliftir. Müşteri karar penceresini kendi takvimine göre açar; siz o pencereyi kaçırdığınızda ikna gücünüzü değil, sıranızı kaybedersiniz. Onay süresi bu yüzden bir hedef değil, bir taahhüt olarak yazılmalıdır: dört saat denmişse dört saat, bir iş günü denmişse bir iş günü.

Taahhüdü yazılı hale getirmenin en temiz yolu, onay süresini iç bir hizmet seviyesi olarak tanımlamaktır. Satış ile pazarlama arasında kurulan karşılıklı yükümlülüklerin aynısı, satış ile yönetim arasında da kurulabilir; SLA ile karşılıklı yükümlülük kurma mantığı bu iç akışta da aynı işi görür. Yönetici belirli bir sürede dönmeyi taahhüt eder, temsilci de onay talebini eksiksiz göndermeyi.

Gecikmenin bedelini ölçmek istiyorsanız iki sayıya bakın: onaya düşen tekliflerin ortalama bekleme süresi ve onay bekleyen tekliflerin kazanma oranı ile hiç onaya düşmeyenlerin kazanma oranı arasındaki fark. İkinci sayı çoğu ekipte can yakıcıdır ve kapıyı kaldırma değil, hızlandırma gerekçesi üretir. Süre ile kapanış arasındaki ilişkiyi daha genel olarak anlaşmayı hızlandıran pratikler üzerinden okumak, onay süresini de doğru bağlama oturtur.

Bekleyen teklif nerede durur? Gelen kutusu neden kuyruk değildir

Onay talebi e-postayla gidiyorsa, teklifin durumu artık bir gelen kutusunun rastgeleliğine bağlıdır. Yönetici yüz elli iletinin arasında onay isteğini gördüyse iyi; görmediyse teklif üç gün bekler ve kimse bunu fark etmez. Temsilci hatırlatır, yönetici "bana gelmemiş" der, tartışma teklifin içeriğinden çıkıp iletinin nereye gittiğine döner.

Kuyruk bu belirsizliği ortadan kaldırır. Onay Kuyruğu eşiği aşıp onaya düşen tekliflerin tamamını tek listede, her birinin ne kadar süredir beklediğiyle birlikte gösterir. Yönetici sabah listeyi açar, en uzun bekleyeni önce görür ve kuyruktan onaylar ya da gerekçesiyle geri gönderir. Teklif kimsenin gelen kutusunda kaybolmaz; "bana gelmedi" cümlesinin karşılığı kalmaz.

Kuyruğun ikinci faydası ölçülebilirlik. Bekleme süresi kuyrukta görünür olduğu anda yönetilebilir bir sayıya dönüşür. Hangi bandın en çok beklediğini, hangi yöneticinin kuyruğunun uzadığını, hangi gün ve saatlerde birikme olduğunu görürsünüz. Bu veriyi teklif hunisinin geri kalanıyla birlikte okumak için huninin aşamalarını ve dönüşümü aynı ekranda takip etmek gerekir.

Reddedilen teklif nasıl geri döner?

Onay kapısının en çok ihmal edilen yarısı geri dönüş yoludur. Onay verildiğinde iş kolaydır; teklif gider. Onay verilmediğinde ne olacağı çoğu ekipte tanımsızdır ve temsilci ne yapacağını bilemez. İyi kurulmuş bir kapıda ret bir son değil, gerekçeli bir yönlendirmedir: "bu bandı kabul etmiyorum" değil, "kurulum kalemindeki indirimi kaldırıp süreyi iki yıla çıkarırsan onaylarım".

Gerekçe alanını zorunlu tutmak, kapının en ucuz iyileştirmesidir. Gerekçesiz ret temsilciyi tahmine iter; tahmin de ikinci bir yanlış teklif üretir. Gerekçeli ret ise doğrudan bir revizyon talimatıdır ve çoğu zaman ikinci turda onaylanan bir teklifle sonuçlanır. Reddin dilini de düşünün: müşteriye söylenmeyecek bir cümle iç yazışmaya da yazılmamalıdır, çünkü teklif kaydı sonradan çok kişi tarafından okunur.

Revizyon turunda müşteriyi bekletmemek için kapsamı daraltmak sıklıkla indirimden daha iyi bir yanıttır. Paket Seçimi ve Kısmi Kabul özelliği, müşterinin yalnızca istediği kalemleri onaylamasına izin verdiği için, fiyatı düşürmek yerine kapsamı küçültme seçeneğini masada tutar. Bu, müşterinin bütçesine oturur ve marj tabanına dokunmaz. Bu tür pazarlıkların dilini kurmak için "pahalı" itirazının gerçekte ne anlattığını anlamak, bandı savunmayı çok kolaylaştırır.

Karar nerede kayıtlı kalır? Denetlenebilirlik meselesi

Onay kapısının varlık nedeni yalnızca indirimi sınırlamak değil, kararın izini bırakmaktır. Altı ay sonra aynı müşteri yenilemeye geldiğinde, hesap yöneticisinin "geçen sefer bu bandı neden verdik" sorusuna cevabı olmalıdır. Cevap bir kişinin hafızasında duruyorsa, o kişi ekipten ayrıldığında cevap da gider.

Kararın teklifin kendisiyle aynı yerde saklanması bu yüzden önemli. Versiyon Geçmişi ve Karşılaştırma her revizyonu anlık görüntüsüyle sakladığı için, hangi bandın hangi versiyonda verildiği ve o kararın kim tarafından ne zaman alındığı sonradan satır satır okunabilir. İki teklifi yan yana koyup farkı görmek, "biz bunu böyle konuşmamıştık" tartışmasının uzunluğunu belirgin biçimde kısaltır.

Aynı iz, teklif sözleşmeye dönüştüğünde de taşınır. Yalnızca kabul edilmiş bir teklif sözleşmeye çevrildiği ve tutar, para birimi ile taraflar olduğu gibi aktarıldığı için, onaylanmamış bir bandın sözleşmeye sızması mümkün olmaz. Yenileme dönemine geldiğinizde de aynı kayıt elinizin altındadır; yenilemeyi şansa bırakmayan bir düzen kurmanın ilk şartı, önceki dönemin fiyat kararının gerekçesiyle birlikte duruyor olmasıdır.

Onay kapısı satışı gerçekten yavaşlatır mı?

Bu itiraz her ekipte çıkar ve kısmen haklıdır: kötü kurulmuş bir kapı satışı yavaşlatır. Ama yavaşlatan şey kapının varlığı değil, kapının kaç kere ve ne kadar süreyle açıldığıdır. Bandı çok dar tutan, kademeyi çok derin kuran ve süre taahhüdü olmayan bir kapı elbette engel olur. Bandı doğru genişlikte kuran, tek kademeli ve saat cinsinden taahhütlü bir kapı ise çoğu zaman süreci hızlandırır, çünkü temsilcinin "bu oranı verebilir miyim" diye ortalıkta dolaşarak geçirdiği belirsiz süreyi ortadan kaldırır.

İkinci yaygın itiraz, kapının temsilciye güvensizlik anlamına geldiğidir. Pratikte tersi olur: yazılı bant temsilciye kendi alanını net biçimde verir. O bandın içinde kimseye sormadan karar verebileceğini bilmek, sürekli izin isteme halinden daha fazla özerkliktir. Sınırın nerede olduğunu bilmeyen temsilci ya çok az indirim verip anlaşmayı kaybeder ya da çok fazla verip marjı yakar.

Üçüncüsü, kapının pazarlığın kendisini bozduğu iddiasıdır. Aslında iyi satıcılar kapıyı bir pazarlık aracı olarak kullanır: "bu oranı onaya götürmem gerekiyor, karşılığında iki yıllık taahhüt alabilir miyim" cümlesi, karşılıksız indirimi karşılıklı bir alışverişe çevirir. Anlaşmayı bitiren yöntemler arasında en sağlamı, tam olarak bu tür karşılıklı taviz kurgusudur.

Kapıyı otuz günde nasıl kurarsınız?

İlk hafta ölçmekle geçer. Son iki çeyrekte verilen indirimlerin dağılımını çıkarın: hangi bantta kaç teklif var, bantlar arasında kazanma oranı nasıl değişiyor, hangi bandın üstünde marj tabanının altına iniliyor. Bu dağılım olmadan konulan her eşik tahminden ibarettir ve genellikle ya çok sıkı ya çok gevşek olur.

İkinci hafta kuralı yazın. Tek sayfa yeter: bantlar, her bandın onay makamı, hedef süre ve ret gerekçesi için beklenen içerik. Bu sayfayı satış ekibiyle birlikte yazın, onlara tebliğ etmeyin — kuralı yazarken odada olan kişi, kuralı uygulayan kişi olur. Fiyat tarafının teklif metnine nasıl yansıyacağını netleştirmek için teklif mektubunun nasıl kurulduğuna aynı hafta bakmak iyi olur.

Üçüncü hafta sistemi kurun. Eşikleri tanımlayın, kuyruğu açın, yöneticilere bildirimleri bağlayın ve iki hafta boyunca yalnızca uyarı modunda çalıştırın: teklif onaya düşsün ama gönderim engellenmesin. Bu süre, eşiğin gerçekten doğru yerde olup olmadığını gösterir. Dördüncü hafta kapıyı zorunlu hale getirin ve ilk ayın sonunda üç sayıyı ölçün: onaya düşen teklif oranı, ortalama onay süresi ve reddedilip revize edilerek kazanılan teklif sayısı. Teklif Analitiği ve Dışa Aktarma ile kaç teklifin kabul edildiğini ve hangi tutarda takıldığınızı CSV olarak dışarı alıp kendi raporunuza taşıyabilirsiniz; bu sayıları gönderilen teklifi kazanca taşıyan takip düzeniyle birlikte okumak, onay bandının kazanma oranına etkisini net gösterir.

Kurulumdan sonraki ilk üç ay, eşikleri ayarlama dönemidir. Onaya düşme oranı çok yüksekse bandı genişletin; çok düşükse eşiği aşağı çekin. Kapının başarısı, ne kadar çok teklifi durdurduğuyla değil, kaç teklifin doğru bantta ve zamanında gittiğiyle ölçülür. Bu düzeni kendi ekibinizde denemek isterseniz Rocketly hesabınızı açıp eşikleri kendi marj yapınıza göre tanımlayabilirsiniz.

Sıkça sorulan sorular

Küçük bir ekipte onay kapısı gereksiz mi?

Üç kişilik bir ekipte herkes her teklifi görüyor olabilir, ama kayıt yine de gerekir. Ekip beş kişiyi geçtiğinde ya da ilk yenileme dönemi geldiğinde, geçmiş kararın gerekçesini hatırlayan kimse kalmaz. Küçük ekipte kapıyı tek kademeli ve geniş bantlı kurun; amaç yavaşlatmak değil, kararı kaydetmek.

Yönetici izinliyken teklif bekler mi?

Beklememeli. Her banda bir asıl ve bir yedek onaylayan tanımlayın. Yedek tanımlanmamışsa kapı ilk izin döneminde tıkanır ve ekip onu aşmanın gayriresmi yollarını bulur — ki bu, kapıyı hiç kurmamış olmaktan daha kötüdür.

Eşiği aşan her teklif gerçekten durdurulmalı mı?

Evet, aksi halde eşik bir tavsiyeye dönüşür. Onaylanmadan gönderilemeyen bir teklif kuralı gerçek kılar. Buna karşılık eşiğin doğru yerde olduğundan emin olun: her ikinci teklifi durduran bir eşik, kuralın kendisini itibarsızlaştırır.

Onay süresini kısaltmanın en pratik yolu nedir?

Talebin eksiksiz gelmesi. Yöneticiye giden ekranda müşterinin geçmişi, teklifin marjı, istenen bandın gerekçesi ve karşılığında alınan taahhüt görünüyorsa karar dakikalar sürer. Bu bilgiler yoksa yönetici sormak zorunda kalır ve tur sayısı ikiye katlanır. Talep formunun içeriğini standartlaştırmak, onayı saatlerce bekletmeden almanın en hızlı yoludur.