Patronun telefonuna bağlı olmayan onay süreçleri

TL;DR (Quick Summary)

Onaylar patronun telefonunda dönüyorsa iş hızlanmış gibi görünür ama aslında kuyruk büyür, kayıt kaybolur ve karar kalitesi düşer. Çözüm her kararı kurucudan almak değildir, düşük riskli kararları kurala bağlayıp kritik kararları hızlı ve görünür yürütmektir.

• Telefonla yürüyen onayların işi neden kilitlediğini netleştirin → Darboğazı görünür kılın
• Önce hangi onayları kurucudan ayıracağınıza risk ve tekrar sıklığına göre karar verin → Doğru yerden başlayın
• Tutar, risk ve istisnaya göre çalışan bir yönlendirme matrisi kurun → Kurallı yönlendirme oluşturun
• Rolleri, vekalet zincirini ve bekleme süresi kurallarını baştan yazılı hâle getirin → Bekleme yerine akış kurun
• Telefon konuşmasını değil, kanıtı taşıyan onay paketini standartlaştırın → Kararı kayıtla taşıyın
• Mobil erişimi telefon trafiğine alternatif olarak değil, yapılandırılmış hız avantajı olarak tasarlayın → Aramadan hızlı onay verin
• Kontroller, istisnalar ve aylık gözden geçirme ile süreci kalıcı hâle getirin → Süreci canlı tutun

Takeaway

İyi kurulmuş onay sistemi, patronu devreden çıkarmaz; doğru kararları doğru seviyeye indirir. Telefon trafiğini azaltırken kayıt, hız ve sorumluluğu aynı anda güçlendirir.

İşler büyüdüğünde ilk görünmeyen krizlerden biri onay trafiğidir. Her ödeme, indirim, satın alma ve istisna talebi kurucunun telefonuna düştüğünde şirket “kontrollü” değil de tek kişiye bağımlı hâle gelir. Çözüm, patronu tamamen denklemden çıkarmaktan geçmez; düşük riskli kararları kurallı akışa almaktan ve yüksek etkili kararları bekletmeden görünür şekilde üst seviyeye taşımaktan geçer.

Sistem basittir: Hangi kararın kimde kalacağını tanımlarsınız, belli eşiklere göre talebi yönlendirirsiniz, her karar için yazılı kanıt bırakırsınız ve ana onaycı yoksa akışı durdurmazsınız. Telefon görüşmesi yerine yapılandırılmış onay paketi kullanıldığında hız artar, sonradan “kim neye göre onay verdi” tartışması azalır.

Telefonla yürüyen onayların işi neden kilitlediğini netleştirin

Hızlı büyüyen şirketlerde onaylar genelde fark edilmeden kurucuda birikir. Finans ekibi ödeme için arar, satış ekibi indirim onayı ister, satın alma ekibi yeni tedarikçi için mesaj atar, insan kaynakları ekibi aday teklifi bekletir, hukuk ekibiyse standart dışı sözleşme maddesi için geri dönüş bekler. Bir süre sonra tüm operasyon ritmi, patronun müsaitlik takvimine bağlanır.

Buradaki sorun sadece yavaşlama değildir. Telefonla alınan sözlü onaylar, aynı konuda farklı zamanlarda verilen çelişkili kararlar üretir. Sabah “geçsin” denilen teklif, akşam “kim onayladı bunu?” sorusuna dönebilir. Özellikle ödeme, indirim ve sözleşme istisnalarında bu dağınıklık ciddi sürtünme yaratır.

Kişiye bağımlı sürecin belirtileri genelde nettir:

• Bekleyen onay kuyruğunun gün içinde şişmesi
• Mesai dışı arama ve mesaj trafiğinin artması
• “Sözlü onay alındı” notuyla ilerleyen işlemler
• Aynı tip taleplerde farklı kararlar çıkması
• Sonradan bulunamayan ekran görüntüleri, mesajlar ve e-postalar
• Talep sahibinin onay alabilmek için doğrudan kurucuya bypass (istisna geçişi) yapması

