# 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.
