# Niwera AI > İşletmeler için yapay zekâ danışmanlığı, AI ajanları, WhatsApp ve CRM entegrasyonu ile iş süreci otomasyonu çözümlerini inceleyin. Asıl sayfa (canonical): https://niwera.ai/ ## Niwera AI Ne Yapar? İşletmeler için yapay zekâ danışmanlığı, iş süreçleri otomasyonu ve özel geliştirme. Çalışmalar sayfasında WhatsApp, CRM, sipariş ve tedarik, tekstil, sosyal medya ve AI asistan iş akışları incelenebilir. ## Hizmetler ve Kullanım Alanları ### AI ajanları ve chatbotlar WhatsApp ve web konuşmalarını kurumsal bilgi, CRM kaydı ve gerektiğinde insan devriyle yönetin. İlgili sayfa: https://niwera.ai/calismalarimiz/whatsapp/ ### İş akışı otomasyonu ve API entegrasyonu Sipariş, stok, kargo ve finans adımlarını iş kuralları, API bağlantıları ve onaylarla ilerletin. İlgili sayfa: https://niwera.ai/calismalarimiz/siparis-tedarik/ ### Gelişmiş veri analizi CRM, sipariş ve operasyon verilerini tek görünümde birleştirip karar için anlaşılır içgörülere dönüştürün. İlgili sayfa: https://niwera.ai/calismalarimiz/crm/ ### Kurumsal bilgi ve özel AI Dokümanları ve şirket bilgisini, erişim yetkilerine uyan özel AI asistanlarıyla kullanılabilir hâle getirin. İlgili sayfa: https://niwera.ai/#iletisim ### Özel yazılım ve entegrasyon Mevcut araçlarınıza bağlanan web arayüzleri, sunucu tarafı servisleri ve işletmenize özel AI bileşenleri geliştirin. İlgili sayfa: https://niwera.ai/#iletisim ## Çalışmalar Bunlar Niwera’nın kendi markaları için kurduğu sistemlerin yerel simülasyonlarıdır. Simülasyonlar gerçek müşteri verilerine veya üretim sistemlerine bağlı değildir; bir müşteri referansı ya da başarı garantisi olarak sunulmaz. - [Bir insanın sohbette yaptığı işin tamamı .](https://niwera.ai/calismalarimiz/whatsapp/) - [Shopify’a girmeye bile gerek kalmadan, tek merkezden .](https://niwera.ai/calismalarimiz/siparis-tedarik/) - [Beden, renk, seri. Koleksiyon mantığıyla çalışan satın alma.](https://niwera.ai/calismalarimiz/giyim-siparis/) - [Otuz bin kişi. Tek müşteri kaydı.](https://niwera.ai/calismalarimiz/crm/) - [Haftalık sinyal araştırmasından yayına .](https://niwera.ai/calismalarimiz/sosyal-medya/) - [Şirketi konuşarak yönetmek.](https://niwera.ai/calismalarimiz/anton/) ## İletişim - E-posta: contact@niwera.ai - Telefon: +90 533 148 4186 - Konum: Bursa - Turkey ## Rehberler ve Diğer Biçimler - [Blog](https://niwera.ai/blog/) - [İçerik haritası](https://niwera.ai/llms.txt) - [Tüm metinler](https://niwera.ai/llms-full.txt) --- # CRM Entegrasyonu: Dağınık Veriden Tek Müşteri Kaydına > WhatsApp, sipariş, form ve e-posta verilerini doğru müşteride birleştirin. Kimlik eşleştirme, veri sahipliği ve izinleri gözeten CRM entegrasyonu rehberi. - Asıl sayfa (canonical): https://niwera.ai/blog/crm-entegrasyonu-tek-musteri-kaydi/ - Yazar: Niwera AI - Yayın tarihi: 2026-09-12 - Konu: Veri ve Entegrasyon - Dil: Türkçe (tr) Bir müşteri satış ekibine e-posta gönderir, WhatsApp'tan ürün sorar ve başka bir gün internet sitesinden sipariş verir. Bu temaslar farklı kayıtlarda kalırsa işletme aynı kişiyi birkaç ayrı müşteri gibi görebilir. Sonuç, tekrar sorulan sorular ve hangi bilginin güncel olduğuna dair belirsizliktir. **Tek müşteri kaydı**, bütün veriyi düşünmeden tek bir tabloda toplamak değildir. Aynı kişiye ait kayıtları doğru eşleştirmek, önemli alanların kaynağını belirlemek ve ilgili ekibin ihtiyaç duyduğu geçmişi tutarlı biçimde gösterebilmektir. ## Bir Bağlantı Kurmak Neden Yeterli Değil? İki sistem arasında veri akışı başlatmak teknik olarak mümkündür; ama hangi alanın hangi yönde taşınacağı net değilse iki tarafta da hatalı bilgi oluşabilir. CRM'de düzeltilen telefon numarasını eski bir sipariş kaydı geri yazabilir. Bir sistemde kapatılan müşteri, başka bir kaynaktan yeniden oluşturulabilir. Bu yüzden entegrasyonun ilk işi API bağlantısı değil, veri sahipliği kararıdır. Sipariş durumu sipariş sistemine, iletişim tercihi izin kaydına, satış sorumlusu CRM'e ait olabilir. Her alan için hangi kaynağın esas alınacağı ve uyuşmazlıkta ne yapılacağı belirlenmelidir. [Microsoft'un veri birleştirme dokümantasyonu](https://learn.microsoft.com/en-us/dynamics365/customer-insights/data/data-unification), kaynak alanlarının seçimi, yinelenen kayıtların bulunması, tablolar arası eşleştirme ve birleşik görünüm oluşturma adımlarını ayrı ele alır. Bu ayrım, belirli bir CRM ürünü seçmeseniz de sorunu düşünmek için yararlıdır. ## Müşteri Kimliğini Nasıl Eşleştirirsiniz? E-posta adresi veya telefon numarası iyi bir başlangıç olabilir; ancak tek başına her durumda kesin kimlik değildir. Ortak kullanılan şirket numaraları, yazım hataları, değişen adresler ve birden çok şubeyle çalışan kişiler dikkate alınmalıdır. Eşleştirme kurallarını açık yazın. Kesin eşleşme ile olası eşleşmeyi ayırın. Belirsiz kayıtları otomatik birleştirmek yerine incelemeye bırakın. Birleştirme işleminin hangi kuralla yapıldığı kaydedilmeli; yanlış birleşme sonradan ayrılabilmelidir. Yapay zekâ, benzer kayıtları inceleme sırasında yardımcı olabilir. Fakat yalnızca benzer isimlere bakarak müşterilerin siparişlerini, özel notlarını veya iletişim izinlerini birleştirmesine izin vermek ciddi hatalara yol açabilir. Kimlik kararı ile metin benzerliği aynı şey değildir. ## Profil Bilgisi ile Hareket Geçmişini Ayırın Müşterinin adı, telefon numarası ve tercih ettiği iletişim kanalı profil bilgisidir. Verdiği siparişler, destek talepleri ve gerçekleşen görüşmeler ise zaman içinde çoğalan hareket kayıtlarıdır. Bunları tek bir satıra sıkıştırmak yerine ilişkili kayıtlar olarak tutmak daha anlaşılır bir yapı sağlar. Profil güncellendiğinde geçmiş siparişin teslimat adresinin değişmemesi gerekir. Aynı şekilde, bir görüşmenin özeti yeni bir görüşmeyle sessizce silinmemelidir. | Veri Grubu | Tasarımda Sorulacak Soru | | --- | --- | | Müşteri profili | Güncel bilgi hangi sistemde tutuluyor? | | Sipariş geçmişi | Her işlem doğru müşteriyle nasıl ilişkilendiriliyor? | | İletişim tercihi | İznin kapsamı ve değişiklik zamanı nerede kayıtlı? | | Destek kaydı | Talebin sahibi, durumu ve geçmişi nasıl izleniyor? | Bu yapı, hem ekiplerin aynı bilgiye bakmasını hem otomasyonların daha güvenilir girdilerle çalışmasını kolaylaştırır. ## Entegrasyon Hatalarını Görünür Yapın Bağlantılar her zaman kesintisiz çalışmayabilir. Aynı olay iki kez gelebilir, bir istek zaman aşımına uğrayabilir veya iki sistem farklı anda güncellenebilir. Hata yönetimi yalnızca geliştiricinin sonradan inceleyeceği bir log dosyasına bırakılmamalıdır. Tekrarlanan bir olayın aynı işlemi ikinci kez oluşturmaması için olay kimliklerini takip edin. Başarısız güncellemeleri görünür bir kuyruğa alın. Yeniden deneme ve manuel düzeltme yollarını belirleyin. Ekip, hangi kaydın hangi sistemle senkronize olmadığını anlayabilmelidir. Özellikle müşteriye mesaj gönderme gibi dış etkisi olan işlemlerde yeniden deneme daha dikkatli tasarlanmalıdır. Teknik bir zaman aşımı, mesajın hiç gönderilmediğini her zaman kanıtlamaz. Gönderim durumunu doğrulamadan aynı işlemi tekrarlamak müşteriye mükerrer mesaj ulaştırabilir. ## Segment Oluşturmadan Önce İzinleri Kontrol Edin Bir müşterinin geçmiş siparişlerini görmek, o kişiye her kanaldan pazarlama mesajı gönderebilmek anlamına gelmez. İletişim tercihi, kampanya listesi ve erişim yetkisi ayrı konulardır. İzin kaydını kaynağı ve zamanı ile birlikte saklamak; iletişimi durdurma taleplerini ilgili sistemlere yansıtmak gerekir. Ekip üyelerinin yalnızca görevleri için gerekli alanlara erişmesi de tasarımın parçasıdır. Faaliyetinizin tabi olduğu kişisel veri ve ticari ileti kuralları ayrıca değerlendirilmelidir. WhatsApp üzerinden iletişim kuruyorsanız [platformun mesajlaşma politikası](https://business.whatsapp.com/policy) da dikkate alınmalıdır. Müşteri verisini birleştirmek, platform ve mevzuat yükümlülüklerini ortadan kaldırmaz. ## Nereden Başlamak Daha Mantıklı? İlk entegrasyonda bütün müşteri geçmişini taşımak yerine, somut bir sorunu çözebilirsiniz. Örneğin destek ekibinin bir görüşme sırasında doğru siparişi bulmasını sağlayın. Ardından eksik eşleşmeleri ve veri hatalarını ölçün; yeni kaynakları bu temel oturduktan sonra ekleyin. İyi bir CRM entegrasyonu, daha fazla alan gösteren bir ekran değil, ekiplerin karar verirken güvendiği bir kayıt düzenidir. [CRM çalışmamız](/calismalarimiz/crm/) bu yaklaşımı örnek bir simülasyonla gösterir. Konuşma tarafındaki bağlantıları ise [WhatsApp otomasyonu rehberinde](/blog/whatsapp-otomasyonu-siparisten-musteri-hizmetlerine/) ele alıyoruz. CRM projesi için sağlayıcı karşılaştırırken connector listesinin ötesine geçin: veri sahipliği, çift yönlü senkronizasyon, hata düzeltme, erişim yetkisi ve taşınabilirlik teklifin parçası olmalıdır. [İş süreci otomasyonu firması seçim rehberi](/blog/en-iyi-otomasyon-firmasi-secim-rehberi/) bu soruları tek bir değerlendirme tablosunda toplar. ## Kaynaklar - [Microsoft Learn: Data Unification Overview](https://learn.microsoft.com/en-us/dynamics365/customer-insights/data/data-unification) - [WhatsApp Business Messaging Policy](https://business.whatsapp.com/policy) Anlatılan akışlar genel tasarım örnekleridir. Veri modeli, yetkiler ve mevzuat değerlendirmesi işletmenin gerçek koşullarına göre belirlenmelidir. --- # En İyi Otomasyon Firması Nasıl Seçilir? İş Süreçleri İçin Rehber > Endüstriyel otomasyonla iş yazılımı otomasyonunu ayırın; teklifleri entegrasyon, güvenlik, hata yönetimi, maliyet ve taşınabilirlikle karşılaştırın. - Asıl sayfa (canonical): https://niwera.ai/blog/en-iyi-otomasyon-firmasi-secim-rehberi/ - Yazar: Niwera AI - Yayın tarihi: 2026-09-12 - Konu: Otomasyon ve Entegrasyon - Dil: Türkçe (tr) “En iyi otomasyon firması” araması iki farklı pazarı aynı sonuçlarda gösterebilir. Bir tarafta PLC, SCADA, robotik, sensör ve makine kontrolüyle çalışan **endüstriyel otomasyon** firmaları; diğer tarafta CRM, ERP, e-posta, WhatsApp ve özel yazılımları bağlayan **iş süreci otomasyonu** ekipleri vardır. Yanlış kategoriden teklif istemek zaman kaybettirir ve gerçek ihtiyacı görünmez kılar. **Kısa yanıt:** Önce fiziksel üretim hattını mı, yoksa ekiplerin ekranlar arasında yürüttüğü bilgi ve onay akışını mı otomatikleştirdiğinizi belirleyin. İş yazılımı otomasyonu için firmaları süreç analizi, API entegrasyonu, istisna yönetimi, güvenlik, insan onayı, toplam maliyet ve taşınabilirlik üzerinden karşılaştırın. ## Endüstriyel Otomasyon mu, İş Süreci Otomasyonu mu? | Alan | Tipik kapsam | Aranacak uzmanlık | | --- | --- | --- | | Endüstriyel otomasyon | Makine, üretim hattı, PLC, SCADA, sensör, robotik, saha güvenliği | Elektrik/elektronik, kontrol mühendisliği, makine güvenliği ve saha devreye alma | | İş süreci otomasyonu | CRM, ERP, sipariş, belge, e-posta, WhatsApp, onay ve raporlama | Süreç analizi, API, veri modeli, sunucu tarafı geliştirme, erişim kontrolü ve izleme | | Hibrit proje | Üretim verisinin ERP/CRM ve yönetim raporlarına bağlanması | İki alan arasında tanımlı sorumluluk ve entegrasyon mimarisi | Bir üretim makinesinin güvenli çalışması gerekiyorsa yalnız web yazılımı deneyimi yeterli değildir. Bir satış talebinin WhatsApp'tan CRM'e aktarılması gerekiyorsa da PLC markaları ve pano tecrübesi tek başına doğru yetkinlik değildir. Hibrit projede hangi ekibin saha sistemi, hangi ekibin iş yazılımı ve veri akışından sorumlu olduğunu sözleşmede ayırın. Bu rehber Niwera'nın çalışma alanıyla uyumlu olarak **iş yazılımı ve iş süreci otomasyonuna** odaklanır; endüstriyel makine güvenliği veya PLC/SCADA tedarikçisi seçme rehberi değildir. ## 1. Süreci Ekranlardan Önce Haritalayın “CRM'i ERP'ye bağlayalım” teknik bir yön gösterir ama iş sonucunu tanımlamaz. Önce başlangıç olayını, gerekli veriyi, karar noktalarını, beklenen çıktıyı ve istisnaları yazın. Örnek sipariş akışı: 1. Müşteri talebi gelir. 2. Müşteri ve ürün kaydı doğrulanır. 3. Fiyat, stok ve teslimat bilgisi yetkili kaynaktan alınır. 4. Eksik bilgi müşteriden veya ekipten istenir. 5. Sipariş taslağı insan onayına sunulur. 6. Onay sonrası kayıt oluşturulur. 7. İşlemin gerçekten oluştuğu doğrulanır. 8. Hata varsa kuyruğa ve sorumlu ekibe aktarılır. Teklif yalnız 1 ile 6 arasındaki mutlu yolu anlatıyorsa eksiktir. Mükerrer mesaj, yanlış müşteri eşleşmesi, API kesintisi, stok çelişkisi ve onay gecikmesi de kapsamda değerlendirilmelidir. ## 2. Hazır Ürün, Kodsuz Platform veya Özel Yazılım Kararını Açıklayın Her süreç için sıfırdan yazılım gerekmez. Hazır bağlayıcı veya kodsuz platform hızlı başlangıç sağlayabilir; özel sunucu tarafı yazılımı ise karmaşık iş kuralları, yüksek kontrol ihtiyacı veya mevcut sistemlerdeki sınırlamalar için gerekli olabilir. Firmadan neden seçtiği yaklaşımın uygun olduğunu şu başlıklarla açıklamasını isteyin: - Kurulum ve değişiklik hızı. - API ve veri hacmi sınırları. - Kullanıcı, iş akışı ve işlem başına lisanslar. - Sürüm değişikliklerinin etkisi. - Test ve devreye alma süreci. - Tedarikçiye bağımlılık ve dışa aktarma seçenekleri. - Kurum içi ekibin sistemi devralabilme düzeyi. “En yeni araç” bir iş gerekçesi değildir. Araç seçimi süreç, risk, ekip yetkinliği ve toplam maliyetle ilişkilendirilmelidir. ## 3. Entegrasyon Sözleşmesini Alan Alan Tanımlayın API bağlantısı kurmak, veri sorumluluğunu çözmez. CRM'deki müşteri telefonu ile ERP'deki teslimat adresi çelişirse hangi kaynak esas alınacak? Bir sipariş iptal edildiğinde diğer sistemde ne kadar sürede görünmeli? Hangi alan tek yönlü, hangisi çift yönlü güncellenmeli? [Microsoft'un data unification dokümantasyonu](https://learn.microsoft.com/en-us/dynamics365/customer-insights/data/data-unification), kaynak alanlarının seçimi, yinelenen kayıtların bulunması, eşleştirme ve birleşik görünüm adımlarını ayrı ele alır. Belirli bir CRM ürünü kullanmasanız da bu ayrım entegrasyon teklifini değerlendirmek için yararlıdır. Teklif ekinde şu tabloyu isteyin: | Alan | Ana kaynak | Akış yönü | Güncelleme sıklığı | Çelişki kuralı | Hata sahibi | | --- | --- | --- | --- | --- | --- | | Müşteri telefonu | CRM | Çift yönlü | Olay bazlı | En son doğrulanmış kayıt | Satış operasyonu | | Sipariş durumu | ERP | ERP → CRM | Olay bazlı | ERP değeri geçerli | Sipariş operasyonu | Tablodaki örnek değerler kendi sisteminiz için karar değildir. Ama teklifin hangi ayrıntı seviyesine ulaşması gerektiğini gösterir. ## 4. Hata Yönetimi ve Gözlemlenebilirlik Otomasyon yalnız çalıştığında değil, çalışmadığında da yönetilebilir olmalıdır. Firma şu durumları nasıl ele alacağını göstermelidir: - Aynı olayın iki kez gelmesi. - İstek zaman aşımına uğradığında işlemin gerçekte tamamlanmış olma ihtimali. - İstek sınırı ve geçici servis kesintisi. - Değişen API alanları veya kimlik doğrulama yöntemi. - Eksik ya da beklenmeyen veri. - İnsan onayının süresinde gelmemesi. - Yanlış işlemi geri alma veya telafi etme. Her yeniden deneme güvenli değildir. Müşteriye mesaj gönderme veya sipariş oluşturma gibi dış etkili işlemlerde işlem kimliği ve gerçek sonuç doğrulanmadan tekrar çalıştırmak mükerrer kayıt üretebilir. Hata kuyruğu, uyarı, sorumlu kişi ve manuel düzeltme ekranı teklifin parçası olmalıdır. ## 5. Güvenlik ve Yetkiyi İş Akışı Seviyesinde İnceleyin Otomasyon hesabına “yönetici” yetkisi vermek kolay ama risklidir. Her API aracı için gereken en düşük okuma/yazma izinlerini tanımlayın. Gizli anahtarların nerede tutulduğunu, erişimlerin nasıl yenilendiğini ve eski çalışan/tedarikçi hesaplarının nasıl kapatıldığını sorun. [CISA Software Acquisition Guide](https://www.cisa.gov/software-acquisition-guide/tool), tedarikçilerin güvenli geliştirme, zafiyet yönetimi, üçüncü taraf bileşenler ve olay süreçleri hakkında değerlendirilmesine yönelik ayrıntılı bir soru seti sunar. Küçük bir otomasyon projesi için tüm maddeler aynı ağırlıkta olmayabilir; veri ve işlem riskine göre uyarlanmalıdır. AI ajanı işleme karar veriyorsa ek riskler vardır. [OWASP'ın LLM uygulamaları risk listesi](https://owasp.org/www-project-top-10-for-large-language-model-applications/) hassas bilgi açıklanması ve aşırı yetkilendirme başlıklarını içerir. Model girdisini talimat olarak kabul edip yetkisiz işlem yapmamalı; araç çağrıları doğrulama ve yetki kontrolünden geçmelidir. ## 6. İnsan Onayı ve Manuel Çalışma Yolu İnsan onayı yalnız yüksek tutarlı ödeme gibi belirgin işlemlerde değil, belirsiz müşteri eşleşmesi ve sıra dışı fiyat talebi gibi durumlarda da gerekebilir. Şunları netleştirin: - Hangi işlem hangi rolden onay ister? - Onay ekranı karar için gerekli bağlamı gösteriyor mu? - Reddedilen işlem nasıl kaydediliyor? - Sistem kapalıyken ekip işi manuel sürdürebiliyor mu? - Otomasyon tekrar açıldığında manuel kayıtlarla nasıl uzlaşıyor? - Acil durumda bir acil durdurma veya yetki kapatma yolu var mı? Amaç her adımı insana onaylatmak değildir. Yanlış işlemin etkisi ile otomasyonun hız faydasını birlikte değerlendirip doğru kontrol noktasını seçmektir. ## 7. WhatsApp ve CRM Tekliflerinde Ek Sorular WhatsApp otomasyonu, mesaj ekranından daha geniştir. [WhatsApp Business Messaging Policy](https://business.whatsapp.com/policy), opt-in, iletişimi durdurma talepleri, belirli durumlarda onaylı message template kullanımı ve otomasyonda açık insan desteği yolları gibi koşullar içerir. Güncel platform fiyatı, template kategorileri ve sağlayıcı ücretleri toplam maliyete ayrıca eklenmelidir. WhatsApp teklifi için sorun: - Resmî WhatsApp Business Platform yolu mu kullanılıyor? - Meta ücretleri ile sağlayıcı ücretleri ayrı gösteriliyor mu? - Opt-in kaynağı ve zamanı nerede tutuluyor? - 24 saatlik hizmet penceresi dışında template akışı nasıl yönetiliyor? - İnsan devrinde konuşma özeti ve kontrol edilen kayıtlar aktarılıyor mu? CRM entegrasyonu için sorun: - Aynı müşteriyi eşleştirme kuralı nedir? - Olası eşleşme otomatik birleşiyor mu, incelemeye mi gidiyor? - Yanlış birleşme geri alınabiliyor mu? - İletişim izni ile müşteri profili ayrı kayıtlar olarak korunuyor mu? - Senkronizasyon hatası kullanıcıya nerede gösteriliyor? Daha ayrıntılı uygulama örnekleri için [WhatsApp otomasyonu rehberini](/blog/whatsapp-otomasyonu-siparisten-musteri-hizmetlerine/) ve [CRM entegrasyonu rehberini](/blog/crm-entegrasyonu-tek-musteri-kaydi/) inceleyebilirsiniz. ## 8. Toplam Maliyet ve Güvenilir Üst Sınır Teklifte yalnız proje kurulum bedelini değil, en az 12 aylık işletim varsayımını görün: **Toplam maliyet = analiz + kurulum + özel geliştirme + lisans + API/işlem ücretleri + barındırma + izleme + destek + iç ekip zamanı + bakım + çıkış** Kullanıma bağlı maliyetlerde ortalama tahminin yanında güvenilir bir üst sınır isteyin. Üçüncü taraf sağlayıcının fiyatı kontrol edilemiyorsa bütçe uyarısı, istek sınırı, kullanım kotası veya otomatik durdurma gibi teknik kontrolleri değerlendirin. Tahmin, harcama limiti değildir. Değişiklik talebinin nasıl fiyatlandığını da sorun. İlk kapsamda olmayan her alan eşleştirmesi veya iş akışı adımı ayrı ücretleniyorsa küçük düzeltmeler toplam maliyeti büyütebilir. ## 9. Taşınabilirlik, Dokümantasyon ve Çıkış Otomasyonun çalıştığı platform değişebilir; firma da bir gün hizmet vermeyebilir. Çıkış planı şu varlıkları kapsamalıdır: - İş akışı tanımları ve dışa aktarılabilir yapılandırma. - Kaynak kodu ve kullanım hakları. - API şemaları, olay bildirimi sözleşmeleri ve alan eşleştirmeleri. - Veri sözlüğü, gizli anahtar envanteri ve erişim devir planı. - Test senaryoları ve bilinen istisnalar. - Sistem kayıtları ve işlem geçmişinin erişilebilir formatı. - Üçüncü taraf hesaplarının kime ait olduğu. - Devir desteğinin süresi ve bedeli. Taşınabilirlik, her aracın anında değiştirilebilmesi değildir. Bağımlılıkların görünür olması ve geçiş maliyetinin karar öncesinde anlaşılmasıdır. ## Teklifte Sorulacak 15 Soru 1. Bu proje endüstriyel otomasyon mu, iş süreci otomasyonu mu, hibrit mi? 2. Tek cümlelik iş sonucu ve başlangıç ölçümü nedir? 3. Kapsama girmeyen sistemler ve işlemler hangileri? 4. Hangi sistem her veri alanının ana kaynağıdır? 5. API yoksa hangi yöntem kullanılacak ve kırılma riski nedir? 6. Mükerrer olay ve yarım kalan işlem nasıl önlenecek? 7. Hata kuyruğunu kim izleyecek, kim düzeltecek? 8. Her bağlantı için gereken en düşük yetkiler nelerdir? 9. Hangi işlemler insan onayı gerektirir? 10. Üçüncü taraf platformlar ve alt yükleniciler hangileridir? 11. Aylık maliyet hangi işlem hacmine dayanıyor? 12. Kullanım artarsa güvenilir üst sınır veya durdurma kontrolü nedir? 13. Kabul testi hangi senaryolarla ve hangi veriyle yapılacak? 14. Veri, iş akışı ve kod sözleşme sonunda nasıl teslim edilecek? 15. Canlı destek, bakım ve kritik hata yanıt süresi nedir? ## Aynı Puan Kartıyla Karşılaştırın | Ölçüt | Örnek ağırlık | | --- | ---: | | Süreç ve kapsam uyumu | %20 | | Entegrasyon mimarisi | %15 | | Hata yönetimi ve işletim | %15 | | Güvenlik ve veri sorumluluğu | %15 | | İnsan kontrolü | %10 | | Toplam maliyet | %15 | | Taşınabilirlik ve dokümantasyon | %10 | Bu ağırlıklar ölçülmüş pazar verisi değildir; teklifleri aynı çerçevede değerlendirmek için başlangıç hipotezidir. İşlem riski, sistem kritiklik seviyesi ve kurum içi yetkinliğe göre değiştirin. ## Küçük Ama Gerçek Bir Akışla Kanıt İsteyin Demo için yalnız örnek mesaj kullanmayın. Kişisel verilerden arındırılmış gerçekçi kayıtlar, bir API kesintisi, bir mükerrer olay ve bir insan onayı senaryosu ekleyin. Pilot sonunda yalnız çalışan ekranı değil; test sonucu, hata listesi, gerçekleşen maliyet, işletim sorumluluğu ve çıkış teslimlerini değerlendirin. Niwera'nın [sipariş ve tedarik](/calismalarimiz/siparis-tedarik/), [WhatsApp](/calismalarimiz/whatsapp/) ve [CRM](/calismalarimiz/crm/) örnekleri iş yazılımı otomasyonunun farklı parçalarını simülasyon olarak gösterir. Bunlar gerçek müşteri sonucu veya belirli bir verimlilik artışı iddiası değildir. ## Kaynaklar - [CISA: Software Acquisition Guide — Supplier Response Tool](https://www.cisa.gov/software-acquisition-guide/tool) - [OWASP: Top 10 for Large Language Model Applications](https://owasp.org/www-project-top-10-for-large-language-model-applications/) - [Microsoft Learn: Data Unification Overview](https://learn.microsoft.com/en-us/dynamics365/customer-insights/data/data-unification) - [WhatsApp Business Messaging Policy](https://business.whatsapp.com/policy) - [NIST: Artificial Intelligence Risk Management Framework — Generative AI Profile](https://www.nist.gov/publications/artificial-intelligence-risk-management-framework-generative-artificial-intelligence) Bu yazı iş süreci otomasyonu için genel seçim rehberidir. Endüstriyel makine güvenliği, mevzuat, hukuk veya bilgi güvenliği değerlendirmesinin yerine geçmez ve belirli bir firmayı “en iyi” ilan etmez. --- # En İyi Yapay Zekâ Firması Nasıl Seçilir? 8 Karar Ölçütü > Yapay zekâ şirketlerini ve firmalarını iş hedefi, veri güvenliği, insan onayı, toplam maliyet ve taşınabilirlik ölçütleriyle karşılaştırın. - Asıl sayfa (canonical): https://niwera.ai/blog/en-iyi-yapay-zeka-firmasi-nasil-secilir/ - Yazar: Niwera AI - Yayın tarihi: 2026-09-12 - Konu: Yapay Zekâ Stratejisi - Dil: Türkçe (tr) “En iyi yapay zekâ firması hangisi?” sorusunun herkes için geçerli tek bir cevabı yoktur. Bir çağrı merkezi otomasyonu, üretim kalite kontrolü ve şirket içi bilgi asistanı aynı veri, entegrasyon ve risk koşullarına sahip değildir. Bir işletme için doğru olan ekip, başka bir işletmenin ihtiyacına gereğinden pahalı veya teknik olarak uyumsuz kalabilir. **Kısa yanıt:** Önce çözmek istediğiniz işi ve başlangıç ölçümünü yazın. Ardından firmaları aynı kapsam üzerinden; iş uyumu, kanıt, veri güvenliği, insan kontrolü, entegrasyon, işletim, toplam maliyet ve taşınabilirlik ölçütleriyle karşılaştırın. Marka listesi veya iyi hazırlanmış bir demo bu değerlendirmenin yerini tutmaz. ## “En İyi” Yerine “Bu İş İçin Uygun” Olanı Arayın Yapay zekâ şirketleri ve yapay zekâ firmaları listelerini incelerken önce hizmet türünü karşılaştırın. Bir model veya hazır ürün geliştiren şirket ile mevcut iş araçlarınıza yapay zekâ ekleyen danışmanlık ekibi aynı ihtiyacı karşılamayabilir. Bu rehber bir popülerlik sıralaması değil, bu farklı teklifleri aynı ölçütlerle değerlendirme yoludur. Arama sonuçlarında yapay zekâ danışmanlığı, hazır ürün, özel yazılım, eğitim ve veri bilimi hizmetleri aynı sayfada buluşabilir. Teklif istemeden önce hangi tür desteğe ihtiyacınız olduğunu ayırın: | İhtiyaç | Aranacak yetkinlik | | --- | --- | | Nereden başlanacağını belirleme | Süreç analizi, kullanım senaryosu seçimi ve risk değerlendirmesi | | Hazır bir ürünü devreye alma | Ürün kurulumu, veri aktarımı, kullanıcı eğitimi ve destek | | Mevcut sistemlere AI ekleme | API entegrasyonu, sunucu tarafı geliştirme, yetkilendirme ve izleme | | Şirkete özel model veya tahmin | Veri kalitesi, model değerlendirme, modeli devreye alma ve izleme | | AI ajanı veya chatbot | Kurumsal bilgi, araç yetkileri, insan onayı ve konuşma tasarımı | İhtiyacınız birden fazla satıra giriyorsa tek tedarikçinin hepsini yaptığı varsayılmamalıdır. Hangi işi kendisinin, hangisini alt yüklenicinin veya hazır platformun yapacağını teklifte açıkça sorun. ## 1. İş Hedefi ve Başlangıç Ölçümü İlk görüşmede teknoloji adlarından önce süreç sorulmalıdır. “Müşteri hizmetlerini iyileştirmek” yerine “destek ekibinin sipariş durumunu bulmak için kullandığı süreyi ve yanlış bilgiyle kapanan kayıtları azaltmak” gibi sınırları belli bir hedef seçin. Firma mevcut akışı, istisnaları ve son kararı veren kişiyi anlamadan kesin sonuç vaat ediyorsa dikkatli olun. Başlangıç değeri ölçülmeden pilot sonrasında oluşan fark güvenilir biçimde yorumlanamaz. [İşletmelerde yapay zekâya nereden başlanır?](/blog/isletmelerde-yapay-zekaya-nereden-baslanir/) rehberi pilot kapsamını hazırlamanıza yardımcı olur. Teklifte şu dört unsur bulunmalı: 1. Başlangıç olayı ve beklenen çıktı. 2. Kapsama giren ve girmeyen işlemler. 3. Pilot öncesi ölçüm ve kabul eşiği. 4. Hata, belirsizlik veya sistem kesintisinde izlenecek yol. ## 2. Demo Değil, Doğrulama Planı Hazırlanmış birkaç örnekte iyi sonuç almak üretim koşullarını kanıtlamaz. Kendi kullanım senaryonuzu temsil eden, kişisel verilerden arındırılmış bir değerlendirme seti isteyin. Doğru yanıt kadar yanlış yanıtı, insana aktarma davranışını ve sistemin cevap vermemesi gereken durumları da test edin. [NIST'in Generative AI Profile dokümanı](https://www.nist.gov/publications/artificial-intelligence-risk-management-framework-generative-artificial-intelligence), güvenilirlik değerlendirmesini yapay zekâ ürün ve hizmetlerinin tasarım, geliştirme, kullanım ve değerlendirme yaşam döngüsü içinde ele alır. Bu çerçeve bir firma sertifikası değildir; teklif sırasında ölçüm, risk sahibi ve izleme sorularını düzenlemek için kullanılabilir. Şunları isteyin: - Test senaryolarının kim tarafından hazırlanacağı. - Yanlış cevap, eksik kaynak ve gecikme tanımları. - Model veya istem değiştiğinde testlerin tekrar çalıştırılması. - Pilot sonucu ile üretim kabulü arasındaki fark. - Kullanım başladıktan sonra kalite gerilemesinin nasıl izleneceği. ## 3. Veri Güvenliği ve Kişisel Veri Sorumlulukları “Verileriniz güvende” cümlesi tek başına yeterli değildir. Hangi verinin hangi sisteme gönderildiğini, nerede saklandığını, ne kadar tutulduğunu ve kimlerin erişebildiğini veri akışı üzerinde görün. Model sağlayıcıları, veri tabanları, log servisleri ve destek araçları dahil tüm alt işleyenleri sorun. [Kişisel Verileri Koruma Kurumunun yapay zekâ tavsiyeleri](https://www.kvkk.gov.tr/SharedFolderServer/CMSFiles/25a1162f-0e61-4a43-98d0-3e7d057ac31a.pdf), amaç sınırlılığı, ölçülülük, veri güvenliği, tasarımdan itibaren veri koruma ve paydaşların rollerinin proje başında belirlenmesi gibi başlıkları içerir. Bunların işletmenize uygulanması için faaliyetiniz ve veri akışınız ayrıca hukuki değerlendirmeye ihtiyaç duyabilir. Teklifte netleştirin: - Veri sorumlusu ve veri işleyen rolleri. - Veri saklama, silme ve yedeklerden çıkarma süreleri. - Eğitim veya ürün geliştirme amacıyla müşteri verisi kullanılıp kullanılmayacağı. - Rol bazlı erişim, kayıt tutma ve olay bildirim süreci. - Verinin işlendiği ve aktarıldığı ülkeler. - Sözleşme bittiğinde verilerin nasıl teslim ve imha edileceği. ## 4. İnsan Onayı ve Yetki Sınırları Bir sistemin metin üretebilmesi ile işletme adına işlem yapabilmesi farklı yetkilerdir. AI ajanı e-posta taslağı hazırlayabilir; ancak fiyat değiştirme, ödeme iadesi, müşteri kaydı birleştirme veya dışarı mesaj gönderme yetkisi ayrıca tanımlanmalıdır. [OWASP'ın LLM uygulamaları için risk listesi](https://owasp.org/www-project-top-10-for-large-language-model-applications/), hassas bilgi açıklanması ve aşırı yetkilendirme gibi riskleri öne çıkarır. Teklifte her araç/API için okuma, yazma, onay ve geri alma sınırlarını isteyin. İyi bir kontrol tasarımı şunları açıklar: - Hangi işlemler otomatik, hangileri insan onaylıdır? - Onayı hangi rol verir? - Belirsizlikte sistem durur mu, tahmin ederek devam mı eder? - Yanlış işlem geri alınabilir mi? - Kullanıcı sistemin AI ile çalıştığını ne zaman görür? - Yapılan işlem ve kullanılan kaynak sonradan incelenebilir mi? ## 5. Entegrasyon ve Üretim İşletimi Pilotun bir sohbet ekranında çalışması yeterli değildir. CRM, ERP, sipariş sistemi, doküman kaynağı veya kimlik altyapısıyla bağlantı gerekiyorsa veri sahipliği ve hata yönetimi birlikte tasarlanmalıdır. Firma yalnız “API var” dememeli; istek sınırı, kimlik doğrulama, yeniden deneme, mükerrer işlem, sürüm değişimi ve servis kesintisi davranışlarını açıklamalıdır. Üretim kayıtlarına kimin bakacağı, alarmı kimin karşılayacağı ve kritik hatanın hangi sürede ele alınacağı teklifte yazmalıdır. ## 6. Toplam Maliyeti Aynı Formülle Hesaplayın Kurulum bedeli çoğu AI projesinin tek maliyeti değildir. Teklifleri aynı dönem ve kullanım varsayımıyla karşılaştırın: **Toplam maliyet = keşif + geliştirme + entegrasyon + model/API kullanımı + barındırma + lisans + izleme + destek + iç ekip zamanı + değişiklik + çıkış maliyeti** Kullanıma bağlı kalemler için birim fiyatı, fiyatın hangi ölçüye göre değiştiğini ve beklenenden yüksek kullanımda uygulanacak limiti sorun. “Sınırsız” ifadesinin teknik veya sözleşmesel sınırlarını yazılı alın. Döviz, vergi ve üçüncü taraf fiyat değişikliklerinin kime ait olduğunu netleştirin. ## 7. Taşınabilirlik ve Çıkış Planı İyi bir başlangıç kadar kontrollü bir çıkış da önemlidir. Sözleşme bittiğinde yalnız ham veriyi değil, sistemin çalışması için gereken yapılandırma ve dokümantasyonu da değerlendirin. Şu teslimleri teklife ekleyin: - Verinin açık ve belgelenmiş formatta dışa aktarımı. - API şemaları, alan eşleştirmeleri ve veri sözlüğü. - İstem, iş akışı ve iş kuralı yapılandırmalarının sahipliği. - Özel yazılımın kaynak kodu, kullanım hakkı ve bağımlılık listesi. - Test senaryoları, devreye alma dokümanı ve erişim devir planı. - Sağlayıcı değişiminde geçiş desteği ve ücretlendirmesi. Her bileşenin taşınabilir olması şart değildir; önemli olan hangi parçanın taşınamadığını ve bunun ticari sonucunu satın almadan önce bilmektir. ## 8. Teslimat Ekibi ve Yönetişim Satış görüşmesindeki ekip ile işi yapacak ekibin aynı olup olmadığını sorun. Süreç analizi, yazılım, veri, güvenlik ve operasyon sorumlularını isim değil rol seviyesinde görün. Haftalık demo tek başına yönetişim değildir; karar kayıtları, risk listesi, değişiklik süreci ve kabul sahibi belirlenmelidir. Bursa'da yüz yüze çalışma veya yerinde süreç incelemesi bazı işletmeler için avantaj olabilir. Ancak konum, tek başına teknik yetkinlik veya güvenilirlik kanıtı değildir. Yerel erişimi; kapsam, güvenlik, referans doğrulaması ve işletim yeteneğiyle birlikte değerlendirin. ## Teklif Görüşmesinde Sorulacak 12 Soru 1. Bu projenin çözdüğü tek cümlelik iş problemi nedir? 2. İlk sürümde hangi işlemler açıkça kapsam dışıdır? 3. Başlangıç ölçümü ve pilot kabul eşiği nedir? 4. Başarıyı hangi test setiyle, kim doğrulayacak? 5. Hangi model, platform ve alt yükleniciler kullanılacak? 6. Veriler nerede işlenecek, ne kadar tutulacak ve eğitimde kullanılacak mı? 7. Hangi işlemler insan onayı gerektiriyor? 8. CRM/ERP/API kesintisinde sistem ne yapacak? 9. Aylık toplam maliyet hangi kullanım varsayımına dayanıyor? 10. Fiyat artışı veya sağlayıcı değişiminde seçeneklerimiz neler? 11. Sözleşme bittiğinde veri, yapılandırma ve kod nasıl teslim edilecek? 12. Üretim desteğini kim, hangi yanıt süresiyle verecek? [CISA Software Acquisition Guide](https://www.cisa.gov/software-acquisition-guide/tool), tedarikçiye güvenli geliştirme, zafiyet yönetimi, üçüncü taraf bileşenler ve olay süreçleri hakkında yapılandırılmış sorular sormak için ayrıntılı bir örnek sunar. Her maddesi küçük bir proje için zorunlu olmayabilir; risk seviyenize göre uyarlayın. ## Basit Bir Puanlama Tablosu Kullanın Teklifleri sunum kalitesine göre değil, önceden belirlenmiş ağırlıklarla değerlendirin. Örnek bir başlangıç: | Ölçüt | Ağırlık | | --- | ---: | | İş hedefi ve kapsam uyumu | %20 | | Doğrulama ve kalite planı | %15 | | Veri güvenliği ve mahremiyet | %20 | | İnsan kontrolü ve yetkilendirme | %10 | | Entegrasyon ve işletim | %15 | | Toplam maliyet | %10 | | Taşınabilirlik ve çıkış | %10 | Bu ağırlıklar ölçülmüş pazar standardı değildir. İşletmenizin riskine göre değiştirilecek bir karar şablonudur. Sağlık, finans veya çalışan verisi gibi daha hassas alanlarda güvenlik ve hukuki değerlendirme ağırlığı artabilir. ## Kararı Küçük Bir Pilotla Doğrulayın Nihai sözleşmeden önce dar kapsamlı ve süreli bir pilot uygulayın. Pilotun teslimi yalnız demo olmasın; test sonuçları, hata listesi, veri akışı, maliyet gerçekleşmesi ve üretime geçiş kararı da teslim edilsin. Beklenen sonucu vermeyen pilotun durdurma koşulu baştan yazılmalıdır. İhtiyacınız sohbet, sipariş veya CRM akışına yakınsa [Niwera'nın çalışma örneklerini](/calismalarimiz/) inceleyebilir; çözümün hangi işi, hangi kontrol noktalarıyla ilerlettiğine bakabilirsiniz. Bu sayfalar simülasyondur ve gerçek müşteri sonucu veya performans iddiası içermez. ## Kaynaklar - [NIST: Artificial Intelligence Risk Management Framework — Generative AI Profile](https://www.nist.gov/publications/artificial-intelligence-risk-management-framework-generative-artificial-intelligence) - [KVKK: Yapay Zekâ Alanında Kişisel Verilerin Korunmasına Dair Tavsiyeler](https://www.kvkk.gov.tr/SharedFolderServer/CMSFiles/25a1162f-0e61-4a43-98d0-3e7d057ac31a.pdf) - [OWASP: Top 10 for Large Language Model Applications](https://owasp.org/www-project-top-10-for-large-language-model-applications/) - [CISA: Software Acquisition Guide — Supplier Response Tool](https://www.cisa.gov/software-acquisition-guide/tool) Bu yazı genel bir seçim ve teklif değerlendirme rehberidir. Belirli bir firmayı “en iyi” ilan etmez; hukuki, mali veya bilgi güvenliği danışmanlığının yerine geçmez. --- # İşletmelerde Yapay Zekâya Nereden Başlanır? > İlk yapay zekâ projenizi seçmek için süreç, veri, risk ve maliyeti birlikte değerlendirin. Küçük bir pilotu ölçülebilir bir iş sonucuna dönüştürün. - Asıl sayfa (canonical): https://niwera.ai/blog/isletmelerde-yapay-zekaya-nereden-baslanir/ - Yazar: Niwera AI - Yayın tarihi: 2026-09-12 - Konu: Yapay Zekâ Stratejisi - Dil: Türkçe (tr) Bir yapay zekâ projesine model seçerek başlamak cazip görünebilir. Daha doğru başlangıç, ekibinizin zamanını hangi işin aldığını bulmaktır. Her gün farklı araçlardan bilgi toplayıp aynı tabloya yazıyorsanız, müşteriye yanıt vermeden önce birkaç kişiye sormanız gerekiyorsa veya bir sipariş aynı bilgilerle tekrar tekrar açılıyorsa, incelenecek bir süreç vardır. **Kısa yanıt:** Sık tekrarlanan, girdisi ve çıktısı belli, hatası kontrol edilebilir bir iş seçin. Önce mevcut durumu ölçün; sonra sınırlı bir pilot kurun. Model, bu işin gerektirdiği araçlardan yalnızca biridir. ## Önce Tek Bir İşi Tanımlayın “Şirkete yapay zekâ entegre edelim” bir yön tarifidir, proje kapsamı değildir. “Gelen toptan sipariş mesajını ürün, adet ve teslimat bilgileriyle taslağa dönüştürelim” ise üzerinde çalışılabilir bir iş tanımıdır. Bu tanımı yazarken başlangıç olayını, kullanılan bilgiyi, beklenen çıktıyı ve son kararı veren kişiyi belirtin. Bir müşterinin mesaj göndermesiyle başlayan süreç, onaylanmış siparişle bitebilir. Aradaki fiyat kontrolü, eksik bilgi sorusu ve stok doğrulaması da kapsamın parçalarıdır. Bunları atlayıp yalnızca iyi konuşan bir asistan kurmak, işin asıl yükünü ekipte bırakır. Pilot için bütün departmanı değil, tek bir akışı seçmek genellikle daha yönetilebilirdir. Sınırları belli bir işte hem faydayı hem hatayı görmek kolaylaşır. ## Yapay Zekâ Gerektiren Adımı Ayırın Her otomasyon problemi bir dil modeli gerektirmez. Sabit bir vergi hesabı, net bir fiyat kuralı veya belirli bir durum kodunun eşleştirilmesi klasik yazılımla daha tutarlı çözülebilir. Serbest yazılmış bir talebin anlaşılması, belge içinden anlam çıkarılması veya görüşmenin özetlenmesi ise yapay zekânın değerlendirilebileceği alanlardır. İyi bir sistem bu iki yaklaşımı birlikte kullanır. Model talebi yorumlar; ürünün fiyatı kayıtlı sistemden gelir. Model bir yanıt taslağı hazırlar; ödeme iadesi için iş kuralı ve gerekiyorsa insan onayı uygulanır. Böylece model, bilmediği bir ticari bilgiyi üretmek zorunda kalmaz. > Amaç bütün kararları yapay zekâya vermek değil, insanların tekrar eden iş yükünü azaltırken kontrolü korumaktır. ## Veri Hazırlığını Ertelemeyin Pilot öncesinde hangi bilginin nerede tutulduğunu çıkarın. Ürün açıklaması bir tabloda, fiyat başka bir sistemde, müşteri notu kişisel mesajlarda duruyorsa model seçimi bu dağınıklığı tek başına çözmez. Her veri grubu için bir kaynak ve sorumlu belirleyin. Güncelliğini yitirmiş belgeleri ayırın; erişim izinlerini kontrol edin. Asistanın bir bilgiyi okuyabilmesiyle o bilgiyi değiştirebilmesi aynı yetki değildir. Bu ayrım teknik tasarımda açıkça yer almalıdır. Müşteri verisi kullanılan projelerde ihtiyaç duyulmayan alanları toplamamak, saklama süresini belirlemek ve erişimi görevle sınırlamak iyi bir başlangıçtır. Kişisel veri ve iletişim izinlerine ilişkin hukuki değerlendirme ise işletmenin faaliyetlerine ve kullandığı hizmetlere göre ayrıca yapılmalıdır. ## Başarıyı Kurulumdan Önce Tarif Edin “Daha akıllı çalışıyor” değerlendirmesini tek başına ölçemezsiniz. Başlangıçta küçük bir ölçüm seti belirleyin: | Ölçüm | Ne Anlatır? | | --- | --- | | İşlem başına harcanan süre | Ekibin aynı işi tamamlamak için ayırdığı zaman | | Düzeltme gerektiren işlem oranı | Hızın kalite kaybıyla elde edilip edilmediği | | İnsana aktarılan işlem sayısı | Otomasyonun kapsamı ve sınırları | | Tamamlanan iş başına maliyet | Model, altyapı ve insan kontrolünün birlikte maliyeti | Aynı işi pilot öncesi ve pilot sırasında benzer koşullarda değerlendirin. Yalnızca modelin yanıt süresini değil, sürecin tamamını ölçün. Hızlı üretilen ama tekrar kontrol edilmesi gereken bir çıktı, beklenen faydayı sağlamayabilir. ## Pilotun Sınırlarını Baştan Koyun İlk sürümün hangi işlemleri yapamayacağını da yazın. Örneğin asistan sipariş taslağı oluşturabilir ancak fiyat değiştiremez; müşteriye bilgi verebilir ancak iade başlatamaz. Eksik stok bilgisi, çelişen talimat ve belirsiz müşteri kaydı gibi durumlar için durma veya insana aktarma yolları tanımlayın. [NIST'in AI Risk Management Framework yaklaşımı](https://www.nist.gov/itl/ai-risk-management-framework), güvenilirlik ve risk değerlendirmesini yapay zekâ sistemlerinin tasarımından kullanımına kadar ele alır. Bu gönüllü çerçeve, bir ürün sertifikası veya işletmenize özel mevzuat incelemesinin yerine geçmez; sorulması gereken soruları düzenlemek için yararlı bir kaynaktır. ## Çalışan Pilotu Nasıl Genişletirsiniz? Pilotun sonuçlarını ekipte işi gerçekten yapan kişilerle değerlendirin. Hangi önerileri düzelttiklerini, hangi bilgiyi hâlâ başka bir yerde aradıklarını ve hangi istisnaların sık tekrarlandığını sorun. Sonraki geliştirme, çoğu zaman yeni bir modelden önce daha iyi veri veya daha açık bir iş kuralıdır. Bu temel oturduğunda komşu akışları ekleyebilirsiniz. Mesajdan sipariş taslağı oluşturmakla başlayan bir proje, [WhatsApp müşteri iletişimine](/blog/whatsapp-otomasyonu-siparisten-musteri-hizmetlerine/) ve ardından [CRM kayıtlarının birleştirilmesine](/blog/crm-entegrasyonu-tek-musteri-kaydi/) bağlanabilir. Niwera'nın [çalışmalarını](/calismalarimiz/) bu gözle inceleyebilirsiniz: Hangi araç kullanılmış sorusundan önce, hangi işin nasıl tamamlandığına bakın. Pilotunuzu dışarıdan bir ekiple kuracaksanız, marka sıralamasından önce kapsamı, veri sorumluluklarını, insan onayını ve çıkış koşullarını karşılaştırın. [Yapay zekâ firması seçme rehberi](/blog/en-iyi-yapay-zeka-firmasi-nasil-secilir/) teklifleri aynı ölçütlerle değerlendirmenize yardımcı olur. Sorununuz esas olarak sistemler arasında iş akışı kurmaksa [iş süreci otomasyonu firması seçim rehberini](/blog/en-iyi-otomasyon-firmasi-secim-rehberi/) kullanın. ## Kaynaklar - [NIST: AI Risk Management Framework](https://www.nist.gov/itl/ai-risk-management-framework) Bu yazı genel bir uygulama rehberidir. Örnek iş akışları açıklama amacı taşır; belirli bir verimlilik veya maliyet sonucu vaat etmez. --- # WhatsApp Otomasyonu: Siparişten Müşteri Hizmetlerine > WhatsApp chatbot, bot ve CRM entegrasyonunu hazır yanıtlardan iş akışlarına taşıyın. Sipariş, stok, iletişim izni ve insana devir adımlarını tasarlayın. - Asıl sayfa (canonical): https://niwera.ai/blog/whatsapp-otomasyonu-siparisten-musteri-hizmetlerine/ - Yazar: Niwera AI - Yayın tarihi: 2026-09-12 - Konu: Müşteri Deneyimi - Dil: Türkçe (tr) Müşteri “Geçen siparişimden iki kutu daha istiyorum” yazdığında iş yalnızca yanıt vermek değildir. Hangi siparişten söz ettiğini bulmak, doğru ürünü seçmek, stok ve fiyatı kontrol etmek, teslimat bilgisini doğrulamak gerekir. Hazır bir mesaj, bu adımların hiçbirini tek başına tamamlamaz. **WhatsApp otomasyonu**, konuşmayı işletmenin kayıtları ve iş kurallarıyla bağlayan bir süreç olarak düşünülmelidir. Hedef, mümkün olduğunca çok mesaj göndermek değil; doğru bilgiyi kullanarak bir işi güvenli biçimde ilerletmektir. ## Hazır Yanıt ile İş Akışı Arasındaki Fark Bir **WhatsApp chatbot** veya **WhatsApp bot**, müşterinin sorusunu yanıtlayan konuşma katmanıdır. **WhatsApp CRM entegrasyonu** ise konuşmayı doğru müşteri, sipariş ve destek kaydıyla ilişkilendirir. Otomasyon bu iki katmanı iş kuralları ve gerekli insan onaylarıyla birbirine bağlar. Teklif alırken yalnız sohbet ekranını değil, hangi kayıtların okunabildiğini ve hangi işlemlerin gerçekten yapılabildiğini sorun. Hazır yanıtlar çalışma saatleri veya sık sorulan basit sorular için yararlıdır. Fakat müşteri önceki siparişini değiştiriyorsa, bir fotoğraftaki ürünü soruyorsa veya farklı bir teslimat adresi veriyorsa konuşmanın bağlamı gerekir. Yapay zekâ, müşterinin ne istediğini sınıflandırabilir ve eksik bilgileri belirleyebilir. Ancak siparişin gerçekten var olup olmadığını, fiyatı veya kargo durumunu tahmin etmemelidir. Bu bilgiler yetkili sistemlerden alınmalı; bulunamadığında açıkça belirtilmelidir. Başarılı tasarım, konuşma yeteneği ile işlem yetkisini birbirinden ayırır. İyi yazılmış bir cümle, arka planda işlemin başarıyla tamamlandığının kanıtı değildir. ## Örnek Bir Sipariş Akışı Aşağıdaki akış, uygulama mantığını açıklayan bir örnektir; belirli bir müşterinin sonucu veya performans ölçümü değildir. 1. **Talebi anlayın.** Yeni sipariş, mevcut siparişte değişiklik, ürün sorusu ve iade gibi niyetleri ayırın. 2. **Kaydı doğrulayın.** Müşteriyle ilişkili siparişi yetkili kaynaktan bulun. Yalnızca konuşmada yazılan bir sipariş numarasına güvenmeyin. 3. **Ürün ve koşulları kontrol edin.** Ürün kodu, varyant, adet, fiyat ve stok bilgisini kayıttan okuyun. 4. **Özeti sunun.** Müşterinin onaylayacağı ürün ve teslimat bilgilerini tek bir anlaşılır özet halinde gösterin. 5. **İşlemi uygulayın.** Gerekli yetki ve onay varsa kaydı oluşturun; yoksa ekibe aktarın. 6. **Sonucu doğrulayın.** İşlem kaydı gerçekten oluştuğunda müşteriye sonucu bildirin. Hata varsa başarılıymış gibi yanıt vermeyin. Aynı yaklaşım, “Kargom nerede?” sorusunda takip kaydına, ürün sorusunda güncel kataloğa, müşteri şikâyetinde ise destek sürecine bağlanır. ## Hangi Bilgiler Birbirine Bağlanmalı? Başlangıçta bütün yazılımları tek seferde entegre etmek zorunda değilsiniz. En sık kullanılan akışın gerektirdiği kaynakları seçin. Sipariş soruları için sipariş ve kargo kayıtları; kişiselleştirilmiş destek için müşteri geçmişi; ürün danışmanlığı için güncel katalog gerekebilir. Bu bağlantıların bir veri sözleşmesi olmalıdır. Örneğin “sipariş durumu” alanının hangi sistemden geleceği ve ne zaman güncelleneceği belirli olmalıdır. Kaynak erişilemiyorsa asistanın göstereceği yanıt da tasarımın parçasıdır. Müşteri kimliğini sağlıklı eşleştirmek özellikle önemlidir. Aynı numaranın farklı şubelerde kullanılması veya bir siparişin şirket hesabı üzerinden verilmesi mümkündür. Belirsiz durumlar için ek doğrulama istemek, yanlış müşterinin bilgisini paylaşmaktan daha doğrudur. [Tek müşteri kaydı yaklaşımı](/blog/crm-entegrasyonu-tek-musteri-kaydi/) bu bağlantıların temelini açıklar. ## İzin ve Mesajlaşma Kurallarını Baştan Tasarlayın Otomasyon, platformun iletişim kurallarını ortadan kaldırmaz. [WhatsApp Business Messaging Policy](https://business.whatsapp.com/policy), işletme tarafından yapılacak iletişim için telefon numarası ve uygun iletişim iznini, iletişimi durdurma taleplerine uyulmasını ve belirli durumlarda onaylı mesaj şablonlarının kullanılmasını düzenler. Politikaya göre kullanıcının son mesajından itibaren 24 saatlik müşteri hizmetleri penceresinde şablonsuz yanıt verilebilir; bu pencerenin dışında onaylı şablon gerekir. Ürün koşulları ve platform kuralları değişebileceğinden kurulum sırasında güncel politika ve teknik belgeler yeniden kontrol edilmelidir. Platform izni ile kişisel verilerin işlenmesine ilişkin hukuki değerlendirme aynı şey değildir. Hangi bilgiyi hangi amaçla tuttuğunuzu ve kimin erişebildiğini ayrıca belirleyin. Özellikle müşteri konuşmalarının tamamını gereksiz yere farklı hizmetlere aktarmaktan kaçının. ## İnsana Devir Bir Hata Değil, Tasarım Kararıdır Bazı konuşmalar insan kararı gerektirir. Belirsiz bir şikâyet, istisnai fiyat talebi, kimlik uyuşmazlığı veya müşterinin doğrudan bir temsilci istemesi bunlara örnektir. WhatsApp politikası da otomatik yanıtlarda açık ve doğrudan destek aktarım yollarının bulunmasını ister. Devir sırasında yalnızca “Bir temsilciye aktarıyorum” demek yeterli değildir. Ekibe müşterinin talebi, kontrol edilen kayıtlar, yapılan işlemler ve neden durulduğu aktarılmalıdır. Müşterinin aynı hikâyeyi yeniden anlatmasını önleyen şey, bu iyi hazırlanmış özettir. ## Başarıyı Mesaj Sayısıyla Ölçmeyin Gönderilen mesaj sayısı tek başına iyi bir müşteri deneyimi göstermez. İşin tamamlanma oranına, tekrar sorulan sorulara, yanlış veya düzeltilmiş yanıtlara ve insana devir kalitesine bakın. Otomasyonun hızını değerlendirirken müşterinin sorusunun gerçekten çözülüp çözülmediğini de izleyin. İlk sürümü dar bir kapsamda başlatın. [Yapay zekâ pilotu seçme rehberimiz](/blog/isletmelerde-yapay-zekaya-nereden-baslanir/) bu kapsamı belirlemeye yardımcı olabilir. Konuşmanın bir iş akışına nasıl bağlanabileceğini görmek için [WhatsApp çalışmamızı](/calismalarimiz/whatsapp/) inceleyebilirsiniz; sayfadaki simülasyon gerçek bir müşteri işlemi yapmaz. Bir uygulama sağlayıcısından teklif alırken yalnız chatbot demosunu değil; WhatsApp maliyetlerini, CRM/API kapsamını, hata kuyruğunu, insan devrini ve veriyi dışarı alma koşullarını sorun. Bu başlıkları [iş süreci otomasyonu firması seçim rehberinde](/blog/en-iyi-otomasyon-firmasi-secim-rehberi/) karşılaştırmalı bir kontrol listesine dönüştürdük. ## Kaynaklar - [WhatsApp Business Messaging Policy](https://business.whatsapp.com/policy) - [WhatsApp Business Terms of Service](https://www.whatsapp.com/legal/business-terms) Bu yazı genel uygulama rehberidir; işletmenize özel hukuki görüş veya platformdan verilmiş bir uygunluk onayı değildir.