Teklif ve Satış Otomasyonu

Teklif otomasyonu projesinin başarısı modelin ne kadar akıllı olduğuna değil, firmanın fiyat bilgisini ne kadar düzenli tuttuğuna bağlıdır. Ürün adları tutarsız, iskontolar kişiden kişiye değişiyor ve teklif şablonu her temsilcide farklıysa yapay zeka bu dağınıklığı yalnızca hızlandırır.

Bu rehber, kurulumdan önce verilmesi gereken kararları sırayla ele alıyor: hangi firmada anlamlı olduğu, katalog ve fiyat verisinin nasıl hazırlanacağı, onay ve kayıt düzeni, hukuki çerçeve, devreye alma ve ölçüm. Her bölümde kendi sürecinize uygulayabileceğiniz somut bir kontrol ya da adım bulacaksınız.

01Teklif otomasyonu için uygunluk testi

Teklif otomasyonu, benzer talepleri sık alan ve fiyatı yazılı kurallarla belirlenebilen firmalarda işe yarar. Karar vermeden önce son üç ayda verdiğiniz teklifleri bir tabloya dökün ve her biri için talebin kanalını, kalem sayısını, hazırlık süresini ve fiyatın nasıl bulunduğunu not edin.

Tablo hazır olduğunda şu sorulara dürüst yanıt verin:

• Tekrar oranı: Tekliflerin çoğu aynı ürün gruplarından mı oluşuyor, yoksa her teklif yeni bir mühendislik çalışması mı istiyor?
• Fiyat kaynağı: Rakamlar güncel bir listeden mi geliyor, yoksa bir kişinin deneyimine mi dayanıyor?
• Hacim: Haftada kaç talep geliyor ve bunların ne kadarı yanıt beklerken bekletiliyor?
• Darboğaz: Zaman talebi anlamaya mı, fiyatı bulmaya mı, belgeyi biçimlendirmeye mi, yoksa takibe mi gidiyor?

Fiyat bir kişinin kafasında duruyorsa ilk iş otomasyon değil, o bilginin bir tabloya geçirilmesidir. Teklifler az ama karmaşıksa, iyi bir şablon ve CRM'de takip görevi çoğu zaman yeterlidir. Darboğaz yalnızca takipteyse, belge üretimine hiç dokunmadan hatırlatma akışıyla başlamak daha az riskle sonuç verir.

Testte dikkat edilecek bir nokta da kaybedilen tekliflerdir. Yalnız kazanılan teklifleri tabloya almak, sürecin gerçek darboğazını gizler; yanıtsız kalan ve geç gönderilen teklifler çoğu zaman en öğretici örneklerdir.

Bu testin bir yan faydası da vardır: tabloya döktüğünüz geçmiş teklifler, ileride akışı sınayacağınız gerçek veri setinin ilk hâli olur.

02Firma tipine göre teklif akışı nasıl değişir

Aynı teknik yapı, sektöre göre farklı bir işi üstlenir; bu yüzden ilk kapsamı firmanızın talep biçimine göre seçin. Aşağıdaki örnekler gerçek müşteri sonuçları değil, sık karşılaşılan talep tiplerinin tarifidir.

• Üretici sanayi firması: Talep çoğu zaman teknik çizim ya da şartname ekiyle gelir; akışın asıl işi ekten ölçü, malzeme ve adet çıkarmak, standart dışı kalemleri mühendise ayırmaktır.
• Toptancı ve distribütör: Yüzlerce kalemlik sipariş listeleri gelir; değer, müşteri grubuna göre kademeli fiyatı doğru uygulamak ve stokta olmayanları işaretlemektir.
• Nakliyat firması: Talep adres, kat, eşya listesi ve tarih içerir; akış eksik bilgiyi sorar, ekspertiz gerekip gerekmediğine karar vermeyi temsilciye bırakır.
• Yapı malzemesi bayisi: Metrekare ve adet dönüşümleri, nakliye bedeli ve şantiye teslimi kuralları belirleyicidir.
• Kurumsal hizmet firması: Paketler ve saat bazlı kalemler vardır; akışın katkısı kapsam metnini standart hâle getirmektir.

Talepleriniz sitenizdeki teklif formundan geliyorsa formun hangi alanları zorunlu tuttuğu, sonraki her adımın kalitesini belirler. Üretici firmalarda bu formun ürün kataloğuyla birlikte nasıl kurgulanacağını sanayi firmaları için web sitesi sayfasında ayrıca anlatıyoruz. Formu yeniden tasarlarken her alanın teklif belgesindeki hangi satıra karşılık geldiğini bir kez eşleştirmek, ileride akışın soracağı eksik bilgi sorularını belirgin biçimde azaltır.

