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.
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.
İçindekiler
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.
Aynı işi iki ölçütle sınamak
| İş | Kuralı yazıya dökülebilir mi? | Karar kimde kalmalı |
|---|---|---|
| Web formundan gelen talebi bölgeye göre atamak | Evet — bölge alanı kayıtta duruyor | Makine atar, istisnayı yönetici elle değiştirir |
| Tutar eşiğini aşan teklifi onaya düşürmek | Evet — eşik bir sayıdır | Makine düşürür, onayın kendisi insanda |
| Aşaması 30 gündür değişmeyen fırsatı işaretlemek | Evet — tarih farkı hesaplanabilir | Makine işaretler, kapatma kararı insanda |
| Kaybedilen fırsatın sebebini yazmak | Hayır — sebep her kayıtta farklı | İnsan |
| İndirim talebine cevap vermek | Kısmen — eşik altı yazılabilir, üstü yazılamaz | Eşik üstü insanda |
| Şikâyet eden müşteriye ilk dönüşü yapmak | Hayı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.
Bir kuralı canlıya almadan önce yazılacak beş satır
-
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
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
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
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
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.
Otomasyon hakkında sık sorulan sorular
Otomasyon gerçekten maliyet düşürür mü?
Hangi işleri ilk turda otomatikleştirmeliyim?
Bir otomasyon kuralının yanlış çalıştığını nasıl fark ederim?
Kaç otomasyon kuralı fazla sayılır?
Küçük bir ekibin otomasyona ihtiyacı var mı?
Otomasyonu kurmadan önce CRM'de ne hazır olmalı?
Bir kuralı kaldırmak ne zaman doğru olur?
İlgili içerikler
- Görev yönetimi nedir? — otomatik açılan görevin hangi kayda bağlandığı, kuralın işe yarar olup olmadığını belirler.
- Satış hattı (pipeline) nedir? — çıkış kriteri olmayan aşama, aşamaya bağlı her kuralı rastgele tetikler.
- CRM benimsemesi nasıl ölçülür? — kuralın yarattığı kayıt, insanın yarattığı kayıt gibi sayılırsa benimseme rakamı şişer.
- Apex nedir? — yapılandırma yetmediğinde kodun nereye konacağı ve neden platformun içine konmadığı.
- WhatsApp Business API entegrasyonu — otomatik mesajın izin ve şablon tarafı, akışın dışında kalır.
- Entegrasyonlar — webhook'un ucundaki sistemler: bugün çalışanlar ve talep üzerine kurduklarımız.
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.
Kerim Yıldırım
Kurucu, Rapitek CRM · Salesforce döneminde 200'den fazla kurumsal CRM projesi
