CRM Otomasyonu

CRM otomasyonu projeleri çoğu zaman ters sırayla başlar: önce bir otomasyon aracı seçilir, sonra akışlar çizilir, en son da verinin neden hâlâ dağınık olduğu sorulur. Bu rehber sırayı düzeltiyor; talebin nereden geldiğini saymaktan başlayıp alan tanımlarına, eşleştirme kurallarına, yapay zekanın sınırlarına ve ölçüme kadar işletme sahibinin vereceği kararları tek tek ele alıyor.

Anlatılanlar belirli bir CRM markasına bağlı değil; HubSpot, Pipedrive, Zoho CRM ya da kendi geliştirdiğiniz bir panel kullanıyor olun, aynı sorular geçerli. Bazı bölümler otomasyonu ertelemeniz gereken durumları da açıkça anlatıyor, çünkü yanlış zamanda kurulan bir akış veriyi düzeltmek yerine daha hızlı bozar.

01Bir haftalık talep dökümüyle ihtiyacı ölçün

CRM otomasyonuna karar vermeden önce yalnızca bir haftanın gelen taleplerini elle sayın; bu döküm hangi akışın gerçekten zaman kazandıracağını tahminden daha iyi gösterir. Her talep için kanalı, geliş saatini, ilk dönüş saatini, kimin cevap verdiğini ve CRM'e girip girmediğini bir tabloya yazın. Seçtiğiniz hafta olağan yoğunluğu temsil etmiyorsa sezonun ortasından ikinci bir hafta ekleyin.

Tablo dolduğunda şu sinyallere bakın:

• Kayıp: CRM'e hiç girmeyen talepler belirli bir kanalda toplanıyorsa ilk akış o kanalın giriş akışıdır.
• Gecikme: Talebin gelişiyle ilk dönüş arasındaki süre kişiden kişiye çok değişiyorsa sorun atama ve bildirimdedir, yapay zekada değil.
• Tekrar sorulan bilgi: Bütçe, tarih ya da adres gibi bilgiyi müşteriden ikinci kez istiyorsanız ilk mesajı okuyup alanlara ayıran bir adım değer üretir.
• Hacim: Ekip talepleri birkaç dakikada elle girebiliyorsa akışın bakım yükü kazandırdığı zamandan fazla olabilir.

Otomasyonu ertelemeniz gerektiği de bu tablodan anlaşılır. Satış aşamaları her çalışan tarafından farklı anlatılıyorsa ya da CRM'i fiilen tek bir kişi kullanıyorsa önce süreci yazılı hale getirin. Tanımsız bir alışkanlığa kural uydurmak, her istisnada akışı yeniden yazmak anlamına gelir.

02Şirket tipine göre ilk akışı seçmek

İlk akış satışın nerede tıkandığına göre değişir; aynı CRM otomasyonu bir danışmanlık firmasında ve bir abonelik işinde farklı halkadan başlar. Aşağıdaki eşleştirme kesin bir reçete değil, ilk görüşmede üzerine konuşulacak bir başlangıç noktasıdır.

• B2B hizmet ve danışmanlık: Talepler az ama değerlidir; görüşme notundan sonraki adımı çıkaran takip akışı, teklif sonrası sessizliği önler. Teklif belgesini hazırlamak ayrı bir iştir ve teklif otomasyonu sayfamızda ele alınır.
• Gayrimenkul ve araç satışı: İlan portalından, telefondan ve WhatsApp'tan gelen talepler dağınıktır; ilan numarasını ve bütçeyi okuyup doğru danışmana atayan giriş akışı önceliklidir.
• Eğitim kurumları ve kurslar: Dönem başında talep yığılır; veli ve öğrenci adına ayrı ayrı açılan kayıtları ayıklamak ve kayıt tarihine bağlı hatırlatma kurmak öne çıkar.
• Üretici ve toptancılar: Bayi yazışmaları e-posta ağırlıklıdır; ürün kodunu, adedi ve teslim yerini alanlara ayıran okuma adımı en çok zamanı kurtarır.
• Abonelik ve yazılım işleri: Deneme süresinin bitmesi, kullanımın düşmesi ve yenileme tarihi gibi olaylardan görev açan akış, müşteri kaybını erken fark ettirir.

Sağlık gibi özel nitelikli veri işleyen alanlarda ilk akışı seçerken veri sınırını da hesaba katın. Randevu talebinin kendisi CRM'e yazılabilir; şikâyet ya da teşhis içeren serbest metnin dil modeline gidip gitmeyeceği ise ayrıca ve yazılı olarak karara bağlanmalıdır.