03Akışın mimarisi sade dille

Bir teklif akışı, her biri tek işi yapan ve birbirine veri aktaran küçük adımlardan oluşur; böylece bir adım hata verdiğinde yalnız o adım düzeltilir. Mimariyi anlamak, teklif aldığınız ekiplerin ne kurduğunu karşılaştırmanızı kolaylaştırır.

1. Toplama: E-posta kutusu, form ve mesajlaşma kanalları tek bir iş kuyruğuna bağlanır; her talep benzersiz bir kayıt numarası alır.
2. Ayrıştırma: Dil modeli serbest metni okuyup önceden tanımlı alanlara yazar. Çıktı, her alanın tipini ve zorunluluğunu belirten bir JSON şemasına (yapılandırılmış veri kalıbı) uymak zorundadır.
3. Eşleştirme: Talepteki ürün ifadeleri katalogdaki stok kodlarıyla eşleştirilir; emin olunamayan eşleşmeler işaretlenir.
4. Hesap: Fiyat motoru, yani kurallarınızı uygulayan sıradan bir program, kalem tutarlarını hesaplar.
5. Belge: Şablon motoru numaralı teklif belgesini üretir; model yalnız kapak yazısını önerir.
6. Onay: Taslak, temsilcinin ekranına düşer; eşik aşılmışsa yönetici kuyruğuna gider.
7. Takip: Gönderim sonrası CRM'de aşama güncellenir ve hatırlatma görevleri açılır.

Bu yapıda yapay zeka yalnız ikinci, üçüncü ve beşinci adımlarda devrededir. Kalan adımlar kurala dayalı kod olduğu için aynı girdiye her seferinde aynı sonucu verir; denetim de bu sayede mümkün olur. Kurulum ve bakım yapay zeka otomasyonu hizmetimiz kapsamında yürür.

04Katalog ve ürün eşleştirme: en hassas adım

Teklif akışlarında hataların çoğu fiyat hesabında değil, müşterinin yazdığı ifadeyi doğru ürüne bağlama adımında çıkar. Müşteri "galvaniz 40'lık profil" yazar, katalogda ise stok kodu ve teknik ad vardır; aradaki köprüyü kurmak hazırlık ister.

Eşleştirme kalitesini artırmak için kurulumdan önce şu çalışmaları yapın:

• Eş anlamlı tablosu: Satış ekibinin ve müşterilerin bir ürün için kullandığı tüm adları, kısaltmaları ve eski kodları stok koduyla eşleştiren bir liste hazırlayın.
• Birim tanımı: Her ürünün satış birimini netleştirin; adet, metre, kilogram ya da paket karışıklığı yanlış tutarın en sık nedenidir.
• Varyant kuralı: Renk, ölçü ve kalınlık gibi seçeneklerin ayrı stok kodu mu, yoksa aynı kodun özelliği mi olduğuna karar verin.
• Pasif ürünler: Satıştan kalkmış kalemleri silmek yerine "yerine önerilen ürün" bilgisiyle işaretleyin.

Akış, her eşleştirme için bir güven puanı üretmeli ve belirlediğiniz düzeyin altındaki kalemleri temsilciye soru olarak göstermelidir. Teknik şartname, taranmış çizim ya da el yazısı sipariş formu gibi zor eklerle çalışıyorsanız, bu belgelerden alan çıkarma işini yapay zeka ile belge işleme sayfasında ayrıntılı ele alıyoruz. Eş anlamlı tablosu canlı bir belgedir; temsilcinin onay ekranında yaptığı her düzeltme bu tabloya yeni satır olarak önerilmelidir.

05Fiyat kurallarını yazıya dökmek

Fiyat motoru ancak yazılı kuralları uygulayabilir; bu yüzden ekipte sözlü dolaşan her istisnayı kurulumdan önce belgeye geçirin. Bu çalışma çoğu firmada, aynı ürüne neden farklı fiyatlar verildiğini ilk kez görünür kılar.

Kural belgesinde en az şu başlıklar yer almalıdır:

• Liste fiyatı ve geçerlilik: Hangi fiyat listesi sürümünün hangi tarihten itibaren geçerli olduğu ve eskisinin ne zaman kapandığı.
• Miktar kademeleri: Adet ya da tutar arttıkça uygulanan indirim basamakları ve bunların birbiriyle birleşip birleşmediği.
• Müşteri grubu: Bayi, proje müşterisi ve son kullanıcı gibi grupların fiyat farkları ve bir müşterinin hangi gruba ait olduğunun nereden okunacağı.
• Döviz ve kur: Döviz bazlı ürünlerde hangi kurun, hangi saatte alınacağı ve teklifte kur riskinin nasıl yazılacağı.
• Ek kalemler: Nakliye, montaj, ambalaj ve asgari sipariş bedeli gibi kalemlerin hangi koşulda eklendiği.
• Yuvarlama: Birim fiyatın ve toplamın kaç basamağa, hangi yönde yuvarlanacağı.

Her kuralın bir sahibi olmalı. Kuralı kimin değiştirebileceği yazılı değilse, ilk yoğun dönemde biri tablo üzerinde "geçici" bir düzeltme yapar ve akış o düzeltmeyle aylarca çalışır. Kural değişikliklerini sürüm numarasıyla saklamak, geçmiş bir teklifin neden o tutarla çıktığını sonradan açıklamanızı sağlar. Kural belgesini hazırlarken birkaç zor örnek teklifi elle yeniden hesaplamak, eksik kalan istisnaları kısa sürede ortaya çıkarır.

06CRM, ERP ve e-posta entegrasyonları

Teklif otomasyonu ayrı bir ada gibi çalışmamalı; fiyatı ERP'den okumalı, müşteriyi CRM'den tanımalı ve teklifi şirketin kendi e-posta hesabından göndermelidir. Entegrasyon planını çıkarırken her sistem için okunacak ve yazılacak alanları ayrı ayrı listeleyin.

• ERP ya da muhasebe yazılımı: Güncel fiyat, stok ve müşteri vadesi buradan okunur. API yoksa düzenli dışa aktarma dosyası kullanılır ve dosyanın tarihi her teklife yazılır.
• CRM: Teklif kaydı, aşama, sorumlu temsilci ve takip görevi buraya yazılır. Mükerrer müşteri kaydı açılmaması için eşleştirme vergi numarası ya da e-posta alan adıyla yapılır.
• E-posta: Teklif şirket alan adından, temsilcinin adıyla gider; gönderimden sonra yanıt aynı yazışma zincirinde kalır.
• Belge ve e-imza: PDF şablonu, numara serisi ve isteğe bağlı çevrim içi kabul bağlantısı bu katmanda yönetilir.

Otomatik üretilen tekliflerin müşterinin spam klasörüne düşmesi sık rastlanan ve geç fark edilen bir sorundur. Gönderimi açmadan önce alan adınızın kimlik doğrulama kayıtlarını SPF, DKIM ve DMARC kontrol aracıyla kontrol edin. Takip görevleri, aşama kuralları ve satış hattı düzeni gibi CRM tarafındaki işleri CRM otomasyonu çözümümüzde daha geniş anlatıyoruz. Teklif ekranı ya da bayi portalı gibi mevcut sistemlerde karşılığı olmayan bir arayüz gerekiyorsa bunu özel yazılım projesi olarak planlıyoruz.

07Model seçimi ve barındırma

Teklif akışında modelin işi sınırlı olduğu için en büyük modele ihtiyaç duyulmaz; önemli olan, yapılandırılmış çıktıyı tutarlı vermesi ve verinin nerede işlendiğidir. Model seçimini bir tercih tartışması olarak değil, kendi geçmiş taleplerinizle yapılan bir sınav olarak ele alın.

• Şemaya uyum: Aday modelleri aynı test setinde çalıştırıp şemaya uymayan, alan atlayan ya da alan uyduran çıktıların oranını karşılaştırın.
• Dil ve terminoloji: Türkçe teknik terimleri, kısaltmaları ve sektör jargonunu doğru ayrıştırıp ayrıştırmadığını kendi örneklerinizle görün.
• Ek okuma: PDF, tablo ve görsel ekleri okuyabilme yeteneği, şartnameyle çalışan firmalar için belirleyicidir.
• Veri işleme koşulları: Sağlayıcının veriyi eğitimde kullanıp kullanmadığını, saklama süresini ve işleme bölgesini sözleşmeden okuyun.

