Teklif Onay Akışı Nasıl Kurulur? Revizyon ve Sürüm Kontrolü

Teklif revizyon yönetimi, her değişikliği ayrı bir sürüm olarak saklayıp önceki sürümü silmeden neyin, ne zaman değiştiğini kayıt altına almaktır. Teklif onay akışı ise belirli bir eşiği (genelde bir iskonto oranını) aşan revizyonun, belirlenmiş onaylayıcılardan geçmeden müşteriye gitmesini engelleyen kuraldır.

İki kavram farklı katmanlarda çalışır: sürüm kontrolü her teklif için varsayılan olmalıdır, onay akışı ise yalnızca ekibinizin belirlediği bir eşiği aşan durumlarda devreye girer. Bu yazı ikisini ayırıp onay akışını sıfırdan nasıl kuracağınızı adım adım anlatıyor.

Teklif revizyonu ile teklif onay süreci arasındaki fark nedir?

Teklif revizyonu, aynı teklifin fiyatı, kapsamı ya da koşulları değiştiğinde açılan yeni bir sürümdür: R1, R2, R3. Her sürüm saklanır, hiçbiri silinmez; hangi sürümün müşteriye gönderildiği ve hangisinin hâlâ taslak olduğu kayıtta görünür. Bu, teklif göndermenin doğal bir parçasıdır ve ayrı bir kural gerektirmez.

Teklif onay süreci ise farklı bir katmandır: bir revizyon belirli bir eşiği aştığında (genelde bir iskonto oranı, bazen bir ödeme koşulu ya da teslim süresi esnetmesi), teklifin müşteriye gönderilmeden önce belirlenmiş bir ya da birden fazla kişinin onayından geçmesini zorunlu kılar. Sürüm kontrolü her teklifte vardır; onay akışı yalnızca ekibin “bu tür revizyon onaysız gitmesin” dediği durumlar için ayrıca kurulur.

İndirim onayı kim verir? Onay eşiği nasıl belirlenir?

Onay eşiği, kimin ne kadar iskontoyu kendi başına verebileceğini tanımlayan yazılı bir sınırdır. Sınır yazılı değilse eşik fiilen “kim en son konuştuysa o karar verir” olur. Bu da aynı müşteriye farklı temsilcilerden farklı iskontoların gittiği, kimsenin ötekinden haberdar olmadığı bir duruma yol açar.

Üç katmanlı bir eşik çoğu satış ekibi için başlangıç noktasıdır:

• Temsilci: küçük, standart iskontoları (örneğin liste fiyatının %5’ine kadar) onay almadan verir.
• Satış müdürü: orta düzey iskontoları (örneğin %5 ile %15 arası) onaylar; tek onaylayıcı yeterlidir.
• Genel müdür ya da finans: %15’in üzerindeki iskontoları ve standart dışı ödeme koşullarını onaylar; gerekirse ikinci bir onaylayıcı eklenir.

Yüzdeler örnektir; kendi marjınıza ve ürün karmaşıklığınıza göre ayarlayın. Önemli olan sayı değil, sınırın yazılı olması ve her teklifte aynı şekilde uygulanmasıdır.

Eşiği tarihli bir politika notunda, tek bir paragrafla yazın, çünkü ekip toplantısında sözlü anlatılan bir kural altı ay sonra ekibe katılan temsilciye ulaşmaz. Notta üç şey bulunsun: eşiğin kendisi (hangi yüzde, hangi koşul), her katmanın onaylayıcısı ve yedeği, eşiğin ne sıklıkla gözden geçirileceği.

Teklif onay akışı adım adım nasıl kurulur?

Aşağıdaki beş adım bir onay akışını sıfırdan kurar; her adımın bir sorumlusu ve somut bir çıktısı vardır.

1. Onay gerektiren durumu tanımlayın. Sorumlu: satış müdürü ve finans. Çıktı: yazılı bir eşik listesi (iskonto oranı, ödeme koşulu, teslim süresi esnetmesi gibi).
2. Onaylayıcıları belirleyin. Sorumlu: satış müdürü. Çıktı: her eşik için adı belli bir onaylayıcı ve bir yedek.
3. Akışı sisteme kurun. Sorumlu: CRM yöneticisi. Çıktı: eşiği aşan bir revizyon oluştuğunda onaylayıcıya giden bir süreç. Senitix CRM’de bu adımın otomasyon ve onay özellikleri vardır.
4. Ekibe duyurun ve örnekle gösterin. Sorumlu: satış müdürü. Çıktı: bir örnek revizyon üzerinden akışın uçtan uca test edilmiş olması.
5. Onay süresini izleyin. Sorumlu: satış müdürü. Çıktı: onayda bekleyen tekliflerin listesi ve ortalama onay süresi.

