"Teklif otomasyonu" arandığında akla tek bir kutu geliyor: teklifle ilgili her şeyi bir yere at, gerisini bir sistem halletsin. Gerçekte teklif süreci tek bir iş değil, birbirinden oldukça farklı üç iştir: teklifi hazırlamak, teklifi göndermek, teklife cevap gelmezse takip etmek. Bir AI çalışanın hangi parçayı devralabileceğini sormadan önce bu üçünü ayırmak gerekiyor, çünkü üçü de aynı derecede tekrar eden bir iş değil.
Göndermek genelde zaten tektir — bir e-posta ya da mesaj olarak gider, bunun için ayrı bir otomasyona ihtiyaç yoktur. Asıl fark hazırlamak ile takip etmek arasında. Hazırlamak her seferinde biraz farklıdır: müşteri farklı, ölçü farklı, fiyat farklı. Takip etmek ise tam tersi — hangi müşteriye teklif verildiği değişir ama "cevap gelmedi, ne zaman ve ne yazarak hatırlatayım" sorusu her teklifte aynı biçimde tekrar eder. Bu yazı bu ayrımı takip ederek ilerliyor: önce hazırlamanın bugün nerede durduğunu dürüstçe anlatıyor, sonra bugün katalogda canlı olan takip ürününe geçiyor.
Bunu bir günün akışı üzerinden düşünmek işi somutlaştırıyor. Sabah bir müşteri arıyor, ölçü ve renk soruyor; sen ya da ekibin fiyat tablosuna bakıp bir teklif hazırlıyor, müşteriye gönderiyorsun — bu hazırlama ve gönderme adımı. Öğleden sonra başka bir işle uğraşırken, üç gün önce gönderdiğin bir teklifin hâlâ cevapsız durduğunu fark ediyorsun; hatırlıyorsan arıyorsun, hatırlamıyorsan bir sonraki hatırlatmaya kadar unutuluyor. Akşam masana oturup "kimden cevap bekliyorum" diye düşündüğünde, aklında birkaç isim var ama hangisinin ne zaman gönderildiğini, hangisine ne söylediğini net hatırlamıyorsun. İşte otomasyonun devreye girdiği yer tam burası: sabahki hazırlama ve gönderme adımı hâlâ senin elinde, ama akşamki "kimi aramalıyım, ne demeliyim" sorusunun cevabı artık bir listede hazır duruyor.
Teklif hazırlamanın devredilebilir kısımları
Bir teklif hazırlarken tekrar eden birkaç adım vardır: fiyat tablosuna bakıp doğru kalemi bulmak, müşteriden eksik bir bilgiyi (ölçü, adet, teslim yeri) sormak, şirketin her zaman kullandığı şablona göre bir taslak metin yazmak. Bunların hepsi teorik olarak bir AI çalışana yazdırılabilecek işler — model bir fiyat tablosunu okuyup şablona göre bir taslak üretebilir.
Ama burada dürüst olmak gerekiyor: bugün katalogda bu adımı üstlenen, canlı ve deneme vardiyasıyla denenebilir bir ürün yok. Yani "teklif hazırlama otomasyonu satın alabilir miyim" sorusunun cevabı şu an "hayır" — bu iş hâlâ senin ya da ekibinin elinde. Bu, ileride hiç olmayacağı anlamına gelmiyor; sadece bugün için gerçek durum bu. Bir sayfada bu adımı da yaptığını iddia eden bir ürün görürsen, deneme vardiyasını iste ve gerçek bir fiyat tablosuyla dene — iddia ile gerçek çıktı arasındaki fark orada görülür.
Bugün gerçekten devredilebilen kısım, teklif sürecinin bir sonraki adımında: teklif gönderildikten sonra, cevap gelene kadarki takip işinde.
Teklif sonrası takip: bugün canlı olan kısım
Bir teklif gönderdikten sonra üç şey olur: müşteri kabul eder, reddeder ya da hiç cevap vermez. Üçüncüsü asıl sorunlu olandır, çünkü ne zaman ve nasıl hatırlatma yapacağın belirsiz kalır. Beş teklifin varsa bunu aklında tutabilirsin. Otuz teklifin varsa, hangisinin ne zaman gönderildiğini, hangisine daha önce ne söylendiğini ve hangisinin süresinin dolmak üzere olduğunu hafızanda taşımak zorlaşır — genelde de birkaçı unutulur, kaybedilir değil, sadece hatırlanmaz.
Katalogda bugün canlı olan Teklif Sonrası Takip Çalışanı tam olarak bu boşluğu dolduruyor. Sana bir teklif tablosu (müşteri, tarih, tutar, konu, durum, en son ne zaman konuşulduğu, kısa bir not) verdiğinde, bekleyen teklifleri kimin önce aranması gerektiğine göre gerekçeli bir sıraya koyuyor ve her biri için bir takip mesajı taslağı yazıyor. Sıralama rastgele değil — önce geçerlilik süresi dolmak üzere olan teklifler, sonra en uzun süredir temas edilmeyenler, eşit durumdaysa tutarı büyük olan öne alınıyor. Her sıranın yanında gerekçesi de yazılı çıkıyor, "neden bu sırada" sorusu havada kalmıyor.
Mesaj taslakları da rastgele bir hatırlatma metni değil. Sistem, notundaki somut bir ayrıntıyı (örneğin "renk örneği istedi" ya da "eşiyle karar verecek") kullanarak taslağı ona göre açıyor; tutarı ve geçerlilik tarihini olduğu gibi yazıyor, girdide olmayan hiçbir rakamı, teslim tarihini ya da vaadi eklemiyor. Bunun bir önemi var: bir takip mesajının en kötü hâli, müşteriye söylenmemiş bir şeyi söylemiş gibi görünmesidir — bu, sistemin uydurmayı reddetmesiyle önleniyor.
Bir kardeş ürün olarak Çağrı Sonrası Takip Çalışanı ile karıştırılmamalı: o ürün bir telefon görüşmesinin notundan çalışır ve görüşme zaten yapılmıştır — iş, görüşmenin ardından ne yazılacağıdır. Buradaki ürün ise henüz cevap gelmemiş bekleyen teklifler üzerinde çalışır ve kendi öncelik sırasını üretir; ikisi farklı bir girdiyle, farklı bir soruya cevap veriyor.
Hangi işletmelere uygun
Bu ürün, belirli bir teklif hacmi olan işletmeler için anlamlı. Somut olarak şu üç özellik bir arada bulunuyorsa, teklif takibi işi gerçekten tekrar eden bir yük hâline gelmiş demektir:
- Aynı anda birden çok açık teklifin bulunması — beş, on, otuz, sayı önemli değil, önemli olan hepsini aynı anda takip etmek zorunda kalman
- Teklifler arasında cevap süresinin belirsiz olması — bazı müşteriler hemen döner, bazıları iki hafta sonra; bu belirsizlik hatırlatma zamanlamasını zorlaştırıyor
- Bir B2B ya da yüksek işlem tutarlı satış süreci — teklif, sipariş formu gibi anında dolan bir şey değil, üzerinde düşünülen bir karar
Mobilya atölyesi, yerel hizmet işletmesi (tadilat, etkinlik organizasyonu, danışmanlık), B2B tedarik gibi işlerde teklif genelde bu şekilde işler: teklif verilir, müşteri düşünür, bazen hiç dönmez. Böyle bir işte teklif takibi zaten var olan ama düzensiz yapılan bir iştir; bu ürün onu düzenli hâle getiriyor.
Somut bir örnek: küçük bir mobilya atölyesinin elinde aynı anda sekiz açık teklif olduğunu düşün. Biri geçen hafta verildi ve geçerlilik süresi birkaç gün sonra doluyor, biri iki hafta önce verildi ve o günden beri hiç aranmadı, biri de daha yeni verildi ama tutarı en yüksek olan teklif. Bu üçünden hangisini bugün araman gerektiğine elinle karar vermek mümkün ama zaman alıyor — tabloyu açıp tarihleri tek tek karşılaştırman gerekiyor. Aynı işi ürün, teklif tablosunu okuyup "önce şu, çünkü geçerliliği dolmak üzere; sonra şu, çünkü en uzun süredir temas edilmedi" diye gerekçesiyle sıralıyor. Sonuç değişmiyor, aynı kararı sen de verirdin; ama her seferinde tabloyu baştan taramak yerine, hazır bir sırayla işe başlıyorsun.
Hangi işletmelere uygun değil
Aynı derecede açık söylemek gerekiyor: her teklif süreci bu tanıma uymuyor.
Ayda bir ya da iki teklif hazırlayan, her teklifin tamamen özel pazarlıkla ilerlediği bir işletmede bu ürünün getirisi düşük olur — zaten hangi teklifi kimin nerede beklediğini hatırlamak zor değildir, sıralama ihtiyacı doğmaz. Aynı şekilde tekliflerin hepsi kısa vadeli olup birkaç gün içinde kesinleşiyorsa (örneğin bir online form doldurulduğu anda fiyat gösteriliyor ve karar hemen veriliyorsa), "bekleyen teklif" diye bir kategori zaten oluşmaz.
Bir işletmenin teklif süreci büyük ölçüde sözlü pazarlıkla, telefonda anlık karar verilerek ilerliyorsa da bu ürün doğru araç değil — o durumda ihtiyaç bir görüşme notundan takip mesajı çıkaran, yukarıda bahsedilen kardeş üründe olabilir. Teklif sayısı azken bir otomasyon kurmak, işi basitleştirmek yerine üstüne bir katman ekler; bu durumda elle takip etmeye devam etmek daha az işlem gerektirir.
Bir örnek: bir danışmanlık ofisi, ayda bir ya da iki büyük müşteriye teklif hazırlıyor olsun; her teklif haftalarca süren bir görüşme sürecinin sonunda, karşılıklı konuşarak şekilleniyor. Böyle bir işte hangi teklifin beklemede olduğunu unutmak zaten zor — zaten bir elin parmaklarını geçmiyor, her biri ayrı ayrı hatırlanıyor. Bu durumda bir sıralama aracı fazladan bir adım olur: girdi tablosunu hazırlamak, üründen çıkan sırayı okumak, senin zaten bildiğin bir şeyi doğrulamaktan öteye geçmez. Tersine, bu ofis on beş açık teklifle çalışan bir tedarik firmasına dönüşürse, aynı araç artık gerçek bir iş yapmaya başlar.
İnsan onayı ve sınırlar
Hiçbir mesaj otomatik olarak müşteriye gitmiyor. Ürettiği her taslak bir onay listesine düşüyor; işletme onaylıyor, düzeltiyor ya da reddediyor, gönderme kararını ve gönderme işlemini kendisi yapıyor. Bu, hızı biraz düşüren ama kontrolü elinde tutmanı sağlayan bir adım.
Günlük pratikte bu şöyle görünüyor: elinde tek bir dosya açılıyor, en üstte o gün aranması gereken tekliflerin sırası ve gerekçesi duruyor, altında her teklif için hazır bir mesaj taslağı ve taslağın altında bir "Karar" satırı yer alıyor. Sen ya da ekibin bu dosyayı yukarıdan aşağı okuyor, her taslağın yanına onay, düzelt ya da red yazıyor; onayladığın mesajı kendi WhatsApp'ından ya da e-postandan sen gönderiyorsun. Yani ortada senin okuman gereken uzun bir metin yok — hazır bir taslak var, senin işin onu okuyup göndermek ya da bir cümlesini değiştirip öyle göndermek. Bu birkaç dakikalık bir okuma işi; ortadan kalkan şey mesajı sıfırdan yazma ve kimi arayacağını bulma zamanı, ortadan kalkmayan şey son sözün sende olması.
İndirim konusunda da net bir kural işliyor: senin belirttiğin indirim ya da pazarlık yetkin "hayır" ise, hiçbir taslakta indirim dili geçmiyor. Yetkin "evet, şu koşulla" ise (örneğin "peşin ödemede yüzde beş"), yalnızca senin verdiğin bu koşul yazılıyor ve o taslak ayrıca işaretlenerek onayına gidiyor — sistem kendiliğinden bir indirim önermiyor.
Bazı teklifler bu sürecin dışında tutuluyor. Durumu zaten reddedilmiş ya da kazanılmış olan bir teklife mesaj yazılmıyor; geçerlilik süresi dolmuş bir teklif de aynı şekilde takip listesine girmiyor. Notunda şikâyet, hukuki bir ifade, ödeme anlaşmazlığı ya da iade geçen bir teklif de otomatik olarak insana devrediliyor — sistem bu durumlarda bir mesaj denemiyor, doğrudan "bunu sen değerlendir" diyerek gerekçesini yazıyor. Bu devir kararını model değil, önceden tanımlanmış bir kural veriyor; yani hassas bir durumun taslağa dönüşüp dönüşmeyeceği modelin o anki yorumuna bırakılmıyor. İnsan onayının bu tür ürünlerde genel olarak nasıl kurgulandığını merak edersen İnsan onaylı otomasyon nedir? yazısına bakabilirsin.
Kendi sürecini üçe ayır
Teklif sürecini hazırlama, gönderme ve takip diye üçe ayırdığında, hangi parçanın seni gerçekten yorduğunu görmek kolaylaşıyor. Eğer sorun her teklifi elle hazırlamaksa, bugün için bu bir insan işi olmaya devam ediyor. Eğer sorun kaç teklifin beklemede olduğunu, hangisine ne zaman hatırlatma göndermen gerektiğini takip edememekse, bunun bugün karşılığı olan bir çözüm var. Kendi sürecine bakıp hangi parçanın gerçekten tekrar ettiğini bulmak, doğru soruyu doğru ürüne sormanın ilk adımı. Karar vermeden önce ürünü kendi teklif tablonla denemek istersen, sürecin nasıl işlediğini Deneme vardiyası: bir AI çalışanı işe almadan önce nasıl denersin? yazısında bulabilirsin.