03Alan sözlüğü ve her bilginin sahibi

Alan sözlüğü, CRM'deki her alanın ne anlama geldiğini, kimin doldurduğunu ve hangi sistemin asıl kaynak olduğunu yazan kısa bir belgedir; otomasyonun bütün kuralları bu belgeye dayanır. Basit bir tablo yeterlidir, yeter ki her satır tartışmaya yer bırakmasın.

Her alan için şu soruları yanıtlayın:

• Tanım: Sıcak talep ne demek: bütçe belirtmiş ve yakın tarihte karar verecek kişi mi, yoksa telefonla arayan herkes mi?
• Kabul edilen değerler: Serbest metin yerine seçim listesi kullanın; "İstanbul", "ist" ve "Istanbul" raporda üç ayrı şehir gibi görünür.
• Zorunluluk anı: Alan kayıt açılırken mi, teklif aşamasında mı zorunlu? Her şeyi baştan zorunlu yapmak ekibi uydurma veri girmeye iter.
• Sahip sistem: Vergi numarası ve fatura adresi muhasebede, iletişim tercihi CRM'de, sözleşme bitiş tarihi sözleşme arşivinde asıldır; akış yalnız sahip sistemden diğerine yazar.
• Yazma yetkisi: Akış bu alanı doğrudan yazabilir mi, yalnız önerebilir mi, yoksa hiç dokunamaz mı?

Aşama tanımları sözlüğün en çok tartışılan kısmıdır. Fırsat aşamasına geçiş için somut bir olay belirleyin: ihtiyaç görüşmesi yapıldı, karar verici belli, tarih konuşuldu gibi. Yazılı bir geçiş koşulu olmadan aşamaya bağlı görev ve rapor kurmak, herkesin farklı yorumladığı bir tabloyu otomatikleştirmek olur.

04Sade dille mimari: tetikleyici, kuyruk ve yazma adımı

Bir CRM akışı dört parçadan oluşur: olayı yakalayan tetikleyici, olayları sıraya koyan kuyruk, veriyi dönüştüren adımlar ve CRM'e yazan son adım. Parçaları ayrı düşünmek, bir şey bozulduğunda nerede bozulduğunu bulmayı kolaylaştırır.

• Tetikleyici: Form gönderimi ya da yeni mesaj, webhook denen anlık bildirimle akışa gelir; bu bildirimi sunmayan sistemlerde akış belirli aralıklarla yeni kayıt olup olmadığını sorar.
• Kuyruk: Olaylar sıraya alınır; CRM ya da model sağlayıcısı geçici olarak yanıt vermezse olay kaybolmaz, aralıklarla yeniden denenir.
• Dönüştürme: Telefon biçimi düzeltilir, metin okunur, eşleşme aranır. Her adımın girdisi ve çıktısı kayda geçer.
• Yazma: CRM'e yalnız sözlükte izin verilen alanlar yazılır ve aynı olay ikinci kez gelirse yeni kayıt açılmaz. Bu özelliğe tekrar güvenliği (idempotency) denir; atlanırsa çift kayıtların kaynağı akışın kendisi olur.

Araç seçimi bu yapıdan sonra gelir. n8n, Make ya da Zapier gibi platformlar orta hacimde hızlı kurulur; kişisel verinin kendi sunucunuzda kalmasını istiyorsanız kendi barındırdığınız bir n8n kurulumu, çok özel kurallar ya da yüksek hacim varsa kodla yazılmış bir servis daha uygundur. Hazır CRM'lerin hiçbiri iş modelinize uymuyorsa özel yazılım geliştirme seçeneğini de masaya koyun. Kurulum ve bakımı birlikte yürüttüğümüz çerçeve yapay zeka otomasyonu hizmetimizde anlatılıyor.

05Kanal kanal talep girişi nasıl kurulur

Her kanal veriyi farklı biçimde taşır; bu yüzden tek giriş kapısı, gelen her şeyi ortak bir kayıt şablonuna çevirmekle başlar: kişi, kanal, kaynak, ham metin ve geliş zamanı. Kanal bazında dikkat edilecek noktalar şunlardır:

• Web formu: Formda görünmeyen gizli alanlarla kampanya, sayfa ve reklam tıklama kimliği kaydedilir. Bağlantılarınızı tutarlı etiketlemek için UTM link oluşturucu kullanın; etiketsiz trafik raporda kaynaksız görünür.
• WhatsApp: Kayıt, WhatsApp Business Platform'un webhook bildirimiyle açılır. Kişinin son mesajından sonraki 24 saat içinde serbest yanıt verilebilir, bu süre dolunca yalnız onaylı şablon mesaj gider; hatırlatma süreleri bu pencereye göre kurulur. Sohbeti karşılayıp bilgiyi toplayan bir asistan için WhatsApp yapay zeka asistanı sayfamıza bakın.
• E-posta: İmza bloğu, alıntılanmış eski yazışma ve yasal uyarı metni ayıklanmadan model metni okursa yanlış kişiyi ya da eski bir tarihi alır.
• Telefon: Santral çağrı kaydı veriyorsa arayan numara ve süre otomatik düşer; görüşme notu kısa bir mobil formla ya da sesli notun yazıya dökülmesiyle alınır.
• Fuar ve etkinlik: Kartvizit fotoğrafından okunan bilgi doğrudan kayıt açmaz, onay kuyruğuna gider; pazarlama izni orada ayrıca sorulur.

Kanalları tek tek bağlayın ve her birini kendi deneme kaydıyla sınayın: bir form doldurun, kendi numaranızdan mesaj atın, ortak adrese bir talep gönderin. Kaydın hangi alanlarla ve hangi sorumluya düştüğünü kontrol etmeden bir sonraki kanala geçmeyin.

06Yinelenen kayıtları eşleştirme ve birleştirme kuralları

Yinelenen kayıt kontrolü, karşılaştırmadan önce veriyi aynı biçime getirmekle başlar; biçim farkı giderilmeden yapılan eşleştirme aynı kişiyi iki ayrı kişi sanar. Telefon numaraları ülke koduyla tek biçime çevrilir (uluslararası E.164 standardı), e-posta adresleri küçük harfe indirilir, firma adlarından "A.Ş.", "Ltd. Şti." ve "Sanayi ve Ticaret" gibi ekler yalnız karşılaştırma için çıkarılır.

Eşleşme daha sonra üç seviyede değerlendirilir:

• Kesin eşleşme: Aynı e-posta ya da aynı telefon. Akış yeni kart açmaz, talebi mevcut kayda yeni bir etkinlik olarak ekler.
• Olası eşleşme: Farklı adres ama aynı firma alan adı ve benzer isim. Akış birleştirme önerisi hazırlar, kararı kaydın sahibi verir.
• Zayıf eşleşme: Yalnız isim benzerliği. Yeni kayıt açılır, iki kart birbirine notla bağlanır.

Birleştirmede hangi değerin kalacağı da önceden yazılmalıdır. Genel kural şudur: en son doğrulanan iletişim bilgisi, en eski oluşturma tarihi ve en kısıtlayıcı izin durumu korunur. Kişilerden biri pazarlama iletisini reddetmişse birleşen kayıt da reddi taşır.

Gmail ya da Hotmail gibi ortak posta servislerinin alan adlarına firma eşleştirmesi uygulanmaz; uygulanırsa yüzlerce bireysel müşteri tek bir şirkete bağlanır. Eşleştirme kuralları, mevcut veritabanında gölge modda çalıştırılıp çıkan birleştirme listesi bir kişi tarafından gözden geçirilmeden açılmaz.

07Yapay zekanın CRM'deki yeri ve model seçimi

Dil modeli CRM'de karar veren değil, okuyan bir yardımcıdır: serbest metni alanlara ayırır, sınıflandırır ve özet yazar; fırsatın kaybedildiğine, indirime ya da kaydın silinmesine karar vermez. Bu sınır, kaçınılmaz hataların etkisini küçük tutar.

Okuma adımını güvenilir yapmak için şunları isteyin:

• Yapılandırılmış çıktı: Model serbest cevap değil, alan sözlüğündeki değerlerden oluşan sabit bir şemaya göre yanıt verir; listede olmayan değer reddedilir.
• Bilinmiyor seçeneği: Metinde bütçe yoksa model tahmin etmez, alanı boş bırakır. Bu seçenek tanınmazsa model boşluğu makul görünen bir değerle doldurur.
• Kanıt alıntısı: Model her değerin yanında metinden aldığı kısa alıntıyı döndürür; kontrol eden kişi kararı kaydı açmadan doğrular.
• Güven eşiği: Belirsiz kalan sınıflandırmalar CRM'e yazılmaz, inceleme kuyruğuna düşer.