Teklif sürüm kontrolü neden önemlidir, önceki revizyon neden silinmemeli?

Bir teklif müşteriye gittiğinde hukuken bir icaptır ve üzerinde bir geçerlilik süresi belirtilmişse, Türk borçlar hukukunda bu süre dolana kadar gönderen tarafı bağlar; bir anlaşmazlıkta hangi koşulların geçerli olduğu sorusu buradan doğar. Aynı fırsatta birden fazla revizyon varsa hangi sürümün hâlâ bağlayıcı olduğu, yani hangisinin geçerlilik tarihinin geçtiği ve hangisinin müşteri tarafından kabul edildiği, ancak sürüm geçmişi eksiksiz tutulursa netleşir.

Bu yüzden bir revizyon açıldığında önceki sürüm silinmez ya da üzerine yazılmaz; yeni bir sürüm numarası alır ve öncekiyle yan yana durur. Bir anlaşmazlıkta “müşterinin elindeki hangi sürümdü” sorusuna dakikalar içinde cevap verebilmek, sürüm geçmişinin en pratik faydasıdır.

Onay akışı kurarken hangi hatalar yapılır?

• Eşiği sözlü bırakmak. Yazılı olmayan bir sınır, ekip büyüdükçe kişiden kişiye farklı uygulanır.
• Tek onaylayıcı, yedeksiz bırakmak. Onaylayıcı izinliyken teklif onayda bekler, bu sırada müşteri kaybedilebilir.
• Onayı teklif gönderildikten sonra istemek. Müşteriye giden teklif geri çekilemez; onay her zaman gönderim öncesi bir adım olmalıdır.
• Her revizyonu aynı eşikten geçirmek. Kapsamı değişmeyen, yalnızca yazım hatası düzeltilen bir revizyonun da onaya girmesi süreci yavaşlatır ve ekibin akışı görmezden gelmesine yol açar.

Örnek: bir ekipte onay akışının kurulumu

Ekip ve sayılar tamamen örnektir. Trabzon’da dokuz kişilik bir ofis mobilyası ve donanımı satış ekibinde iskontolar daha önce yalnızca satış müdürünün sözlü onayıyla veriliyordu; hangi teklifin onaylandığı yalnızca müdürün hafızasındaydı. Ekip üç katmanlı bir eşik belirledi: temsilci %5’e kadar kendi karar veriyor, satış müdürü %5-12 arasını onaylıyor, genel müdür %12 üzerini onaylıyor.

Kurulumdan sonraki ilk ay, sonuçlanan 22 tekliften 7’si onay eşiğini aştı; bunların ortalama onay süresi 6 saat oldu, en uzunu ise bir gün sürdü çünkü satış müdürü o gün şehir dışındaydı ve yedek onaylayıcı henüz tanımlanmamıştı. Ekip, ikinci adımdaki eksiği fark edip bir yedek onaylayıcı ekledi; ikinci ay ortalama onay süresi 2 saate indi.

Teklif onay akışı nasıl ölçülür?

İki ölçü, akışın gerçekten işe yarayıp yaramadığını gösterir: onayda bekleyen tekliflerin ortalama süresi (uzunsa akış bir darboğaz olur) ve sonuçlanan tekliflerin ne kadarının onay eşiğine girdiği (çok yüksekse eşik ya çok düşük konmuştur ya da fiyatlandırma disiplini zayıftır). Her iki ölçüyü de aylık gözden geçirin ve eşiği gerektiğinde yeniden ayarlayın. Reddedilen ya da vazgeçilen onay isteklerinin oranı da izlenmeye değer: sürekli yükseliyorsa temsilciler eşiği zorlayan iskontolar önermeye başlamış demektir.

Bu akış kimin için gerekli, kimin için değil?

