Otomatik onay mı, manuel onay mı? AI ajanının yetki tasarımı

Perşembe 16:40. Üç saat önce yayına alınan destek ajanının çalışma izinde 41 aksiyon görünüyor: 22 kart güncellemesi, 11 etiketleme, 6 görev açma ve müşteriye giden 2 e-posta. İlk 39'unu kimse fark etmedi, çünkü hepsi doğruydu. Son ikisi bir müşteriye "kurulumunuz tamamlandı" yazmıştı; oysa kurulum ertesi güne ertelenmişti. Ekip o akşam ajanı tümden kapattı ve bir daha açmadı. Sorun ajanın ne kadar iyi düşündüğü değildi — 41 aksiyonun kırk birine de aynı yetkinin verilmiş olmasıydı.

Bu yazı ajanı açıp kapatmak yerine yetkisini tasarlamayı anlatıyor. Önce yetki kararının neden ajan kurulmadan önce verildiğini, sonra bir aksiyonu otomatiğe almanın üç somut ölçütünü ele alıyoruz. Ardından ilk günden otomatik çalışabilecek işler, onay isteyen işler ve ikisini ayıran karar tablosu geliyor. Sonra onay kapısının kimin üzerinde duracağı, mesai dışında bekleyen isteklerin ne olacağı, güvenlik sınırlarıyla onay kapısının farkı, yapılan işin sonradan nasıl denetleneceği, kararın hangi ritimle gözden geçirileceği ve yetki genişledikçe maliyetin nasıl sınırlanacağı sırayla işleniyor.

Yetki kararı neden ajanı kurmadan önce verilir?

Çoğu ekip sırayı ters kuruyor: önce ajanı kuruyor, birkaç gün izliyor, bir şey ters gidince yetkiyi kısıyor. Bu sıra pahalı, çünkü öğrenme bedeli müşteriye ödetiliyor. Yetki tasarımı aslında ajanın ne yapabileceğini değil, yanlış yaptığında ne olacağını belirleyen bir karar. Ajanın doğruluk oranı yüzde doksan da olsa yüzde doksan dokuz da olsa, kalan payın nereye düştüğünü siz seçersiniz: bir kart alanına mı, yoksa müşterinin gelen kutusuna mı.

Rocketly'de bu karar teknik bir ayar değil, kurulumun bir parçası. Ajan CRM içinde 74 otonom aksiyon yürütebiliyor ve Onay Kontrolü Sizde ayarı her aksiyon türü için ayrı ayrı soruyor: bu otomatik mi çalışsın, yoksa sizin onayınızı mı beklesin. Yani "ajanı açtım" diye bir durum yok; açtığınız şey, tek tek işaretlediğiniz bir yetki listesi. Bu listeyi boş bırakmak da bir karar — ve genellikle yanlış olanı.

Bu yaklaşımın mantığı yeni değil. Ekip üyelerine hangi kaydı görüp hangisini düzenleyebileceklerini tanımlarken kullandığınız rol ve yetki matrisinin aynısını bu kez insan olmayan bir aktör için kuruyorsunuz. Fark şu: insan tereddüt eder, sorar, ekrandan çıkar. Ajan tereddüt etmez. Bu yüzden sınır kodda değil, ayarda durmalı.

Bir aksiyonu otomatiğe almanın ölçütü nedir?

Tartışma çoğu zaman "ajana güveniyor muyuz" diye başlıyor ve hiçbir yere varmıyor, çünkü güven ölçülebilir bir şey değil. Ölçülebilir olan aksiyonun kendisi. Üç soru, listeyi neredeyse tek başına ikiye ayırıyor.

Geri alınabilir mi? Yanlış etiket silinir, yanlış görev kapatılır, yanlış alan eski değerine döner. Gönderilmiş bir mesaj geri alınmaz. Geri alma maliyeti sıfıra yakınsa aksiyon otomatiğe adaydır.