Talep içeriklerinin yurt dışındaki bir sağlayıcıya gitmesini istemeyen firmalar için, modeli şirketin kendi sunucusunda ya da yurt içindeki bir altyapıda çalıştırmak mümkündür. Bu seçenekte donanım, güncelleme ve bakım yükü size geçer; hangi durumda anlamlı olduğunu yerel LLM kurulumu sayfasında anlatıyoruz. Hangi model seçilirse seçilsin, akışın model sürümünü kaydetmesi gerekir; sağlayıcı modeli güncellediğinde test seti yeniden çalıştırılır.

08Onay matrisi ve iz kaydı

Hız kazanan bir teklif sürecinde denetimi koruyan şey, kimin neyi onaylayabileceğini gösteren yazılı bir onay matrisidir. Matris, iskonto sınırı gibi tek bir eşikten ibaret olmamalı; teklifin riskini belirleyen birkaç ölçütü birlikte değerlendirmelidir.

• Tutar: Belirli bir toplamın üzerindeki teklifler satış yöneticisine, çok daha yükseği genel müdüre gider.
• Marj: Hedef marjın altına düşen her teklif, tutarı küçük olsa da onaya takılır.
• Yeni müşteri: İlk kez teklif verilen firmalarda vade ve ödeme koşulu muhasebe onayından geçer.
• Standart dışı koşul: Özel teslim süresi, uzatılmış geçerlilik ya da sözleşme dışı madde içeren teklif her zaman insan onayı ister.

İz kaydı ise sonradan sorulacak sorulara cevap verir. Her teklif için gelen talebin özgün metni, modelin çıkardığı alanlar, temsilcinin değiştirdiği alanlar, kullanılan fiyat listesi sürümü, onaylayan kişi ve gönderim zamanı saklanmalıdır. Bu kayıtlar müşteriyle bir anlaşmazlık çıktığında başvuracağınız tek kaynak olur; ayrıca hangi alanın sık düzeltildiğini göstererek akışın neresinin iyileştirileceğini söyler. Kayıtların ne kadar süre tutulacağını muhasebe ve hukuk tarafıyla birlikte belirleyin. Onay ekranının kendisi de tasarım ister: temsilci yalnız değişen ya da düşük güvenli alanları vurgulu görmeli, tek tıkla kabul ve gerekçeli ret seçenekleri bulunmalıdır.

09Hukuki çerçeve: bağlayıcılık, ileti izni ve kişisel veri

Otomatik hazırlanan bir teklif, elle yazılan teklif kadar hukuki sonuç doğurur; bu yüzden hız, kontrol adımlarını atlamanın gerekçesi olamaz. Türk Borçlar Kanunu'nun 3. maddesine göre kabul için süre belirleyerek öneride bulunan, bu süre bitene kadar önerisiyle bağlıdır. Aynı kanunun 8. maddesi, fiyat listesi ya da tarife gönderilmesini de aksi açıkça anlaşılmadıkça öneri sayar.

Bu iki madde akış tasarımına doğrudan yansır:

• Geçerlilik tarihi: Her teklifte açık bir geçerlilik süresi bulunmalı; kur ve hammadde riski olan ürünlerde bu süre kısa tutulmalıdır.
• Standart koşullar: Bağlayıcılık, teslim ve ödeme koşullarını içeren metni hukukçunuz bir kez onaylamalı, akış bu metni değiştirmeden eklemelidir.
• Yanlış fiyat riski: Hatalı bir rakamın müşteriye ulaşması sizi o rakamla karşı karşıya bırakabilir; onay adımının asıl gerekçesi budur.

Takip mesajlarında ticari elektronik ileti kuralları geçerlidir: tanıtım amaçlı ileti için önceden onay gerekir, esnaf ve tacirler ise ret hakkını kullanmadıkça bu şarttan muaftır. Talep ve teklif verisi yurt dışındaki bir model sağlayıcıya gidiyorsa KVKK'nın 9. maddesindeki aktarım güvencelerinden biri gerekir. Müşteriyle doğrudan yazışan bir asistan kurulursa, AB Yapay Zeka Yasası'nın 50. maddesi kişinin bir yapay zeka sistemiyle etkileşimde olduğunu bilmesini ister; AB'deki müşterilere satış yapıyorsanız bunu da hesaba katın. Bu bölüm hukuki danışmanlık değildir; metinleri hukukçunuza onaylatın.

10Devreye alma adımları

Akışı tek seferde tüm satış ekibine açmak yerine, müşteriye hiçbir şey gitmeyen bir gölge dönemle başlayın. Gölge modda akış gerçek talepleri işler, taslak üretir ama bu taslakları yalnız proje ekibi görür; temsilciler her zamanki gibi çalışmaya devam eder.