Bir başka kırılma noktası da görünmeyen bekleme süresidir. Talep beş dakikalık karar gerektirir ama o beş dakika, gün içine saçılmış üç telefon araması, iki hatırlatma mesajı ve akşam gelen “yarın bakarım” cevabına dönüşür. Sistem kâğıt üzerinde hızlı görünse bile sahada yavaştır.

Buradaki mesele “kurucu artık hiçbir şeye bakmasın” değildir. Asıl hedef, düşük riskli ve sık tekrar eden kararları kural bazlı akışlara vermek; yüksek etkili, bütçe dışı ya da istisnai kararları ise görünür ve hızlı ele almaktır. Böyle kurulduğunda patron üzerindeki gürültü azalır ve kritik kararların kalitesi düşmez.

Onay İş Akışı Araç Seti: Roller, Limitler, Eskalasyon Haritası

Kapsamlı ve adım adım kılavuzu almak için e-posta adresinizi girin.

You acknowledge that you have read and understood Bitrix24 Privacy Policy

Önce hangi onayları kurucudan ayıracağınıza risk ve tekrar sıklığına göre karar verin

Yanlış başlangıç yaygındır çünkü şirketler önce en ses getiren onayı düzeltmeye çalışır, en çok tekrar eden onayı değil. Oysa patronun telefonunu kilitleyen kararlar çoğu zaman stratejik olanlardan ziyade rutin taleplerdir.

İlk iş onay envanteri çıkarmaktır. Bir tablo açın ve her onay türü için şu başlıkları yazın: karar türü, tutar aralığı, ne kadar sık geldiği, risk seviyesi, yasal veya finansal etkisi, gecikince neyin aksadığı ve bugün en çok kimde takıldığı.

Bu çalışma bazı kararların çok sık ama düşük riskli olduğunu gösterirken, bazılarının seyrek ama yüksek etkili olduğunu gösterir. Bazıları ise finansal olarak düşük tutarlı görünse de yasal riski nedeniyle üst seviyede kalmalıdır. Sorunu böyle ayırmadığınızda herkes aynı telefona yüklenmeye devam eder.

İlk delege edilecek alanlar genelde yüksek hacimli ve düşük-orta riskli onaylardır: belirli limite kadar departman harcamaları, önceden tanımlı indirim bantları, onaylı tedarikçilerden yapılan standart satın almalar, planlı izinler veya bütçede karşılığı olan rutin ödemeler. Bunlar kurucunun stratejik muhakemesini her seferinde gerektirmez.

Pratik kural şudur: Aynı karar tipi tekrar tekrar geliyorsa ve karar mantığı çoğu vakada benzerse o alan delegasyona adaydır. Satış müdürü her hafta aynı çerçevede fiyat istisnası istiyorsa sorun satış ekibi değil, onay modelidir.

Kurucuda kalması gereken alanları da ayırın. Stratejik müşteri için verilen büyük tavizler, bütçe dışı yüksek tutarlı harcamalar, standart dışı sözleşme maddeleri, şirket yapısını etkileyecek işe alımlar veya yeni ticari risk yaratan kararlar hâlâ üst seviyede olmalıdır. Hız uğruna kontrol dağıtılmamalıdır.

Tutar, risk ve istisnaya göre çalışan bir yönlendirme matrisi kurun

Delegasyon kararı verildikten sonra en kritik iş, bunu sözlü anlayışla değil açık yönlendirme mantığıyla yazmaktır. “Normalde müdür onaylar ama duruma göre patrona sorarız” cümlesi sağlıklı bir süreç değil, darboğazın yeni sürümüdür.

Her onay türü için en az üç şey net olmalıdır: hangi limite kadar kim karar verir, hangi durumda ikinci onay gerekir, hangi koşul talebi kurucuya ya da icra seviyesine taşır. Sadece tutara bakmak yetmez, aynı tutardaki iki talep bağlama göre farklı risk taşıyabilir.