Dışarıya dokunuyor mu? Aksiyonun sonucunu yalnızca ekibiniz mi görüyor, yoksa müşteri, tedarikçi ya da bir reklam platformu mu? Dışarıya dokunan her aksiyon, yanlış olduğunda kurumun sesiyle konuşmuş olur.

Görünür mü? Aksiyon yanlış yapıldığında biri bunu birkaç saat içinde fark eder mi, yoksa üç ay sonra raporda mı ortaya çıkar? Sessiz hatalar, gürültülü hatalardan daha tehlikelidir; çünkü birikirler.

Üç soruya da "risksiz" cevabı gelen aksiyonlar otomatik çalışsın. Herhangi birine "hayır" geliyorsa aksiyon onay kapısına girer. Bu, sezgi yerine geçen basit bir kural ve ekipte tartışmayı bitirir: kimse "ben güveniyorum" diyerek tartışmayı kazanamaz.

Hangi aksiyonlar ilk günden otomatik çalışabilir?

İç kayıt zenginleştirmesi bu listenin başında geliyor. Ajanın bir lead kartındaki boş sektör alanını doldurması, şirket büyüklüğünü yazması, kaynağı işaretlemesi geri alınabilir, dışarıya dokunmaz ve kartın kendisinde görünür. Zaten eksik kartı otomatik tamamlama mantığının tamamı bu güvenli bölgede yaşıyor; ajan burada yeni bir risk üretmez, sadece daha hızlı çalışır.

İkinci güvenli küme: özetleme ve not yazma. Bir görüşmenin ardından konuşmanın özetinin karta düşmesi, aramanın sonucunun koda bağlanması, bir sonraki adımın not olarak bırakılması — hepsi iç kayıt. Toplantı ve çağrı notlarının otomatik işlenmesi ajan için doğal bir ilk görev, çünkü hata yapsa bile hatayı okuyan kişi düzeltebilir.

Üçüncüsü ekip içi görev ve hatırlatma açmak. Fazladan açılmış bir görev sinir bozar ama zarar vermez. Buna karşılık ajanın açtığı görevlerin bir sahibi olmalı; sahipsiz görev, kimsenin bakmadığı bir kuyruğa dönüşür ve otomasyonun itibarını iç ekipte tüketir.

Hangi aksiyonlar müşteriye dokunduğu için onay ister?

Sınır çizgisi net: mesaj gönderen, para konuşan ve durum ilan eden her şey. Bir müşteriye giden e-posta ya da WhatsApp mesajı, bir teklifin oluşturulması, indirim tutarının yazılması, bir fırsatın kazanıldı olarak kapatılması, reklam bütçesinin artırılması. Bunların ortak noktası ajanın bilemeyeceği bir şeye dayanmaları: odadaki bağlam. Kurulumun ertelendiğini bilen kişi ekipteki insandır, ajan değil.

Burada özellikle dikkatli olunması gereken bir küme var: müşteriye giden ama zararsız görünen mesajlar. Otomatik teşekkür, otomatik anket daveti, otomatik yorum isteği. Satın alma sonrası değerlendirme toplama akışları tam da bu yüzden koşullu kurulur; teslimat gecikmiş bir müşteriye giden "deneyiminizi puanlayın" mesajı, hiç mesaj göndermemekten kötüdür. Ajan bu koşulu kendi başına kurmaz; siz kurarsınız.

İndirim ve fiyat kararları ise ayrı bir kategori. Bir ajanın teklif taslağı hazırlaması makul, indirim oranını kendi belirlemesi değil. İndirimli teklifi kimin onayladığı insan ekipte de yazılı bir kuralsa, ajan için de aynı kural geçerli olmalı — ajanı istisna yapmak, kuralı fiilen kaldırmak demektir.

Karar tablosu: hangi aksiyon hangi modda çalışsın?