1. Geçmiş taleplerle tekrar: Son dönemin taleplerini akıştan geçirin ve çıkan taslakları o gün gönderilen tekliflerle kalem kalem karşılaştırın.
2. Gölge mod: Yeni gelen talepler için paralel taslak üretin; farkları her gün kısa bir listede toplayın.
3. Kural düzeltmesi: Farkların kaynağını sınıflandırın: eşleştirme hatası mı, eksik kural mı, yoksa temsilcinin belgelenmemiş bir alışkanlığı mı.
4. Dar pilot: Tek ürün grubu ve gönüllü bir temsilciyle canlıya geçin; her teklif onaydan geçsin.
5. Eşik belirleme: Pilot kayıtlarına bakarak hangi teklif tiplerinin daha az kontrolle ilerleyebileceğine birlikte karar verin.
6. Genişletme: Ürün gruplarını ve temsilcileri tek tek ekleyin; her eklemede test setini yeniden çalıştırın.

Her adımın bir çıkış ölçütü olmalı. Örneğin gölge moddan pilota geçiş, belirli sayıda ardışık taslakta hesap farkı görülmemesine bağlanabilir. Bu ölçütleri baştan yazmak, "hazır mıyız" tartışmasını kişisel kanaatten kurtarır. Pilot süresince temsilcilerden haftada bir kısa geri bildirim almak da işe yarar; ekranda neyin yavaşlattığını, hangi uyarının gereksiz olduğunu ekranı her gün kullananlar bilir. Kullanıcıların benimsemediği bir akış, teknik olarak doğru çalışsa bile sessizce devre dışı kalır.

11Değeri ölçmek: hangi rakama bakmalı

Teklif otomasyonunun değerini görmek için kurulumdan önceki dönemi aynı yöntemle ölçmüş olmanız gerekir; başlangıç verisi olmayan bir projede kazanç ancak tahmin edilir. Ölçüm planını kurulumla aynı anda değil, kurulumdan önce yapın.

Süre ve kabul oranının ötesinde şu göstergeleri izlemenizi öneriyoruz:

• İlk yanıt ile tam teklif ayrımı: Müşteriye ilk dönüşün yapıldığı an ile fiyatlı teklifin gittiği anı ayrı ölçün; eksik bilgi sorusu ilk yanıtı hızlandırır.
• Taslak ile gönderilen arasındaki fark: Temsilcinin taslakta değiştirdiği kalem ve alan sayısı, akışın olgunluğunu en dürüst gösteren ölçüdür.
• Marj sapması: Gönderilen tekliflerin hedef marjdan ne kadar uzaklaştığını ürün grubu ve temsilci bazında izleyin.
• Revizyon sayısı: Bir teklifin kabul edilene kadar kaç sürüm gördüğü, ilk taslağın kalitesini gösterir.
• Yanıt hızına göre kazanma: Teklifleri hazırlık süresine göre gruplayıp kazanma oranlarını karşılaştırın; bu karşılaştırma pazar etkisinden arındırılmış değildir, yorum gerektirir.

Bu göstergeleri haftalık tek bir sayfada toplayın ve satış toplantısında aynı sırayla okuyun. Sayıların yanında her hafta birkaç örnek teklifi açıp birlikte incelemek, rakamların neden değiştiğini anlamanın en kısa yoludur.

12Sınırlar ve riskler

Teklif otomasyonu, iyi kurulmuş olsa da bazı riskleri tamamen ortadan kaldırmaz; onları görünür ve yönetilebilir kılar. Kurulumdan önce aşağıdaki riskleri ve her birine karşı alınacak önlemi proje belgesine yazın.

• Talimat enjeksiyonu: Gelen bir e-postanın içine modeli yönlendirmeye çalışan bir metin gömülebilir. Model yalnız alan çıkarmakla sınırlanmalı, fiyat ya da onay kararına erişimi olmamalıdır.
• Okunamayan ekler: Düşük çözünürlüklü taramalar ya da karmaşık tablolar yanlış okunabilir; güven puanı düşük ekler insana yönlendirilmelidir.
• Eskimiş fiyat: ERP bağlantısı koptuğunda akış eski dosyayla çalışmaya devam edebilir. Fiyat verisinin tarihi kontrol edilmeli, belirli bir süreyi aşan veriyle teklif üretilmemelidir.
• Sağlayıcı kesintisi: Model hizmeti yanıt vermediğinde talepler kaybolmamalı, kuyrukta beklemeli ve temsilciye bildirim gitmelidir.
• Aşırı güven: Uzun süre hatasız çalışan bir akışta temsilciler onay ekranını okumadan geçmeye başlar; rastgele seçilen tekliflerin ikinci bir kişi tarafından denetlenmesi bu alışkanlığı kırar.

