İçeriğe geç

Neyi Otomatikleştirmeli, Neyi Otomatikleştirmemeli? Ölçüt Süre Değil, Karar Yükü

Kategori
Rehber
Yayın tarihi
27 Ağustos 2026

Bir işin otomatikleştirilip otomatikleştirilmeyeceği tek soruyla belirlenir: o işin kararı önceden yazılabiliyor mu? Yazılabiliyorsa otomasyon uygundur. Yazılamıyorsa otomasyon işi hızlandırmaz — yanlışı hızlandırır.

Bu yazının adresinde "maliyet tasarrufu" geçiyor. Tasarruf rakamı vermeyeceğiz. Otomasyonun kaç saat ya da kaç lira kazandırdığına dair ölçülmüş bir verimiz yok; olmayan bir ölçümü yazmak da bu sitenin işi değil. Verebileceğimiz şey rakam değil ölçüt: hangi işin kuralı yazılabilir, hangisi yazılamaz.

Tez şu: otomasyonun asıl kazancı kazandırdığı zamanda değil, kaldırdığı karar yükünde. Bir ekibi yoran şey çoğu zaman işlerin süresi değil, her işte aynı kararı yeniden vermek zorunda kalmaktır.

Aşağıda otomatikleştirilebilir işin üç işareti, otomatikleştirilmemesi gereken dört iş, otomasyonun kimsenin bütçelemediği gizli maliyeti — kural bakımı — ve Rapitek CRM'in bu konudaki açık sınırları var.

Karar yükü
Otomasyon zaman kazandırdığı için değil, aynı kararı ikinci kez vermeyi gereksizleştirdiği için işe yarar. Karar hâlâ insana aitse kural o kararı ortadan kaldırmaz, yalnızca görünmez kılar.

Otomasyonun kazancı zamanda değil, karar yükünde

Otomasyon tartışması genellikle süre üzerinden yürür: "bu iş elle on dakika sürüyordu, artık sürmüyor." Bu ölçü yanıltıcıdır, çünkü on dakikanın büyük kısmı işi yapmakla değil, işi nasıl yapacağına karar vermekle geçer.

Somut örnek: web formundan gelen bir talebin hangi satışçıya gideceği. İşin kendisi bir atamadır, saniyeler sürer. Yorucu olan kısım her talepte "bu kimin bölgesi, kim müsait, bu firma daha önce kiminle konuşmuştu" sorularının yeniden sorulmasıdır. Kural yazıldığında kaybolan şey saniyeler değil, o üç sorudur.

Bunun pratik sonucu şu: bir işi otomatikleştirmeden önce bakılacak yer o işin süresi değil, kaç kez aynı kararı gerektirdiğidir. Günde kırk kez tekrarlanan otuz saniyelik bir karar, ayda bir yapılan yarım günlük bir işten daha iyi bir otomasyon adayıdır.

Ölçünün ters yönü de aynı yerden çıkar. Karar her seferinde farklıysa otomasyon o kararı kaldırmaz; yalnızca yanlış kararı daha çabuk uygular ve çabuk uygulandığı için kimse fark etmez.

Otomatikleştirilebilir işin üç işareti

Bir tetikleyicisi vardır. İşin ne zaman başlayacağı sistemde gerçekten olan bir olaya bağlanabiliyorsa — kayıt oluştu, aşama değişti, tarih geçti, form dolduruldu — o iş otomatikleştirilebilir. "Uygun bir zamanda" ya da "gerektiğinde" başlayan işin tetikleyicisi yoktur; onun tetikleyicisi bir insandır ve bu bir kusur değil, işin tanımıdır.

Kuralı yazıya dökülebilir. Sınaması basit: işi bugün yapan kişiden kararını eğer–ise cümleleriyle anlatmasını isteyin. Anlatabiliyorsa kural yazılabilir. "Duruma bakarım" diyorsa ortada henüz bir kural yoktur; önce kural konuşulur, sonra otomasyon. Bu sırayı atlayan projelerde otomasyon, yazılmamış bir kuralı yazılmış gibi gösterir.

İstisnası azdır. Burası en çok atlanan işaret. İstisnası olmayan iş yoktur; sorun istisnanın sıklığıdır. Kuralın on koşumundan üçü elle düzeltiliyorsa otomasyon iş yükünü azaltmaz, ikiye böler: bir kere makine yapar, bir kere insan düzeltir. Satış hattı aşamalarında bunun tipik hâli, çıkış kriteri net olmayan bir aşamaya bağlanmış otomatik bildirimdir.

Karar sınaması

Aynı işi iki ölçütle sınamak