Aşağıdaki tablo yukarıdaki üç ölçütü aksiyon kümelerine uygulanmış halde gösteriyor. Kurulum toplantısında ekranda tutmak için tasarlandı; satırlar sizin CRM'inizdeki aksiyon listesine göre çoğaltılabilir.

Aksiyon kümesi	Geri alınabilir mi?	Dışarıya dokunuyor mu?	Önerilen mod
Kart alanı, etiket, lead puanı güncelleme	Evet	Hayır	Otomatik
Not, özet ve çağrı sonucu yazma	Evet	Hayır	Otomatik
Ekip içi görev ve randevu açma	Evet	Hayır	Otomatik, sahip zorunlu
Müşteriye mesaj ve e-posta gönderme	Hayır	Evet	Manuel onay
Teklif oluşturma ve indirim yazma	Kısmen	Evet	Manuel onay, eşikli
Reklam bütçesi ve kampanya durumu	Kısmen	Evet	Manuel onay

Tablodaki "eşikli" ifadesi önemli. Yetki ikili olmak zorunda değil: belirli bir orana kadar otomatik, üstünde onaylı bir kurgu çoğu ekipte en gerçekçi denge. Aynı mantığı zaten insan tarafında da kuruyorsunuz.

Onay kapısı kimin üzerinde durmalı?

Onayı tek bir kişiye bağlamak, o kişi izne çıktığında ajanı fiilen durdurur. Onayı herkese açmak ise kapıyı anlamsızlaştırır. Doğru kurgu rol üzerine kurulan bir kapı: satış yöneticisi rolündeki kim müsaitse onaylar, kimse müsait değilse istek düşmez, kuyrukta bekler. Onay akışı otomasyonunda öğrenilen ders burada da geçerli — onayın gecikmesinin sebebi çoğu zaman kararın zorluğu değil, kararı verecek kişinin belirsizliğidir.

İkinci bir ayrım: onaylayan kişi ile ajanı kuran kişi aynı olmamalı. Ajanı kuran kişi kendi kurduğu aksiyonu onaylıyorsa, kapı bir kontrol değil bir formalitedir. Küçük ekiplerde bunu tam ayırmak zor olabilir; en azından müşteriye dokunan aksiyonlarda ayrı kişi kuralını koruyun.

Üçüncüsü, onay isteğinin ekrana nasıl düştüğü. Ekip sohbetine düşen ve bağlamı yanında getiren bir istek dakikalar içinde yanıtlanır; ayrı bir onay ekranına düşen istek saatlerce bekler. Ajan Rocketly'de ekip sohbetinde de çalıştığı için onay isteğini insanların zaten baktığı yere getirmek mümkün.

Mesai dışında bekleyen onay isteğine ne olur?

Ajanın en değerli olduğu saatler, kimsenin ofiste olmadığı saatler. Gece gelen bir talebe yanıt vermek, sabaha kadar bekleyen bir lead'i sıcak tutmak, hafta sonu düşen bir talebi sınıflandırmak. Ama tam da bu saatlerde onay verecek kimse yok. Yetki tasarımı bu boşluğu görmezden gelirse, ajan pratikte yalnızca mesai saatlerinde işe yarar hale gelir.

Üç çözüm var ve üçü de meşru. Birincisi zaman koşullu yetki: mesai içinde onaylı çalışan bir aksiyon, mesai dışında hiç çalışmaz. İkincisi daraltılmış otonomi: gece yalnızca bilgilendirici, taahhüt içermeyen yanıtlar otomatik gider; taahhüt gerektiren her şey sabaha kalır. Üçüncüsü kuyruk: ajan aksiyonu hazırlar, gönderilmeden bekletir, sabah ilk iş toplu onaya sunar.

Hangi çözümü seçerseniz seçin, müşterinin bir yanıt görmesi gerekir. Çalışma saatleri ve otomatik karşılama mesajları burada ajanın tamamlayıcısı: ajan taahhüt vermeden bağlamı toplar, karşılama mesajı ne zaman dönüleceğini söyler. Sessizlik, yanlış cevaptan sonraki en kötü seçenektir.