Bu yüzden matriste bağlama dayalı kurallar da olmalıdır. Bütçede yeri var mı? Tedarikçi daha önce onaylı mı? Sözleşme standart şablonla mı gidiyor? Marjı anlamlı şekilde bozuyor mu? Müşteriye verilen teslim, kapsam veya ödeme taahhüdü değişiyor mu?

Bu matrisin gücü, her kararı tepeye taşımamasındadır. Aynı zamanda sınırları belirler. Onaylı tedarikçiden yapılan standart alım ile yeni bir tedarikçiye peşin ödeme aynı kutuya girmemelidir. Tutar aynı olsa bile risk farklıdır.

Örnek karar senaryosu

Karar mantığını ekiplerin günlük işte uygulayabileceği kadar kısa tutun:

• 35.000 TL satın alma: Bütçe içi + onaylı tedarikçi + standart şartlar → birim yöneticisi → işlem ilerler.
• 120.000 TL satın alma: Bütçe içi + onaylı tedarikçi → birim yöneticisi + finans → ikinci onay tamamlanınca işlem ilerler.
• 80.000 TL satın alma: Tutar düşük olsa da bütçe dışı veya yeni tedarikçi → finans kontrolü → risk yüksekse icra/kurucuya eskalasyon.
• %8 indirim talebi: İndirim şirket politikasındaki bant içinde ve marj etkisi 3 puanın altında → satış yöneticisi. Marj düşüşü 3 puanı aşıyorsa → ticari lider + finans. Standart dışı ödeme, kapsam veya müşteri taahhüdü de varsa → icra/kurucu.

İyi matris sade olur. Kimsenin açıp okuyamayacağı kadar uzun bir belge hazırlarsanız insanlar yine telefonla sorar. Çıplak mantık görünmelidir: tutar, bağlam, istisna.

"Bitrix24'ün ihtiyaçlarımıza en uygun yazılım olduğunu gördüm.

Müdür Yardımcısı - BT Departmanı, Mr. Pham Xuan Tung

Saigon Newport Corporation

Ücretsiz kayıt

Rolleri, vekalet zincirini ve bekleme süresi kurallarını baştan yazılı hâle getirin

Yönlendirme matrisi tek başına yetmez. Talep kime gidecek, kim ilk kontrolü yapacak, kim kaydı kapatacak belli değilse akış yine kişisel ilişkilere döner. Bu da “ben bilgilendirilmemiştim” ve “onu şu ekip kontrol ediyor sanıyordum” cümleleriyle sonuçlanır.

Her karar tipi için beş rolü ayırın: talebi açan kişi, ilk kontrolü yapan kişi, onaylayan kişi, bilgisine sunulan kişiler ve nihai kayıt sorumlusu. Satın alma talebini ekip lideri açabilir, finans ilk belge kontrolünü yapabilir, ilgili yönetici onay verebilir, muhasebe bilgisine eklenebilir ve kayıt sorumluluğu satın alma ya da finans tarafında kalabilir.

Bu ayrım özellikle karmaşık taleplerde işe yarar. Talebi açan kişi çoğu zaman onay sahibi değildir, ilk kontrolü yapan da karar veren kişi olmayabilir. Herkesin her şeyi yaptığı sistemler dışarıdan esnek görünür ama içeride kimsenin tam sorumluluğu yoktur.

Vekalet zinciri de şarttır. Kurucu ya da ana onaycı izinli, seyahatte, toplantıda veya gün içinde erişilemez olabilir. Akış burada donmamalıdır, hangi durumda hangi vekilin devreye gireceği önceden yazılmalıdır. Otomatik devir uygulamak en iyi çözümdür ancak bu mümkün değilse manuel devir yetkisi belirli bir süreç sahibinde olmalıdır.