Tablo puanlama değil sınamadır: ortadaki sütuna "hayır" düşen satır, otomasyonun değil kural konuşmasının konusudur. Satırlar örnektir; hangi işin nereye düştüğü şirkete göre değişir.
İşKuralı yazıya dökülebilir mi?Karar kimde kalmalı
Web formundan gelen talebi bölgeye göre atamakEvet — bölge alanı kayıtta duruyorMakine atar, istisnayı yönetici elle değiştirir
Tutar eşiğini aşan teklifi onaya düşürmekEvet — eşik bir sayıdırMakine düşürür, onayın kendisi insanda
Aşaması 30 gündür değişmeyen fırsatı işaretlemekEvet — tarih farkı hesaplanabilirMakine işaretler, kapatma kararı insanda
Kaybedilen fırsatın sebebini yazmakHayır — sebep her kayıtta farklıİnsan
İndirim talebine cevap vermekKısmen — eşik altı yazılabilir, üstü yazılamazEşik üstü insanda
Şikâyet eden müşteriye ilk dönüşü yapmakHayır — ton ve içerik duruma bağlıİnsan; makine yalnız işi zamanında düşürür

Otomatikleştirilmemesi gereken dört iş

Yargı isteyen işler. Bir fırsatın gerçekten kaybedildiğine, bir müşterinin memnuniyetsiz olduğuna ya da bir talebin istisna hak ettiğine karar vermek yargıdır. Bunları otomatikleştirmek teknik olarak mümkündür — sistem bir alan doldurur — ama kararın kalitesi düşer ve düştüğü kimseye görünmez. Doğru bölüşüm şu: yargıyı değil, yargı için gereken veriyi otomatikleştirin. Hazırlık makinede, karar insanda kalsın.

İstisnası kural kadar sık olan işler. Elle düzeltilerek yaşayan bir kural, kural değil bir öneridir. Böyle bir işi otomatikleştirmek görünür iş yükünü azaltmaz; yükü, kimsenin ölçmediği bir "düzeltme" işine taşır. Bu iş bir yerde raporlanmadığı için de otomasyon başarılı görünür.

Hata maliyeti yüksek işler. Fiyat yazmak, sözleşme göndermek, müşteriye toplu mesaj atmak. Buradaki soru "kural doğru mu" değil, "yanlış çalışırsa ne olur". Geri alınabilir bir hata otomatikleştirilebilir; geri alınamayan hatanın önüne bir insan onayı konur. Toplu mesaj tarafında bu, izin ve şablon denetiminin otomatik akışın dışında tutulması demektir.

Müşterinin insan beklediği işler. Bazı temaslarda otomatik cevabın kendisi bir mesajdır ve o mesaj şudur: "bu konuyu önemsemiyoruz." Şikâyet, iptal talebi, gecikme bildirimi. Bu temaslarda otomasyonun doğru yeri cevabı yazmak değil, cevabı yazacak kişiye işi zamanında ve bağlamıyla birlikte düşürmektir.

Otomasyonun gizli maliyeti: kural bakımı

Otomasyon tartışmasında kurulum maliyeti konuşulur, bakım maliyeti konuşulmaz. Oysa kurulan her kural, kurulduğu günden sonra bir varlık değil bir yükümlülüktür.

Birinci mekanizma eskime. Kural, kurulduğu andaki süreci varsayar. Süreç değişir — yeni bir aşama eklenir, bir alan yeniden adlandırılır, bir ekip ikiye bölünür — ama kural değişmez. Bozulduğunu da haber vermez; sessizce yanlış çalışır. Yanlış kişiye atar, dolması gereken alanı boş bırakır, tetiklenmemesi gereken bildirimi gönderir. Bunlar hata mesajı üretmez, çünkü teknik olarak hata değildir: kural tam da yazıldığı gibi çalışmaktadır.

İkinci mekanizma sahiplik. Kuralı kuran kişi genellikle onu izleyen kişi değildir. Kimsenin sahiplenmediği kural, yanlış çalıştığı hâlde aylarca yaşar; çünkü yanlışı gören kişi (satışçı) düzeltme yetkisi olan kişi (yönetici) değildir ve ikisinin arasında bir bildirim yolu yoktur.

Üçüncü mekanizma birikme. Kurallar eklenir, silinmez. Yirmi kuralın çalıştığı bir kurulumda hangi bildirimin hangi kuraldan geldiğini kimse bilmez; iki kural aynı işi yapmaya başlar ve müşteri aynı e-postayı iki kez alır. Bu noktadan sonra kimse kural silmeye cesaret edemez, çünkü hangi kuralın neyi tuttuğu belirsizdir.

Gizli maliyet buradadır: otomasyonun bedeli kurma emeği değil, kuralı canlı tutma emeğidir ve bu emek hiçbir teklifte kalem olarak görünmez.