Güvenlik sınırları ile onay kapısı aynı şey mi?

Hayır ve bu ikisini karıştırmak yaygın bir hata. Onay kapısı "bunu yapabilirsin ama önce sor" der. Güvenlik sınırı "bunu hiçbir koşulda yapma" der. Birincisi bir gecikme, ikincisi bir yasak.

Rocketly'de Guardrails bu ikinci katmanı deklaratif olarak tanımlar ve sınırlar çalışma anında zorunlu tutulur; yani ajan onay istemez, o yolu hiç açmaz. Buraya yazılacak şeyler tipik olarak kurumsal taahhütlerdir: yasal metin yorumlamamak, garanti süresi hakkında söz vermemek, iade kararı ilan etmemek. Onay kapısına yazılacak şeyler ise iş kararlarıdır: indirim, gönderim, kapatma.

Üçüncü bir katman daha var ve genelde atlanıyor: ajanın neyi okuyabildiği. Ajan Bilgi Yönlendirme ile her ajanın hangi bilgi kaynaklarına erişeceğini tek tek seçersiniz — satış ajanı fiyat listesini okur, destek ajanı yalnız dokümantasyonu. Yetkiyi sadece yazma tarafında düşünmek eksik kalır; ajan okuyamadığı şey hakkında yanlış bir şey de söyleyemez.

Ajanın yaptığı işi sonradan nasıl denetlersiniz?

Yetki tasarımı, denetim olmadan bir varsayım listesidir. Ayarı doğru yaptığınızı ancak çalıştırmalara bakarak bilirsiniz. Çalışma İzi tam bunun için var: tüm ajanların çalıştırmaları tek akışta, her aksiyonun parametresi, sonucu, süresi ve onaylayanı kayıt altında. Onaylayan alanının orada olması tesadüf değil — bir aksiyonun otomatik mi geçtiği yoksa birinin mi onayladığı, sonradan sorulacak ilk sorudur.

İzi okurken üç şeyi ararsınız. Bir: onay kuyruğunda uzun bekleyen aksiyon türleri — bunlar ya gereksiz yere kapıya konmuştur ya da yanlış role bağlanmıştır. İki: onaya sunulup neredeyse her seferinde onaylanan türler — bunlar otomatiğe alınmaya hazır. Üç: onaya sunulup sık reddedilen türler — bunlar ajanın hiç yapmaması gereken, yani güvenlik sınırına taşınacak işler.

Bu üç sinyali haftalık bir alışkanlığa çevirmek için ayrı bir ekran açmanız gerekmez; zamanlanmış otomatik raporlarla onay kuyruğu özetini kendi kutunuza getirebilirsiniz. Kimse panoyu kendiliğinden açmaz, ama gelen özeti okur.

Yetki kararı ne zaman gözden geçirilir?

Doğru yaklaşım kademeli genişletme. İlk hafta yalnızca iç kayıt aksiyonları otomatik. İkinci ve üçüncü haftada, onay kuyruğunda sürekli onaylanan türler tek tek otomatiğe alınır — hepsi birden değil, seferde bir tane. Böylece bir sorun çıktığında hangi değişikliğin sebep olduğu belli olur.

Yayına almadan önceki adım da atlanmamalı. Test ve Önizleme paneli ajanı gerçek senaryolarla denemenizi sağlar; yanıtları ve aksiyonları müşterilere ulaşmadan görürsünüz. Bir yetki değişikliğini doğrudan canlıya almak yerine burada denemek, ekibin ajana güvenini bir hafta yerine bir saatte kurar.