Bu yaklaşım özellikle birden fazla imza ve yetki gerektiren yapılarda önemlidir. Türkiye’de şirket kuruluş süreçlerinde dahi imza yetkileri ve vekâlet düzenlemeleri resmî sürecin parçasıdır. Yetkinin kimde olduğu kadar, hangi koşulda kime devredilebileceğinin önceden tanımlanması, yöneticinin yokluğunda işlemlerin kişisel takibe dönmesini engeller.

Bekleme süresi kuralları da baştan tanımlanmalıdır. Talep sistemde “bekliyor” görünüyorsa ama kimse ne zaman müdahale edeceğini bilmiyorsa o kayıt canlı değildir, sadece park edilmiştir. Bu gibi karmaşaları önlemek için zaman tabanlı akış mantığı kurun:

• Belirli süre içinde yanıt yoksa hatırlatma gider.
• Cevap gelmezse talep bir üst role yönlenir.
• Daha uzun aşımda alternatif onaycıya geçer.
• İş kritikse süreç sahibi ayrıca müdahale eder.

Örnek süreler şirket ritmine göre değişse de ana mantık değişmez: Bekleyen işin sahibi sistem tarafından görünür olmalı ve gecikme bir sonraki adımı tetiklemelidir. Yoksa herkes bir başkasının döneceğini varsayar.

Bekleme süresini de ölçülebilir kurallara bağlayın. Örneğin 4 saat yanıt yoksa otomatik hatırlatma, 8 saatte bir üst role eskalasyon, 24 saatte alternatif onaycıya geçiş gibi bir kural akışını Bitrix24 CRM içindeki satış otomasyonu araçları ile uygulayabilirsiniz.

Ayrıca Görevlerin Ayrılığı (SoD) kuralını açıkça tanımlayın. Talebi açan kişi aynı kaydı onaylayamamalıdır. Özellikle ödemelerde talebi açan, belgeleyen, onaylayan ve ödemeyi gerçekleştiren roller ayrıştırılmalıdır. Böylece hem geciken onaylar kişisel takibe kalmaz hem de tek kişinin bir işlemi başlatıp kendi kendine onaylamasının yaratacağı kontrol riski ortadan kalkar.

Telefon konuşmasını değil, kanıtı taşıyan onay paketini standartlaştırın

Telefon konuşması hızlı gibi görünür çünkü birkaç dakikada karar alınır. Ama kararın bağlamı, dayanağı ve kapsamı kayda girmiyorsa bu hızın faturası sonra çıkar. “Patron onay verdi” cümlesi tek başına işlem yapmak için yeterli kayıt değildir.

Her talep için standart bir onay paketi oluşturun. Talep açılırken zorunlu alanlar boş geçilememelidir. En azından talep nedeni, tutar, bütçe kodu, karşı taraf, beklenen etki, ek belgeler, kısa risk notu ve talep sahibinin önerisi bulunmalı. Onaycı arka planı sormak için tekrar aramak zorunda kalmamalı.

İyi onay paketi karar vereni gereksiz bilgiye boğmaz ama karanlıkta da bırakmaz. Satış indirimi talebinde sadece fiyat farkı değil, marj etkisi, müşterinin mevcut durumu, taahhüt değişikliği ve talep edilen istisnanın tek seferlik mi yoksa emsal oluşturacak türde mi olduğu görünmelidir.

Denetlenebilir iz burada devreye girer. Kim, ne zaman, hangi bilgiye bakarak onay verdi? Sonradan hangi alan güncellendi? Talep reddedilip revize edilerek tekrar mı geldi? Yorumlar nerede duruyor? Bunlar sistemde görünmüyorsa aynı konu haftalar sonra yeniden tartışılır.

Kayıt mantığı sadece denetim için değil, operasyon hafızası için de gerekir. Aynı tedarikçi için neden önce ret verildiğini bilmiyorsanız ekip tekrar aynı duvara çarpar. Aynı müşteri için hangi şartla istisna tanındığı görünmüyorsa satış ekibi emsal olmayan kararı emsal gibi kullanır.