Model seçiminde en büyük model çoğu zaman gerekmez. Sınıflandırma ve alan çıkarma için küçük ve hızlı bir model, uzun görüşme notlarının özeti için daha güçlü bir model kullanılabilir. Barındırma kararı veri hassasiyetine bağlıdır: ücretli API katmanında verinin eğitimde kullanılmadığı koşullar belgelenir; veri hiç dışarı çıkmamalıysa yerel LLM kurulumu değerlendirilebilir. Hangi model seçilirse seçilsin, aynı örnek setle karşılaştırmalı test yapılmadan model değiştirilmez.

Bu örnek set, ekibinizin daha önce elle işlediği ve kişisel bilgileri maskelenmiş gerçek taleplerden oluşur. Her talep için doğru konu, aciliyet ve alan değerleri yazılıdır; böylece model ya da istem değiştiğinde isabet tahminle değil, aynı sınavla karşılaştırılır.

08Görev, hatırlatma ve tırmandırma tasarımı

Takip akışının değeri hatırlatma sayısında değil, doğru kişiye doğru anda giden tek bir görevdedir; fazla bildirim, hiç bildirim olmamasından daha çabuk görmezden gelinir. Bu yüzden her aşama için bir yanıt süresi tanımlayın: yeni talebe ilk dönüş, tekliften sonraki arama, hareketsiz fırsatın gözden geçirilmesi gibi.

• Tek görev, tek sahip: Görev bir ekibe değil bir kişiye atanır; kişi izindeyse yedek sorumlu takvimden otomatik belirlenir.
• Mesai takvimi: Süreler çalışma saatleri ve resmi tatillere göre işler; cuma akşamı gelen talep pazar gecesi uyarı üretmez.
• Kademeli tırmandırma: Süre dolunca önce sorumluya, gecikme sürerse yöneticisine haber gider. Doğrudan yöneticiye giden uyarı ekipte savunma refleksi yaratır.
• Bağlamlı görev: Görevde model özeti, son yazışma ve önerilen sonraki adım yer alır; sorumlu kaydı baştan okumadan ne yapacağını bilir.
• Kendiliğinden kapanma: Görev, CRM'de ilgili etkinlik görüldüğünde, örneğin arama kaydı ya da gönderilen e-posta düştüğünde kapanır.

Müşteriye gidecek takip iletilerini akış taslak olarak hazırlayabilir, gönderim kişide kalır. Bu e-postalar kendi alan adınızdan çıkacağı için alan adı ayarlarınızı SPF, DKIM ve DMARC kontrolü ile önceden doğrulayın; aksi halde iletiler istenmeyen klasörüne düşebilir ve takip hiç yapılmamış gibi sonuçlanır.

09İzin, aydınlatma ve yurt dışına aktarım

CRM otomasyonu kişisel veriyi daha hızlı taşıdığı için hukuki hatayı da hızlandırır: yanlış bir kural tek bir kaydı değil, yüzlerce kaydı aynı anda etkiler. Aşağıdaki maddeler hukuki görüşün yerini tutmaz; kurulumda hukukçunuzla birlikte kontrol edilmesi gereken başlıklardır.

• Ticari ileti onayı: Pazarlama içerikli ileti için alıcının önceden onayı gerekir. İYS dışında alınan onay üç iş günü içinde İYS'ye kaydedilmezse geçersiz sayılır, ret ulaştıktan sonra gönderim üç iş günü içinde durdurulur; akış İYS durumunu CRM'deki izin alanıyla düzenli eşitler.
• Aydınlatma: KVKK'nın 10. maddesi, veri toplanırken kişinin bilgilendirilmesini ister. Form, WhatsApp karşılama mesajı ve telefon akışında aydınlatma metnine nasıl ulaşıldığı ayrı ayrı belirlenir.
• Otomatik analiz: KVKK'nın 11. maddesi, verilerin münhasıran otomatik sistemlerle analiz edilmesi sonucunda kişinin aleyhine çıkan sonuca itiraz hakkı tanır. Talep puanlaması birine hizmet vermemek için kullanılıyorsa karar bir insanda kalmalıdır.
• Yurt dışına aktarım: CRM ya da model sağlayıcısı yurt dışındaysa 9. maddedeki güvencelerden biri gerekir; standart sözleşme imzadan itibaren beş iş günü içinde Kurum'a bildirilir.
• Saklama: Akışın ara kayıtlarında duran kişisel veri için süre yazılı belirlenir, süresi dolan kayıt silinir.