Genişletme kararını hangi veriyle vereceğinizi de baştan belirleyin. Çözülen konuşma sayısı, insana devir oranı ve reddedilen onay oranı bu iş için yeterli. Metrikleri kime, hangi kırılımda göstereceğiniz ayrı bir tasarım işi; pano tasarımının temel sorusu burada da aynı: bu ekrana bakan kişi hangi kararı verecek?

Yetki genişledikçe maliyet nasıl sınırlanır?

Otonomi arttıkça çalışma sayısı da artar ve bu doğrudan tüketime yansır. Sınır koymadan genişletmek, ayın ortasında ajanın durması demek. Ajan Başına Kredi Tavanı ile her ajana aylık bir tavan koyabilirsiniz; tavanı aşacak bir çalıştırma daha başlamadan durdurulur. Bu bir fren değil, bir bütçe kararı: hangi ajanın ne kadar hakkı olduğunu ekip kendi belirler.

İkinci maliyet kalemi görünmez olanı: gereksiz çalıştırmalar. Ajanın her mesaja değil, tanımlı tetiklere yanıt vermesi hem tüketimi hem gürültüyü düşürür. Aksiyon sırasını modele bırakmak yerine Adım Adım Playbook ile tanımlamak da aynı işi görür — koşullu adımlar ve yan etkisiz prova modu, ajanın gereksiz yere dolaşmasını engeller.

Son olarak, insan kararının nereye gireceğini bir kez daha düşünün. Ajan otonomisi ile iş akışındaki onay bekle adımı aynı ihtiyacın iki farklı cevabı: biri modelin kararına kapı koyar, diğeri kural tabanlı bir akışı insanda duraklatır. Hangi işin hangisine ait olduğunu ayırmak, ikisini de daha sağlıklı çalıştırır.

Yetki listesini bir kere doğru kurduğunuzda ajan artık bir risk kaynağı değil, kapasite oluyor; kendi aksiyon listenizi çıkarmak için Rocketly hesabınızı ücretsiz açıp ilk ajanı yalnızca iç kayıt yetkisiyle çalıştırarak başlayabilirsiniz.

Sıkça sorulan sorular

Her aksiyonu manuel onaya alsam ne kaybederim?

Hızı ve mesai dışı kapsamı. Ajanın değerinin büyük kısmı, kimsenin bakmadığı anlarda işi ilerletmesinden geliyor. Her şeyi onaya bağlamak ajanı bir taslak üreticisine indirger; bu da bir kullanım biçimi ama daha dar bir tanesi. Geri alınabilir iç kayıt aksiyonlarını otomatiğe almak, kapıyı önemli işler için boş tutar.

Ajan onay bekleyen bir aksiyonu ne kadar tutar?

Bunu siz belirlersiniz ve belirlemeniz gerekir. Süresiz bekleyen istek, kuyrukta ölür. Pratik bir kurgu: belirli bir süre sonunda istek düşer, ajan konuşmayı insana devreder ve bunu izde işaretler. Karar verilmemesi de bir karardır; sistemin bunu sessizce yutmaması önemli.

Ajanın yanlış yaptığı bir aksiyonu nasıl geri alırım?

Geri alınabilirlik aksiyonun kendi doğasına bağlı, sisteme değil. Alan güncellemesi ve etiket geri alınır; gönderilmiş mesaj alınmaz. Bu yüzden ayrım en baştan yapılıyor. Çalışma izinden aksiyonun parametresini ve sonucunu görüp neyin değiştiğini tespit edebilir, geri alınabilir olanları elle düzeltebilirsiniz.

Birden fazla ajan varsa yetki her biri için ayrı mı tanımlanır?

Evet, ve öyle olmalı. Satış ajanı ile destek ajanının riski aynı değil. Ajan başına ayrı aksiyon yetkisi, ayrı bilgi kaynağı erişimi ve ayrı kredi tavanı tanımlamak, tek bir "her şeyi yapan" ajan kurmaktan hem güvenli hem ölçülebilir. Talebin doğru ajana gitmesi de ayrıca yönlendirme tarafında çözülür.