Bir kuralı baştan koyun: Eksik bilgiyle gelen talep geri çevrilir. “Önce geçsin, sonra belgeyi tamamlarız” yaklaşımı kısa sürede kötü alışkanlığa dönüşür. İnsanlar en kısa yolu bulur, siz de sistemi delik deşik eden bir hız kültürü üretirsiniz.

Örnek onay paketi

• Tutar: 120.000 TL
• Bütçe kodu: ABC-2026-09
• Tedarikçi: DEF Teknoloji A.Ş.
• Gerekçe: CRM lisans yenilemesi
• Bütçe durumu: Bütçe içi
• Ek belgeler: Teklif dosyası, mevcut sözleşme, satın alma talebi.
• Liste fiyatı: 130.000 TL
• Teklif fiyatı: 120.000 TL
• Vade: 90 gün

Bu yapıyı kurmak için ayrı ayrı araçlar kullanmak zorunda değilsiniz. Örneğin Bitrix24 CRM ile görev yönetimi ve iş akışı otomasyonunu birlikte kullanarak satıştan satın almaya kadar farklı süreçleri tek akışta yönetebilirsiniz. Belirli tutarın üzerindeki teklifleri otomatik olarak onaya gönderebilir, eksik bilgili talepleri geri çevirebilir ve bekleyen işleri sorumlu kişiye hatırlatabilirsiniz. Böylece telefonla takip edilen işler sistemde görünür, sorumlusu ve sonraki adımı belli olan yönetilebilir iş akışlarına dönüşür.

Mobil erişimi telefon trafiğine alternatif olarak değil, yapılandırılmış hız avantajı olarak tasarlayın

Kurucuya ya da yöneticiye “telefonda aramak yerine uygulamadan onay ver” dediğinizde ilk itiraz genelde aynıdır: aramak daha hızlı. Oysa arama, iki tarafın aynı anda müsait olmasını gerektirir. Uygulama ise doğru bilgi paketini doğru kişiye doğru anda taşır.

Mobil onayın gerçekten hızlı olması için karar ekranı iyi tasarlanmalıdır. Onaycı tek ekranda karar özetini, ek belgeleri, risk bayraklarını ve önerilen aksiyonu görmelidir. “Bu neydi şimdi?” dedirten bir mobil ekran, insanları yeniden WhatsApp’a ve telefon aramasına iter.

Asgari mobil deneyim basit ama kritiktir:

• Push bildirim ile yeni talebin anında görünmesi
• Tek dokunuşla onay veya ret seçeneği
• Kısa yorum alanı
• Güvenli kimlik doğrulama
• Gerekirse masaüstünde detay incelemeye sorunsuz geçiş

Amaç masaüstünü öldürmek değildir. Bazı kararlar mobilde özet görülüp masaüstünde derin incelenir. Özellikle sözleşme değişikliği, yüksek tutarlı satın alma veya çok taraflı işe alım onaylarında bu geçiş normaldir. Mobilin rolü, bekleyen kritik talebi fark etmek ve ilk kararı geciktirmemektir.

Mesajlaşma uygulaması resmî süreç değildir. WhatsApp benzeri kanallar bildirim veya hatırlatma için işe yarayabilir; fakat yönlendirme, karar kaydı, yorum geçmişi ve revizyon takibi sistem içinde kalmalıdır. Yoksa birkaç ay sonra kimsenin toparlayamadığı ekran görüntüsü arşivleri oluşur.