Avrupa Birliği'ndeki müşterilerin verisini de işliyorsanız GDPR'ın kendi kuralları ayrıca uygulanır; iki çerçevenin kesiştiği noktaları tek bir veri akışı haritası üzerinde konuşmak işi kolaylaştırır.

10Onay kuyruğu, çalışma kaydı ve bilinen riskler

Bir akışın güvenilirliği hiç hata yapmamasından değil, hatanın görünür ve geri alınabilir olmasından gelir. Onay kuyruğunda her öneri; önerilen değer, alanın önceki değeri ve modelin dayandığı alıntıyla birlikte görünür, sorumlu tek tıkla kabul ya da ret eder. Reddedilen öneriler, modelin sonraki testlerinde örnek olarak kullanılır.

Kurulumdan önce şu riskleri ve karşılıklarını konuşun:

• Sessiz hata: CRM'de bir alanın adı değişince akış hata vermeden boş değer yazabilir. Her sabah önceki günün işlem sayısını beklenen aralıkla karşılaştıran bir kontrol bunu yakalar.
• Model değişimi: Sağlayıcı modeli güncellediğinde aynı metin farklı sınıflanabilir; kullanılan model sürümü sabitlenir, geçiş örnek setle test edilir.
• Metne gizlenmiş talimat: Bir e-postaya modeli yönlendirmeye çalışan cümleler gömülebilir. Modelin silme yetkisi olmadığı ve çıktısı şemayla sınırlandığı için etkisi dar kalır; şüpheli metinler yine de işaretlenir.
• Döngü: Akışın CRM'e yazdığı değişiklik akışı yeniden tetiklerse sonsuz döngü oluşur; akış kendi değişikliğini tanıyan bir etiket taşır.
• İstek sınırı: CRM API'lerinin belirli sürede kabul ettiği istek sayısı sınırlıdır; toplu aktarımlar kuyrukla ve parça parça yapılır.

11Kurulumu adım adım yürütmek

Kurulum, her adımda bir geri dönüş noktası bırakacak şekilde sıralanır; bir adım beklendiği gibi gitmezse bir öncekine dönmek veri kaybettirmez. Önerdiğimiz sıra şöyledir:

1. Döküm ve hedef: Bir haftalık talep tablosu çıkarılır, ilk otomatikleştirilecek halka seçilir ve başarının neyle ölçüleceği yazılır.
2. Sözlük ve aşamalar: Alan tanımları ve aşama geçiş koşulları satış sorumlularıyla birlikte yazılır, yönetim tarafından onaylanır.
3. Veri akışı haritası: Hangi alanın hangi sisteme ve hangi sağlayıcıya gittiği çizilir; bu harita hukuki değerlendirmenin girdisidir.
4. Yedek ve temizlik: CRM'in tam dışa aktarımı alınır, mevcut yinelenen kayıtlar birleştirme listesiyle ayıklanır.
5. Test ortamı: Akış ayrı bir test hesabında, kişisel bilgileri maskelenmiş gerçek örneklerle kurulur ve hata senaryoları denenir.
6. Gölge mod: Akış canlı veriyi okur ama yalnız öneri üretir; öneriler ekibin kararlarıyla karşılaştırılır.
7. Kademeli yazma yetkisi: Önce kaynak ve kanal gibi düşük riskli alanlar, isabet doğrulandıkça sınıflandırma alanları açılır.
8. Belgeli teslim: Akış belgesi, anahtar listesi ve aylık gözden geçirme takvimi teslim edilir; bakım sorumlusu yazılı belirlenir.

İlk akış oturmadan ikinci akışa geçmeyin. İkinci akış, birincinin ölçüm sonuçlarıyla ve ekibin onay kuyruğunda en çok uğraştığı konuyla seçildiğinde daha az sürpriz çıkarır.

12CRM otomasyonunun değerini ölçmek

Ölçüm, akış kurulmadan önce alınan bir başlangıç değeriyle başlar; önceki durum bilinmeden yapılan karşılaştırma tahminden öteye geçmez. İlk temas süresi ve veri kalitesinin yanında şu göstergeler otomasyonun gerçekten iş gördüğünü ortaya koyar:

• Aşamalar arası geçiş: Talepten fırsata ve fırsattan satışa geçen kayıtların payı, otomasyondan önceki dönemin aynı sezonuyla karşılaştırılır.
• Aşamada bekleme: Fırsatların bir aşamada ne kadar kaldığı, hareketsiz fırsat uyarısının işe yarayıp yaramadığını gösterir.
• Kaynak bilinirliği: Kaynağı boş kalan talep payı düşmüyorsa formdaki gizli alanlar ya da bağlantı etiketleri hatalıdır. Kanalların katkısını yorumlarken atıf modeli karşılaştırma aracı farklı modellerin aynı veriyi nasıl okuduğunu gösterir.
• Elle düzeltme sayısı: Ekibin akışın yazdığı değeri kaç kez değiştirdiği, modelin isabetinin en dürüst göstergesidir.
• Bakım yükü: Akışın durduğu ve müdahale gerektirdiği durumlar kaydedilir; bu kayıt, kazanılan zamandan düşülmesi gereken maliyeti gösterir.

Satıştaki artışı tek başına otomasyona bağlamayın. Aynı dönemde reklam bütçesi, fiyat ya da ekip değiştiyse etkiler birbirine karışır; otomasyonun doğrudan etkisi en net biçimde süre, eksik kayıt ve kayıp talep sayılarında görünür.

13CRM otomasyonunda sık yapılan hatalar

Aşağıdaki hataların çoğu teknik değil, karar sırasıyla ilgilidir ve kurulumdan sonra düzeltilmesi kurulumdan daha uzun sürer. Her maddede hatanın yarattığı sorunu ve yerine yapılması gerekeni birlikte yazdık.

• Her kanalı aynı anda bağlamak: Hangi akışın neyi değiştirdiği ölçülemez hale gelir. Bunun yerine tek bir darboğazla başlayın, ölçün ve sonra genişletin.
• İki yönlü eşitlemeyi varsayılan yapmak: İki sistem birbirinin verisini sürekli ezer. Her alan için tek bir sahip sistem belirleyin ve akışı yalnız o yönde kurun.
• Modele bütün kaydı göndermek: Gereksiz kişisel veri dışarı çıkar ve maliyet artar. Yalnız okunması gereken metni, kimlik ve ödeme bilgilerinden arındırarak gönderin.
• Akışı bir çalışanın kişisel hesabıyla kurmak: Çalışan ayrıldığında akış sessizce durur. Hesapları şirket adına ve ayrı bir servis kullanıcısıyla açın.
• Eski veriyi temizlemeden otomasyon kurmak: Eşleştirme kuralları kirli tabanda yanlış birleştirme önerir. Önce birleştirme listesiyle temizlik yapın, sonra akışı açın.
• Hata alarmı kurmamak: Durmuş bir akış haftalarca fark edilmez. Her başarısız çalışmayı bir kişiye bildirin ve haftalık bir çalışma raporu gönderin.

Bu listeyi teklif aşamasında iş ortağınızla birlikte okuyun ve her madde için hangi önlemi aldığını sorun. Net bir cevap alamadığınız madde, projenin en zayıf noktası olmaya adaydır.

14İş ortağı seçimi ve sonraki adım

Doğru iş ortağı akış çizmeden önce alan sözlüğünüzü, verinizin durumunu ve onay kurallarınızı sorar. Teklif aldığınız her ekibe şu soruları yöneltin ve cevapları yazılı isteyin:

• İlk teslim edilen şey bir akış mı, yoksa alan sözlüğü ve veri akışı haritası mı?
• Otomasyon platformu, CRM anahtarları ve model hesabı kimin adına açılıyor; iş birliği bittiğinde akışı kim çalıştırır?
• Gölge mod hangi ölçüte göre bitiyor ve yazma yetkisi hangi alanlar için açılıyor?
• Model yanlış bir değer yazarsa geri alma nasıl yapılıyor; bunu canlı bir örnekle gösterebilir misiniz?
• CRM ya da model sağlayıcısı değişiklik yaptığında akışı kim, hangi sürede kontrol ediyor?

Bu alanda yayında gösterebileceğimiz bir müşteri CRM otomasyonu projemiz henüz yok; bu yüzden ilk görüşmede sonuç vaadi yerine ilk akışın kapsamını, gölge mod planını ve ölçüm göstergelerini yazılı olarak öneriyoruz. Kullandığınız CRM'i, talep aldığınız kanalları ve en çok aksayan takip adımını iletişim formu üzerinden yazmanız yeterli.

Keşif çalışması ve ilk akış için sabit kapsamlı seçenekleri yapay zeka otomasyonu fiyatları bölümünde görebilirsiniz. CRM, otomasyon platformu ve model kullanım ücretleri doğrudan sağlayıcılara ödendiği için teklif yalnız kurulum ve bakım emeğini kapsar; kapsam netleştiğinde yazılı teklifi göndeririz.