Kural bakımı

Bir kuralı canlıya almadan önce yazılacak beş satır

  1. 1

    Kuralın tek cümlelik amacı

    Ne yaptığı değil, hangi tekrar eden kararı ortadan kaldırdığı. Bu cümle yazılamıyorsa kural henüz olgunlaşmamıştır; gereksiz kuralların çoğu bu adımda elenir.

  2. 2

    Tetikleyici ve kapsam

    Hangi olay başlatır ve hangi kayıtları kapsar. Kapsam yazılmadığında kural, kurulduğu ekipten sonra açılan ikinci ekipte de çalışır — ve bunu kimse istememiştir.

  3. 3

    Bilinen istisnalar

    Kuralın çalışmaması gereken durumlar tek tek yazılır. Bu adımda yazılamayan istisna kaybolmaz; sonradan elle düzeltme işi olarak geri gelir.

  4. 4

    Sahibi

    Kuralın yanlış çalıştığını kimin fark edeceği ve kimin değiştirme yetkisi olduğu. İkisi farklı kişiyse aradaki bildirim yolu da bu satıra yazılır.

  5. 5

    Gözden geçirme tarihi

    Kurala yeniden bakılacak bir tarih. Tarihi olmayan kural, süreç değiştiğinde gözden geçirilmez; hiçbir zaman gözden geçirilmez.

Rapitek CRM'de otomasyon ne yapar?

Rapitek CRM'de otomasyon görsel bir iş akışı motoruyla kurulur: kayıt oluştuğunda ya da değiştiğinde alan doldurma, görev açma, bildirim gönderme ve dış servise webhook atma adımları kod yazmadan zincirlenir. Akışların koşum geçmişi tutulur — yani bir kuralın ne zaman çalıştığı sonradan bakılabilir bir kayıttır.

Kuralın üzerine kurulacağı alanları da ekrandan açarsınız. Ölçüldü: 19 kiracı kod yazmadan toplam 277 özel alan tanımlamış, bir kiracı 9 özel nesne eklemiş. Bu, otomasyon tartışmasında görünmeyen bir ön koşuldur — kuralın okuyacağı alan yoksa kural da yazılamaz.

Motorun dışında kalan işler için REST API var: OAuth2 ile korunur, composite ucu tek istekte 25 alt-istek, toplu uç tek çağrıda 200 kayıt taşır. Sunucularımızda müşteri kodu çalıştırmıyoruz; gerçekten kod isteyen otomasyon sizin kendi uygulamanızda durur ve CRM'i API'nin ucundan kullanır. Bu tercihin sebebini Apex yazısında ayrıntısıyla anlattık.

Bizim sınırlarımız

Otomasyonun kendi kendini denetleyen bir yüzeyi yok: kurduğunuz bir kuralın hâlâ doğru çalışıp çalışmadığını size söyleyen bir uyarı üretmiyoruz. Koşum geçmişi tutuluyor, ama o geçmişi okuyup "bu kural artık yanlış kişiye atıyor" diyen bir denetim yok. O okumayı bir insan yapar.

Kural sahipliği ve gözden geçirme tarihi de üründe birer alan değil. Yukarıdaki beş satır bir özellik değil, bir çalışma alışkanlığıdır; bugün onları CRM'in içinde değil, kendi belgenizde tutarsınız.

Otomasyonun ne kadar zaman ya da para kazandırdığına dair bir ölçümümüz yok. Hiçbir kurulumda otomasyon öncesi ve sonrası süreleri karşılaştırmadık. Bu yüzden bu sayfada tasarruf rakamı görmüyorsunuz; başka bir sayfamızda da görmemelisiniz.

Hatalı biten işlerin görünürlüğü konusunda elimizdeki tek ölçüm içe aktarma tarafından geliyor: erişebildiğimiz 8 kiracıda çalıştırılan 34 içe aktarma işinden 16'sı hatayla bitti. Hatanın kendisi görünüyor; hatayı kimin sahiplendiği ürünün değil sizin kurgunuzun sorunu.

Belge imzalama ekranı üründe kurulu ama sahada ölçülmedi: ölçüm günü bakılan 8 kiracının 8'inde de 0 imza ve 0 imza talebi vardı. Sözleşme adımını otomatik bir akışın parçası saymadan önce bunu bilin.

Sık sorulanlar

Otomasyon hakkında sık sorulan sorular

