Aydınlatma metni yükleniyor…
Web sitesi–CRM entegrasyonu, form alanlarını bir API'ye göndermekten ibaret değildir. Sağlıklı bir akış; ziyaretçinin gönderimini kaybetmeden kabul eder, veriyi doğrular, mevcut kişi veya şirketle ilişkilendirir, CRM kaydını oluşturur ya da günceller, doğru satış sorumlusuna atar ve satış ekibinin sonucu görünür biçimde işlemesini sağlar.
Bu rehber, pazarlama ve satış ekiplerinin formdan satış takibine kadar entegrasyon kapsamını yazabilmesi için hazırlanmıştır. “Kumsal altı teslim kanıtı” ve kabul testi matrisi bu makale için geliştirilen özgün planlama araçlarıdır. Belirli bir CRM'i önermez; daha fazla satış veya daha yüksek dönüşüm garantisi vermez.
Form gönderimi, kişi, şirket ve satış fırsatı aynı kayıt değildir
Bir ziyaretçinin formu doldurması değiştirilemez bir başvuru olayıdır. CRM'deki kişi, aynı insanın zaman içinde güncellenen profilidir. Şirket kaydı kurumsal hesabı; lead veya fırsat ise belirli bir satış ihtimalini temsil eder. Bunların hepsini tek kayda dönüştürmek tekrarları azaltıyor gibi görünse de geçmiş taleplerin bağlamını silebilir.
Örneğin mevcut bir müşteri altı ay arayla iki farklı hizmet için form gönderebilir. E-posta adresi aynı olduğu için kişi kaydı güncellenebilir; ancak ikinci başvuru ilk başvurunun notunun üzerine yazılmamalıdır. Her gönderim ayrı kimlik, zaman, kaynak, form sürümü ve içerik özetiyle saklanmalı; ilgili kişi, şirket ve satış kaydına bağlanmalıdır.
Entegrasyondan önce kayıt modelini ve sahipliği belirleyin
İlk toplantıda “hangi CRM alanına yazacağız?” sorusundan önce hangi sistemin hangi gerçeği yönettiği kararlaştırılmalıdır:
- Form tanımı, sayfa ve kampanya kaynağı web sitesinin sorumluluğunda mı?
- Kişinin iletişim bilgileri CRM'de mi, başka bir müşteri veri sisteminde mi güncellenir?
- Şirket eşleştirmesinde alan adı, vergi/kurum kimliği veya onaylı hesap numarası mı kullanılır?
- Lead, talep, görev ve fırsat hangi koşullarda oluşturulur?
- Satış aşaması ve nitelik sonucu web sitesine geri dönecek mi?
- Rıza, iletişim tercihi ve saklama kararının ana kaydı hangi sistemdedir?
Formun teknik olarak çalışması ile CRM entegrasyonunun çalışması farklı kontrollerdir. Tarayıcı doğrulaması, sunucuya teslim, e-posta bildirimi ve test gönderimleri için web sitesi form izleme rehberini tamamlayıcı kontrol listesi olarak kullanabilirsiniz.
Kumsal altı teslim kanıtı: formdan satış takibine
Bir talebi yalnız “başarılı” veya “başarısız” olarak izlemek, kaydın nerede kaldığını göstermez. Her aşama ayrı kanıt üretmelidir.
| Aşama | Karar | Kanıt | Başarısızsa davranış |
|---|---|---|---|
| 1. Başvuru kabulü | Gönderim geçerli ve işlenebilir mi? | Kalıcı başvuru kimliği, zaman ve form sürümü | Kullanıcıya açık hata; geçersiz kaydı CRM'ye göndermeme |
| 2. Normalleştirme | Alanlar ortak veri biçimine çevrildi mi? | Kaynak alan, hedef biçim ve doğrulama sonucu | Ham kanıtı koruyup düzeltme kuyruğuna alma |
| 3. Kimlik çözümü | Yeni kişi/şirket mi, mevcut kayıt mı? | Eşleşme kuralı, adaylar ve karar | Belirsiz eşleşmeyi insan incelemesine yönlendirme |
| 4. CRM kalıcılığı | Başvuru ve ilişkili kayıt CRM'de oluştu mu? | CRM kayıt kimliği ve yazma sonucu | Tekrar kuyruğu; aynı başvurudan ikinci kayıt üretmeme |
| 5. Sorumlu atama | Doğru ekip veya kişi sahibi oldu mu? | Kural sürümü, atanan sahip ve zaman | Yedek kuyruğa atama ve uyarı |
| 6. Satış geri bildirimi | Talep işlendi ve sonucu sınıflandırıldı mı? | İlk temas, nitelik sonucu ve sonraki adım | SLA/işletim uyarısı; kaydı silmeme |
Bu modelde ziyaretçiye gösterilen “formunuz alındı” mesajı yalnız ilk kabulü doğrular. CRM kaydı, sahip ataması ve satış takibi daha sonra tamamlanabilir. Kullanıcıya gerçek dışı “satış ekibine iletildi” mesajı göstermemek için hangi aşamanın eşzamanlı, hangisinin kuyrukta gerçekleştiği bilinmelidir.
Alan eşleştirme tablosu yalnız isimlerden oluşmamalıdır
“Telefon → phone” biçimindeki iki sütunlu eşleme, üretim için yetersizdir. Her alanın veri türü, zorunluluğu, uzunluğu, izin verilen değerleri, dönüştürme kuralı, boş değer davranışı, sahibi ve hata sonucu yazılmalıdır.
| Web alanı | CRM hedefi | Dönüşüm/doğrulama | Boş veya hatalıysa |
|---|---|---|---|
| Ad soyad | Kişi adı alanları | Tek alanı körlemesine bölmek yerine özgün değeri de koru | Form kuralına göre reddet veya incelemeye al |
| Kurumsal e-posta | Kişi e-postası | Biçim kontrolü, küçük/büyük harf normalleştirmesi | İletişim kanalı yoksa açık hata |
| Telefon | Telefon | Ülke kodu, karakter temizliği, özgün değer | İsteğe bağlıysa boş; uydurma değer üretme |
| Şirket | Şirket/hesap | Metin benzerliği tek başına otomatik birleştirme değildir | Aday hesap veya yeni şirket incelemesi |
| Hizmet seçimi | Talep türü/ürün ilgisi | Web etiketi ile CRM kodu arasında sürümlü sözlük | Bilinmeyen kodu hata kuyruğuna al |
| Mesaj | Başvuru açıklaması | Uzunluk, dosya ve zararlı içerik kontrolleri | Kesmeden önce kullanıcıyı uyar veya güvenli ek kayda yaz |
| Kaynak bilgisi | Kampanya/kaynak alanları | URL, yönlendiren, kampanya ve form sürümünü ayır | “Doğrudan” diye tahmin etmek yerine bilinmiyor |
CRM seçenekleri zamanla değişirse web formundaki sabit liste geçersiz hâle gelebilir. Ortak kod sözlüğünün sahibi, sürümü ve dağıtım yöntemi belirlenmelidir. Kullanıcıya gösterilen Türkçe/İngilizce etiket ile entegrasyonda kullanılan kararlı kod birbirinden ayrılmalıdır.
Mükerrer kayıt önleme, yalnız e-posta eşitliği değildir
Aynı e-posta adresi mevcutsa kaydı güncellemek bazı akışlarda uygundur; fakat ortak satın alma adresleri birden fazla kişiyi, bir kişi de birden fazla kurumsal adresi temsil edebilir. Telefon numarası değişebilir, şirket adı farklı yazılabilir ve formlar takma e-posta kullanabilir. Bu nedenle mükerrerlik kararı kayıt türüne göre tasarlanmalıdır.
HubSpot'un güncel kişi API belgeleri, toplu “upsert” işleminde e-posta veya özel benzersiz kimlik alanının bir kaydı oluşturmak ya da güncellemek için kullanılabildiğini açıklar. Microsoft Dataverse upsert belgeleri de entegrasyon senaryolarında alternatif anahtarlarla mevcut kaydı bulup oluşturma/güncelleme kararını ele alır. Bunlar ürün davranışı örnekleridir; “hangi alanın gerçekten benzersiz olduğu” işletmenin veri modeline göre kararlaştırılmalıdır.
Pratikte üç farklı sonuç gerekir:
- Kesin eşleşme: Onaylı dış kimlik veya güvenilir benzersiz anahtarla mevcut kayda bağla.
- Olası eşleşme: Ad, şirket, e-posta ve telefon sinyalleri benziyor; otomatik birleştirme yerine inceleme kuyruğu oluştur.
- Yeni kayıt: Yeterli eşleşme yok; yeni kişi/şirket oluştur ve başvuruyu ilişkilendir.
CRM'nin mükerrerlik özelliği olsa bile entegrasyonun gönderim kimliği ayrıca korunmalıdır. Microsoft'un yinelenen veri algılama belgeleri, kuralların alan eşleşmeleri üzerinden olası tekrarları belirlediğini ve aynı anda işlenen kayıtların yine tekrar oluşturabileceğini not eder. Bu nedenle formun ağ tekrarları ile CRM'deki kişi benzerliği ayrı sorunlardır.
Aynı form gönderimi yeniden işlendiğinde ikinci talep oluşmamalıdır
Kullanıcı gönder düğmesine iki kez basabilir; tarayıcı yanıt alamadığı için isteği yineleyebilir; entegrasyon CRM yanıtını almadan kesilebilir. Her kabul edilen form olayına kalıcı bir başvuru kimliği verilmeli, sonraki bütün adımlarda bu kimlik taşınmalıdır. Aynı kimlik yeniden geldiğinde sistem önceki sonucu bulmalı; yeni bir başvuru veya fırsat oluşturmamalıdır.
Başvuru kimliği ile CRM kişi kimliği aynı değildir. Bir kişi zaman içinde birden fazla gerçek başvuru yapabilir. Kimlik çözümü kişiyi birleştirirken her talebin kendi olay kaydını korumak, hem tekrar işlemeyi hem satış geçmişini doğru yönetir.
Sorumlu ataması kural, yedek ve zaman aşımı içermelidir
Atama yalnız şehir veya hizmet alanına göre yapılmayabilir. Ülke, dil, ürün ailesi, mevcut müşteri durumu, hesap yöneticisi, şirket büyüklüğü, kanal ortağı ve çalışma saati birlikte değerlendirilebilir. Kuralların sırası önemlidir: ilk eşleşen mi kazanır, en özel kural mı, yoksa puanlama mı kullanılır?
Salesforce lead atama belgeleri, kural girişlerinin işlenme sırası, eşleşme koşulu ve atanacak kullanıcı gibi bileşenleri ayrı tanımlar. Bu yaklaşım herhangi bir CRM'de uygulanabilir: her kuralın önceliği, kapsamı, sahibi ve test örneği bulunmalıdır.
Sorumlu izinliyse, pasifse veya kapasite sınırındaysa ne olacağı ayrıca yazılmalıdır. Hiçbir kural eşleşmezse kayıt sahipsiz kalmamalı; genel satış kuyruğuna düşmeli ve belirli sürede sahiplenilmezse görünür uyarı üretmelidir. Bildirimin gönderilmesi ile CRM sahibinin atanması da iki ayrı kontroldür.
Hata kuyruğu, başarısız kaydı görünür ve düzeltilebilir tutar
CRM API'sinin geçici olarak yanıt vermemesi ile “hizmet kodu geçersiz” hatası aynı şekilde tekrar edilmemelidir. Teknik hatalar kontrollü aralıklarla yeniden denenebilir. Veri veya iş kuralı hataları ise aynı istekle sonsuza kadar yinelenmek yerine insan düzeltmesi beklemelidir.
Hata kaydı en az başvuru kimliği, aşama, hata sınıfı, güvenli hata özeti, deneme sayısı, son deneme, sonraki işlem zamanı ve sorumlu ekibi içermelidir. Düzeltme sonrası yeniden işlem aynı başvuru kimliğini kullanmalı, önceki hata geçmişini silmemelidir. Başarısız kayıtlar ayrı bir tabloya atılıp unutulmamalıdır.
Loglarda izlenebilirlik ile veri minimizasyonunu birlikte kurun
Bir talebin web sunucusu, kuyruk, entegrasyon ve CRM boyunca izlenebilmesi için ortak ilişkilendirme kimliği kullanılabilir. W3C Trace Context, dağıtık sistemlerde tekil istekleri farklı servisler boyunca ilişkilendirmek için standart HTTP bağlam alanları tanımlar. Her proje bu standardı kullanmak zorunda değildir; ancak “hangi web isteği hangi CRM yazımına dönüştü?” sorusuna cevap verecek bir iz bulunmalıdır.
İzlenebilirlik, formun bütün içeriğini loglara kopyalamak anlamına gelmez. OWASP Logging Cheat Sheet; erişim belirteçleri, parolalar, hassas kişisel veriler ve bazı ticari bilgilerin doğrudan loglanmaması; gerektiğinde maskeleme, temizleme, özetleme veya şifreleme uygulanması gerektiğini belirtir. Saklama süresi, erişim yetkisi ve hata inceleme süreci proje özelinde belirlenmelidir.
CRM'den web sitesine hangi bilgiler geri dönmeli?
İlk sürümde çift yönlü entegrasyon şart değildir. Web sitesi formu CRM'ye güvenilir biçimde aktarabilir; satış aşaması yalnız CRM içinde yönetilebilir. Geri dönüş gerçekten bir kullanıcı deneyimini veya ölçümü besliyorsa eklenmelidir.
Örneğin satış nitelik sonucu pazarlama raporuna anonim veya sınırlandırılmış biçimde dönebilir; müşteri portalında kullanıcı kendi talep durumunu görebilir. Buna karşılık iç satış notlarının, ret gerekçelerinin veya hassas hesap bilgilerinin web katmanına gereksiz aktarılması yeni risk ve sahiplik sorunları oluşturur. Hangi alanın hangi yönde, hangi tetikleyiciyle ve hangi yetkiyle hareket ettiği veri akış tablosunda yazılmalıdır.
Uçtan uca kabul testlerini iş senaryolarıyla yazın
| Senaryo | Beklenen sonuç | Kanıt |
|---|---|---|
| Yeni kişi geçerli form gönderiyor | Başvuru, kişi ve ilgili satış kaydı oluşur; sorumlu atanır | Başvuru ve CRM kimlikleri, atama zamanı |
| Mevcut kişi yeni hizmet için tekrar gönderiyor | Kişi güncellenir; yeni başvuru geçmiş talebin üzerine yazılmaz | Eşleşme kararı ve iki ayrı başvuru |
| Aynı gönderim ağ nedeniyle iki kez ulaşıyor | İkinci CRM talebi oluşmaz; önceki sonuç döner | Tek başvuru kimliği ve tekrar sonucu |
| İki olası şirket eşleşmesi bulunuyor | Otomatik yanlış birleşme yerine inceleme kuyruğu | Adaylar, güven düzeyi ve insan kararı |
| CRM kısa süreli erişilemiyor | Kayıt kaybolmaz; kontrollü tekrar sonrası aynı kimlikle yazılır | Kuyruk, denemeler ve CRM sonucu |
| Hizmet kodu CRM'de tanımsız | Sonsuz tekrar yok; veri hatası düzeltme kuyruğuna gider | Alan eşleme sürümü ve hata sahibi |
| Atama kuralı eşleşmiyor | Talep genel satış kuyruğuna düşer ve uyarı oluşur | Yedek kural ve sahiplenme zamanı |
| Log incelemesi yapılıyor | Akış ilişkilendirilebilir; hassas form içeriği açıkça görünmez | İlişkilendirme kimliği ve maskeli kayıt |
Başarıyı yalnız oluşturulan lead sayısıyla ölçmeyin
Form gönderimi sayısı pazarlama talebini gösterir; entegrasyon kalitesini tek başına göstermez. Kabul edilen başvuruların CRM'ye yazılma oranı, en eski hata kaydı, tekrar kuyruğu yaşı, olası mükerrer inceleme süresi, sahipsiz kayıt sayısı, atamaya kadar geçen süre ve satış sonucu girilmemiş kayıtlar birlikte izlenebilir.
Bu ölçüler hedef garantisi değildir. Başlangıç değeri, hesaplama tanımı, veri sahibi ve inceleme sıklığı proje öncesinde yazılmalıdır. Satış sonucu kalitesini pazarlama kaynağıyla birleştirmek istiyorsanız eksik veya geciken geri bildirim ayrı bir veri kalitesi sorunu olarak raporlanmalıdır.
Entegrasyon teklifinde hangi teslimatlar bulunmalı?
- Form, başvuru, kişi, şirket, lead/talep ve fırsat kayıt modeli
- Alan eşleştirme, kod sözlüğü ve veri sahipliği tablosu
- Kesin/olası/yeni kayıt için mükerrerlik kararları
- Başvuru kimliği, tekrar işleme ve CRM yazma davranışı
- Sorumlu atama, yedek kuyruk, izin ve kapasite kuralları
- Hata sınıfları, tekrar politikası, düzeltme ekranı ve uyarılar
- Kimlik doğrulama, yetki, log maskeleme ve saklama yaklaşımı
- Test ortamı, kabul senaryoları, canlı geçiş ve işletim sorumluları
Genel API, ERP, CRM ve ödeme entegrasyonlarının ortak teknik kapsamını karşılaştırmak için web yazılım entegrasyonları planlama rehberini inceleyebilirsiniz.
Sonuç: Formun gönderilmesi değil, satışa teslimi tamamlanmalıdır
Web sitesi–CRM entegrasyonunun başarısı formdan sonra bir CRM kaydı görülmesiyle ölçülmez. Başvurunun kimliği, alan dönüşümü, kişi/şirket eşleşmesi, kalıcı CRM sonucu, satış sahibi ve takip geri bildirimi aynı zincirde izlenebilmelidir. Her aşama ayrı kanıt ürettiğinde kayıp ve mükerrer kayıtlar nerede oluştuğu üzerinden düzeltilebilir.
İlk kapsamı altı teslim kanıtı ve gerçek iş senaryolarıyla çıkarın. Web formlarınızı, CRM veri modelinizi ve satış takip akışınızı birlikte planlamak isterseniz Kumsal Ajans web yazılım çözümlerini inceleyebilirsiniz.