Gerekli: birden fazla temsilcinin iskonto verebildiği, tek bir kişinin (satış müdürünün) tüm iskontoları hafızasında tutamadığı ekipler; iskonto sonrası marjın dikkatle izlenmesi gereken düşük marjlı ürünler satan işletmeler.

Gerekli değil: tek karar vericinin (genelde kurucu ya da tek satış müdürünün) zaten her teklifi kendisi hazırladığı çok küçük ekipler. Bu durumda ayrı bir onay akışı yerine, iskonto sınırını tek bir referans belgede tutmak yeterlidir.

Aradaki geçiş noktası genelde ekip büyüklüğünden çok, satış müdürünün her teklifi tek tek görüp göremediğidir. Üç-dört temsilcili bir ekipte müdür hâlâ her teklife göz atabiliyorsa sözlü onay işler. Aynı gün birden fazla teklif farklı kişilerce gönderilmeye başladığında ilk belirti, aynı müşteriye iki farklı iskonto oranının gitmesidir.

Senitix CRM’de teklif revizyon yönetimi ve onay akışı

Senitix CRM’de her teklif revizyonu kendiliğinden ayrı bir sürüm olarak saklanır; önceki sürüm silinmez, üzerine yazılmaz. Hangi sürümün müşteriye gönderildiği ve hangisinin taslak olduğu teklif kaydının üzerinde görünür.

Ekibinizin belirlediği eşiği aşan bir teklif revizyonu, belirlenmiş onaylayıcılardan geçen bir onay sürecine girer; hangi eşiğin onay isteyeceğine ekibiniz karar verir. Onaylanan teklif kabul edildiğinde kalemleri yeniden yazılmadan sözleşmeye dönüşür.

Teklif hazırlama sürecindeki iskonto ve revizyon hatalarının tam listesini teklif hazırlama hataları yazımızda, kabulden sonraki adımları tekliften siparişe süreç yazısında anlattık. Plan ayrıntıları Senitix CRM fiyatları sayfasında.

Sık sorulan sorular

Onay akışı için ayrıca bir kurulum gerekir mi?

Sürüm kontrolü için gerekmez: her revizyon kendiliğinden ayrı bir sürüm olarak saklanır. Onay akışı ise ekibinizin eşiği ve onaylayıcıları tanımlayarak kurduğu bir kuraldır; kurulumun beş adımını yukarıda anlattık.

İskonto dışında bir değişiklik (teslim süresi, ödeme koşulu) de onay akışına girer mi?

Evet, eğer eşik tanımınıza dahil ettiyseniz. Onay akışı yalnızca iskontoya özgü değildir; standart dışı bir teslim süresi uzatması ya da alışılmışın dışında bir ödeme vadesi de aynı mantıkla bir onay eşiği olarak tanımlanabilir. Önemli olan, hangi değişikliklerin eşiğe girdiğinin baştan yazılı olmasıdır.

Onay akışı kurmak teklifin müşteriye gitme süresini ne kadar uzatır?

Bu, onaylayıcının uygunluğuna bağlıdır; onaylayıcı ve bir yedek net şekilde belirlenmişse gecikme genelde saatler içinde kalır. Gecikme günler sürüyorsa sorun akışın kendisinde değil, onaylayıcının başka işlere öncelik vermesindedir. Bu durumda ikinci bir yedek eklemek ya da eşiği gözden geçirmek gerekir.

Onaylayıcı teklifi CRM dışında, e-posta ya da telefonla onaylarsa ne olur?

Onay kayıt dışında kalır; teklifin hangi onaydan, ne zaman ve kim tarafından geçtiği yalnızca o e-postayı ya da aramayı hatırlayan kişinin belleğinde durur. Sözlü ya da CRM dışı verilen bir onayı da kaydın üzerine not olarak eklemek, sürüm geçmişiyle birlikte tutarlı ve aranabilir bir iz bırakır.

Eski bir revizyona geri dönmek gerekirse ne olur?

Sürüm geçmişi silinmediği için önceki bir revizyona bakmak ya da onu temel alarak yeni bir sürüm açmak her zaman mümkündür; hiçbir sürüm kaybolmaz, yalnızca yeni bir numarayla devam eder. Müşteri “ilk konuştuğumuz fiyata dönelim” dediğinde de aynı yol izlenir: eski sürüm kopyalanmaz, üzerine yazılmaz, güncel koşullarla yeni bir revizyon olarak açılır.