Otomasyon gerçekten maliyet düşürür mü?
Düşürebilir, ama bunu bir rakamla söyleyemeyiz: otomasyon öncesi ve sonrası süreleri karşılaştıran bir ölçümümüz yok ve olmayan ölçümü yazmıyoruz. Söyleyebileceğimiz şey mekanizma. Otomasyon tekrarlanan bir kararı ortadan kaldırdığında kazanç kalıcıdır; kararı kaldırmayıp yalnızca işi hızlandırdığında kazanç, istisnaları elle düzeltme işine geri döner. Kendi işinizde ölçmek isterseniz bakılacak şey süre değil, aynı kararın haftada kaç kez verildiğidir.
Hangi işleri ilk turda otomatikleştirmeliyim?
Üç işareti birden taşıyanları: sistemde gerçekten olan bir olaya bağlanabilen, kuralı eğer–ise cümleleriyle yazılabilen ve istisnası seyrek olan işler. Pratikte bunlar genellikle atama, hatırlatma, aşama süresi takibi ve alan doldurmadır. Teklif onayının kendisi, fiyat kararı ve şikâyete ilk dönüş bu listeye girmez; bu işlerde otomatikleşen kısım kararın kendisi değil, kararı verecek kişiye işi zamanında düşürmektir.
Bir otomasyon kuralının yanlış çalıştığını nasıl fark ederim?
Kendiliğinden fark etmezsiniz. Yanlış çalışan kural hata vermez; tam da yazıldığı gibi çalışır, yalnızca yazıldığı süreç artık geçerli değildir. Fark etmenin işleyen iki yolu var: kuralın koşum geçmişini düzenli aralıklarla okumak ve kuralın çıktısını gören kişiye — çoğunlukla satışçıya — bir bildirim yolu açmak. Rapitek CRM koşum geçmişini tutar; o geçmişi okuyup "bu kural artık yanlış" diyen bir denetim üretmez.
Kaç otomasyon kuralı fazla sayılır?
Sayı ölçüt değil; ölçüt sahipliktir. Sahibi yazılı olmayan tek bir kural bile fazladır, sahibi belli yirmi kural yönetilebilir. Pratik bir sınama: ekibinize düşen bir bildirimi gösterip "bu hangi kuraldan geliyor" diye sorun. Cevap veren kimse yoksa kural envanteriniz sizden büyümüştür ve yeni kural eklemeden önce mevcutları elden geçirmek gerekir.
Küçük bir ekibin otomasyona ihtiyacı var mı?
İhtiyaç ekip büyüklüğüyle değil tekrar sayısıyla ölçülür. Üç kişilik bir ekip günde kırk kez aynı atama kararını veriyorsa ihtiyaç vardır; otuz kişilik bir ekip her işi farklı yapıyorsa otomasyon o farklılığı önce kurala çevirmeden işe yaramaz. Küçük ekipte asıl risk şudur: kuralı kuran kişi ekipten ayrıldığında kuralı tanıyan kimse kalmaz.
Otomasyonu kurmadan önce CRM'de ne hazır olmalı?
Kuralın okuyacağı alanlar ve kuralın bağlanacağı aşamalar. Alan yoksa kural yazılamaz; aşamaların çıkış kriteri yoksa aşamaya bağlı kural rastgele tetiklenir. Rapitek CRM'de alan ve nesne eklemek ekrandan yapılır — ölçüldü: 19 kiracı kod yazmadan 277 özel alan tanımlamış. Ama hangi alanın açılacağı bir ürün kararı değil, süreç kararıdır ve bu karar sizde kalır.
Bir kuralı kaldırmak ne zaman doğru olur?
Üç durumda: koşumlarının çoğu elle düzeltiliyorsa, çıktısını kimse okumuyorsa, ya da başka bir kural aynı işi yapıyorsa. Kural silmek kural kurmaktan daha az konuşulur, ama bakım yükünü asıl düşüren adım budur. Silmeden önce koşum geçmişine bakın: hiç çalışmamış bir kural zarar vermiyor gibi görünür, yalnızca envanterde yer kaplar ve sonraki kuralı yazan kişiyi yanıltır.

İlgili içerikler

Hangi işin kuralı yazılabilir, birlikte çıkaralım

Rapitek CRM'i kuran ekip, Salesforce döneminde 200'den fazla kurumsal CRM projesi tamamladı. Keşif görüşmesinde süreçlerinizi birlikte gözden geçirir, hangi işin kuralı yazılabiliyor ve hangisinin kararı insanda kalmalı — bunu yazılı çıkarırız.

Tasarruf rakamı vermiyoruz; hangi işin kural olarak yazılabildiğini birlikte çıkarır, kapsamı yazılı belirleriz.

Yazan

Kerim Yıldırım

Kurucu, Rapitek CRM · Salesforce döneminde 200'den fazla kurumsal CRM projesi

RapitekGO ile yapıldı

Ziyaretinizi ölçmek için isteğe bağlı çerez kullanmak istiyoruz. Reddederseniz site aynen çalışır. Çerez politikası