Bu risklerin hiçbiri projeden vazgeçmek için tek başına neden değildir; ancak her biri için kimin, hangi bildirimle haberdar olacağı baştan belirlenmelidir.

13Sık yapılan hatalar ve daha iyi yolu

Teklif akışlarında görülen hataların çoğu teknik değil, hazırlık ve kapsam hatasıdır. Aşağıdaki listeyi kurulum öncesi bir kontrol listesi olarak kullanabilirsiniz; her maddenin ikinci cümlesi, aynı hedefe daha az riskle ulaşmanın yolunu gösterir.

• Fiyatı modele hesaplatmak: Dil modeli rakamları tutarsız işler. Daha iyisi, hesabı kurallı koda bırakıp modeli metin ve alan çıkarma işiyle sınırlamaktır.
• Dağınık fiyat listesiyle başlamak: Üç farklı Excel dosyası varken kurulan akış üç farklı hatayı hızlandırır. Önce tek bir onaylı liste oluşturun.
• Tüm ürünleri aynı anda kapsamak: İlk günden bütün kataloğu açmak hataların kaynağını bulmayı zorlaştırır. Tek ürün grubuyla başlayıp sonra genişletin.
• Onay adımını erken kaldırmak: Birkaç başarılı haftadan sonra otomatik gönderime geçmek caziptir. Kararı kayıtlara ve önceden yazılmış eşiklere dayandırın.
• Hesapları ajans adına açmak: Model, otomasyon ve CRM hesapları başkasının adına olursa iş ilişkisi bittiğinde akış da gider. Hepsini şirket adına açtırın.
• Takip mesajlarını izin kaydından bağımsız kurmak: Ret bildiren bir müşteriye otomatik hatırlatma gitmesi hem güven hem hukuk sorunu yaratır. Akışı ret listesini okuyacak şekilde kurun.

Bu hataların ortak noktası, hızın denetimin önüne geçmesidir. Projenin ilk haftalarında yavaş ilerlemek, sonradan bir yanlış teklifi geri almaya çalışmaktan her zaman daha ucuzdur; kontrol listesini her genişletme adımında yeniden gözden geçirin.

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

Teklif otomasyonu için çalışacağınız ekibi, önce sizin sürecinizi ne kadar ayrıntılı sorduğuna bakarak değerlendirin; ilk görüşmede araç adı sayıp sonuç vaat eden bir ekip, fiyat kurallarınızı henüz görmemiştir.

İyi bir ekip, keşif aşamasında geçmiş tekliflerinizi ister, fiyatı kimin nasıl hesapladığını adım adım dinler ve otomasyona uygun olmayan adımları da açıkça söyler. Bazen önerinin bir kısmı, otomasyon yerine fiyat listesini sadeleştirmek olur; bunu söyleyebilen ekip sizin çıkarınıza çalışıyordur.

Görüşmelerde şu soruları sorun ve yanıtları yazılı isteyin:

• Fiyat hesabını hangi katman yapacak ve model bu hesaba nasıl erişemeyecek?
• Akış canlıya çıkmadan önce hangi geçmiş taleplerle, hangi ölçütle sınanacak?
• Onay matrisi ve iz kaydı nerede tutulacak, kayıtlara kim erişebilecek?
• Model sağlayıcı değişirse ya da fiyatlarını değiştirirse akışın hangi kısmı etkilenecek?
• Teslimde hangi şablonlar, kurallar ve talimatlar şirketinize devredilecek?
• Canlıya çıktıktan sonra hata bildirimleri kime gidecek ve bakım hangi kapsamda sürecek?

Bu soruların yanıtları netse bir sonraki adım, son tekliflerinizden birkaçını, fiyat listenizi ve kullandığınız sistemlerin adlarını paylaşmanızdır. Bunları iletişim sayfasından bize iletebilirsiniz; kısa bir keşif görüşmesinin ardından hangi adımın otomasyona uygun olduğunu ve kapsamı yazılı olarak bildiririz. Keşif ve ilk akış için seçenekleri yapay zeka otomasyonu fiyatları bölümünde görebilirsiniz. Görüşmeye gelmeden önce bu rehberdeki uygunluk tablosunu doldurmanız, ilk toplantıyı tanışmadan çok karar toplantısına dönüştürür.