Örneğin 120.000 TL’lik satın alma talebinde yönetici mobilde tutarı, bütçe kodunu, tedarikçiyi ve ek belgeleri görüp tek dokunuşla karar verebilir; daha ayrıntılı inceleme gerekiyorsa masaüstü kaydına geçebilir. Buradaki akış “bildirim → tek ekranda talep özeti ve kritik alanlar → onayla/reddet + kısa yorum → gerekirse masaüstünde detay inceleme” kuralını izlemelidir. Bitrix24’ün onay iş akışları yapısında onay adımları, yorum zorunluluğu, zaman aşımı ve delegasyon gibi kurallar tanımlanabildiği için bu akış telefon trafiğinin yerine doğrudan sistem içinde kurulabilir.

Yapılandırılmış mobil onay, telefon trafiğini azaltır çünkü konuşmayı değil kararı taşır. Karar verici, eksik bağlamı tamamlamak için insan kovalamaz; talep sahibi de “bir daha arayayım mı?” diye beklemez.

Ayrıca mobil erişimde hız güvenliğin önüne geçmemelidir. MFA ve mümkünse biyometrik doğrulama, cihaz kaybında erişimin kapatılması, kısa oturum zaman aşımı ve güvenilmeyen ağlarda hassas kararın güvenli şekilde bekletilmesi gibi kontroller belirlenmelidir.

Kontroller, istisnalar ve aylık gözden geçirme ile süreci kalıcı hâle getirin

Onay akışı bir kez kurulduktan sonra kendi kendine düzgün işlemez. İlk haftalarda her şey toparlanmış görünür, sonra bazı kararlar yine üst seviyeye tırmanır. Bazı ekipler sistemi dolaşır, bazı onaycılar her şeyi bekletir. Süreci ayakta tutan şey düzenli kontrol noktalarıdır.

Takip edilmesi gereken operasyonel sinyaller bellidir: Hangi talepler SLA süresini aşıyor, hangi eşiklerde gereksiz eskalasyon oluşuyor, sonradan iptal edilen onaylar hangi türde yoğunlaşıyor, sık tekrar eden istisnalar gerçekten istisna mı, aynı kişide biriken darboğazlar nerede oluşuyor?

Özellikle sonradan iptal edilen onaylara dikkat edin. Bu kayıtlar genelde eksik bilgiyle karar verildiğini ya da yönlendirme mantığının yanlış çalıştığını gösterir. Gösterge paneli tertemiz olabilir ancak sahada hâlâ geri sarılan işler varsa süreç tam oturmamıştır.

İstisna yönetimi yazılı olmazsa en iyi kurgu bile dağılır. Acil ödeme, kritik müşteri krizi veya sistem dışı verilen kararlar her zaman olacaktır fakat mesele bunları sıfırlamak değil, sonradan nasıl kayda alınacağını netleştirmektir: Hangi süre içinde sisteme işlenecek, kim doğrulayacak, hangi belge eklenecek?

Sistem dışında verilen bir acil ödeme kararı daha sonra “zaten telefonda konuştuk” diyerek açık bırakılmamalı. İlgili sorumlu talebi sisteme girmeli, karar sahibi bunu doğrulamalı, finans tarafı da ödeme dayanağını eklemelidir. Aksi hâlde istisna yolu kısa sürede ana yola dönüşür.

Aylık gözden geçirme rutini burada fark yaratır: Hangi onaylar gereksiz yere üst seviyeye gidiyor, hangi eşikler fazla düşük kaldığı için kuyruk yaratıyor, hangileri gereğinden yüksek olduğu için risk bırakıyor, hangi delegasyonlar güvenle genişletilebilir?

Bu gözden geçirme ekip davranışını da temizler. Bazı yöneticiler sorumluluk almamak için her şeyi yukarı iter, bazıları ise sınırı aşan işleri sessizce geçirir. Düzenli kalibrasyon yapılmadığında süreç ya aşırı merkezî olur ya da kontrolsüz gevşer.

Sağlam onay sistemi şu dengeyi kurar: Rutin kararlar hızla akar, istisnalar görünür olur, kayıt kaybolmaz, yoklukta akış durmaz. Patronun telefonu hâlâ önemli olabilir ama şirketin ana onay mekanizması artık orada kapalı kalmış değildir.