Web Sitesindeki Teklif Formları CRM’ye Otomatik Nasıl Aktarılır?

Web sitesindeki teklif formlarını CRM’ye otomatik aktarmak için form gönderimini doğrudan “müşteri oluştu” diye kaydetmek yerine önce sunucuda doğrulayın, her başvuruya benzersiz bir talep kimliği verin, aynı kişi veya şirketten gelen tekrarları kontrollü biçimde eşleştirin ve yalnız doğrulanan veriyi CRM’de ilgili satış kuyruğuna gönderin. Sağlam akış; web formu → sunucu doğrulaması → spam ve tekrar kontrolü → CRM talep kaydı → ürün/bölgeye göre atama → satış görevi → teklif ve sonuç takibi şeklindedir. En kritik nokta, kullanıcıya “talebiniz alındı” mesajı gösterirken CRM aktarımı başarısız olmuşsa kaydı kaybetmemektir.

Teklif formunu CRM’ye bağlamak neyi çözer?

Form bildirimleri yalnız e-posta kutusuna düşüyorsa satış ekibi bir başvuruyu iki kez arayabilir, başka birini tamamen kaçırabilir veya hangi kampanyanın gerçek teklife dönüştüğünü göremeyebilir. CRM entegrasyonu her başvuruyu tek bir kayıt altında toplar; ürün, şirket, kaynak ve takip durumunu standartlaştırır. Böylece “kaç form geldi?” yerine “kaç nitelikli talep doğrulandı, kaç teklif çıktı ve hangileri sonuçlandı?” soruları cevaplanabilir.

B2B teklif formunda hangi alanlar gerçekten gerekli?

Formu CRM’ye bağlamadan önce formun kendisini sadeleştirin. Akhisar’da ambalaj üretimi yapan kurgusal bir işletme düşünelim: her ziyaretçiden vergi numarası, tam adres ve onlarca teknik alan istemek yerine ilk değerlendirmeyi yapmaya yetecek bilgileri toplayabilir. Ürün türü, yaklaşık ölçü veya hacim, adet, teslim bölgesi ve gerekli dosya ilk temas için yeterli olabilir; satış temsilcisi ayrıntıları görüşmede tamamlar.

Form gönderildiğinde ilk kontrol tarayıcıda değil sunucuda yapılmalı

Tarayıcıdaki required, e-posta biçimi veya JavaScript kontrolleri kullanıcı deneyimini iyileştirir; güvenlik sınırı değildir. İstek doğrudan API uç noktasına gönderilebilir. Bu nedenle sunucu, alan uzunluklarını, beklenen veri tiplerini, izin verilen seçenekleri ve dosya türü/boyut politikalarını yeniden doğrulamalıdır. OWASP, sözdizimsel doğrulama ile iş kuralı doğrulamasını ayrı düşünmeyi ve mümkün olduğunda izin verilen değer yaklaşımını kullanmayı önerir.

Bot koruması kullanıyorsanız yalnız tarayıcıda bir doğrulama rozeti göstermek yeterli değildir. Örneğin Cloudflare Turnstile, tokenın sunucu tarafında Siteverify ile doğrulanmasını zorunlu tutar; tokenlar sürelidir ve yeniden kullanım kontrolü vardır. CRM kaydını ancak formun kendi sunucu kontrolleri ve varsa anti-bot doğrulaması geçtikten sonra oluşturun.

• Alanları trim/normalize edin; şirket adı veya telefon için körlemesine tüm karakterleri silmeyin.
• Kullanıcının seçebileceği ürün tipi gibi alanlarda tanımlı değer listesini doğrulayın.
• Serbest metni komut, SQL veya HTML olarak çalıştırmayın; depolama ve gösterim katmanında bağlama uygun kaçış uygulayın.
• Dosya yükleme gerekiyorsa yalnız dosya uzantısına güvenmeyin; boyut, içerik türü, depolama konumu ve erişim yetkisini ayrı politikayla yönetin.
• Form endpointi için makul rate limit ve bot doğrulama kuralları kullanın; başarısız doğrulama ayrıntılarını kullanıcıya iç sistem bilgisi olarak göstermeyin.

Her form gönderimine neden benzersiz talep ID vermelisiniz?

Form başarıyla sunucuya ulaştığında CRM’den bağımsız bir talep kimliği üretmek hata ayıklamayı ve tekrar denemeyi kolaylaştırır. Örneğin WEB-2026-09-001842 gibi gözle okunabilir bir referans kullanıcıya gösterilebilir; sistem içinde ise UUID gibi çakışma riski düşük bir anahtar kullanılabilir. Aynı istek ağ problemi nedeniyle iki kez gönderilirse istemci veya sunucu idempotency anahtarıyla ikinci talebin yeni bir kayıt mı yoksa aynı gönderimin tekrarı mı olduğunu ayırabilir.

Aynı müşteri tekrar form gönderirse yeni kişi mi, yeni fırsat mı oluşmalı?

Tekrar kontrolünde tek bir evrensel kural yoktur. Aynı e-posta adresinin beş dakika içinde aynı ürün ve aynı metinle ikinci kez gelmesi büyük olasılıkla yeniden gönderimdir; altı ay sonra aynı şirketin farklı ürün için başvurması ise yeni satış fırsatı olabilir. CRM’de kişi/şirket kimliği ile fırsat kimliğini ayırmak bu nedenle önemlidir. “E-posta aynıysa kaydı at” yaklaşımı gerçek yeni talepleri kaybettirebilir.

Web formu alanları CRM alanlarına nasıl eşlenmeli?

Formdaki alan adlarını doğrudan CRM’nin kullanıcıya görünen etiketlerine bağlamak kırılgandır. Arada sürümlenmiş bir eşleme katmanı kullanın. Web formunda “urun_tipi” alanı CRM’de “interest_product_family” alanına gidebilir; CRM yöneticisi etiketi değiştirdiğinde entegrasyon bozulmaz. Kaynak sistem, form sürümü ve oluşturulma zamanı gibi teknik alanları da görünür veya gizli denetim alanlarında saklayın.

Talep hangi satış temsilcisine atanmalı?

Atama, çalışan isimlerini kod içine sabitlemek yerine iş kuralıyla yapılmalıdır. Örneğin ambalaj türüne göre ürün uzmanı, ülkeye göre ihracat ekibi veya mevcut müşteriyse hesap sorumlusu seçilebilir. Hiçbir kurala uymayan talep sahipsiz kalmamalı; ortak bir “inceleme kuyruğu”na düşmelidir. İzinli tatil, çalışan ayrılığı veya kapasite değişikliği gibi durumlarda kuralı kod yayını gerektirmeden değiştirebilmek operasyonu kolaylaştırır.

CRM API’si hata verirse form talebi nasıl korunur?

Entegrasyonun en kritik testi, CRM normal çalışırken değil çalışmadığında yapılır. Web sunucusu önce kendi kalıcı kaydını oluşturabilir ve durumu “CRM aktarımı bekliyor” yapabilir. İşleyici CRM’ye gönderdiğinde başarıyla dönen CRM kayıt ID’sini saklar. Zaman aşımı veya geçici sunucu hatasında aynı request_id ile tekrar dener. Doğrulama hatası gibi kalıcı sorunlarda sonsuz tekrar yerine “manuel inceleme” durumuna geçer.

Tekrar denemelerde yeni CRM kişisi veya fırsatı üretmemek için dış talep kimliğini CRM’de mümkünse benzersiz dış anahtar olarak kullanın. CRM bu özelliği sunmuyorsa entegrasyon kendi eşleme tablosunda request_id → crm_record_id ilişkisini saklamalıdır. Sistem, CRM’den zaman aşımı aldı diye ilk çağrının başarısız olduğunu varsaymamalıdır; çağrı karşı tarafta tamamlanmış olabilir.

Kurgusal Akhisar ambalaj üreticisinde formdan teklife örnek akış

Akhisar’da gıda üreticilerine özel ambalaj yapan kurgusal “Ege Paket” işletmesini düşünelim. Web formundan Manisa’daki bir zeytin ürünleri firması 20 bin adet baskılı kutu için talep gönderiyor. Bu şirket, müşteri veya rakam gerçek bir Akhisar Dijital projesi değildir; yalnız süreci somutlaştırmak için kullanılır.

• 1. Ziyaretçi şirket adı, iletişim, kutu tipi, yaklaşık adet, teslim bölgesi ve teknik PDF ile formu gönderir.
• 2. Sunucu alanları ve Turnstile gibi kullanılıyorsa anti-bot tokenını doğrular; talebe UUID ve kullanıcıya gösterilecek kısa referans verir.
• 3. Dosya güvenli depoya alınır; CRM kaydında doğrudan herkese açık dosya URL’si yerine kontrollü referans tutulur.
• 4. Şirket adı ve iletişim kanalları normalize edilir; aynı şirketin mevcut CRM hesabı varsa yeni fırsat ona bağlanır.
• 5. Ürün tipi “özel baskılı kutu” olduğu için teknik satış kuyruğuna atanır; ilk inceleme görevi açılır.
• 6. Satış temsilcisi ihtiyacı doğrular. Form göndermek otomatik olarak “nitelikli fırsat” sayılmaz.
• 7. Teklif oluşturulduğunda teklif numarası fırsata bağlanır; revizyonlar eski teklifin üzerine yazılmaz.
• 8. Kazanıldı/kaybedildi sonucu ve gerçek sipariş tutarı ayrı kaydedilir; kampanya kaynağı varsa form sayısıyla değil bu sonuçlarla karşılaştırılır.

Satış ekibine hangi bildirimler gönderilmeli?

Her yeni form için herkese e-posta atmak kısa sürede bildirim yorgunluğu oluşturabilir. CRM içinde sahip ataması ve görev, ana çalışma yüzeyi olmalıdır. Kritik veya zaman hassas taleplerde e-posta/Slack benzeri ek bildirim kullanılabilir; fakat bildirim başarısız olduğunda CRM kaydı kaybolmamalıdır. Bir talebin atamasız kalması, belirlenen sürede ilk işlem görmemesi veya tekrar denemelerin tükenmesi asıl alarm konularıdır.

Formun hangi kaynaktan geldiği nasıl korunmalı?

UTM parametreleri, yönlendiren sayfa, formun bulunduğu hizmet sayfası ve varsa reklam tıklama tanımlayıcıları ilk talep kaydında saklanabilir. Kaynak hiç gelmediyse “organik” diye tahmin etmek yerine “bilinmiyor/doğrudan” gibi açık bir durum kullanın. Daha sonra CRM’de nitelikli talep, teklif ve satış olaylarını aynı fırsata bağlayarak hangi kanalın gerçek satış sürecine katkı verdiğini ölçebilirsiniz. Bu yaklaşım, yalnızca Google Ads panelinde görülen form sayısından farklıdır.

Formdan CRM’ye veri aktarırken hangi güvenlik sınırları korunmalı?

Web formu internetten gelen güvenilmeyen girdidir; CRM ise satış ekibinin günlük kullandığı iç sistemdir. Bu iki alan arasında doğrulama ve yetki katmanı olmalıdır. API anahtarlarını tarayıcı koduna koymayın, CRM gizli anahtarlarını sunucu ortamında tutun, CRM’den yalnız entegrasyon için gereken izinleri isteyin ve loglara gereksiz kişisel veri veya yüklenen belge içeriği yazmayın. Dosya indirme bağlantıları süreli veya yetkili olmalı; herkesçe tahmin edilebilir URL’lerle teknik çizim paylaşılmamalıdır.

İlk 30 günde form → CRM otomasyonu nasıl devreye alınır?

• 1–3. gün: Mevcut formları, satış ekibinin gerçekten kullandığı CRM alanlarını ve teklif adımlarını çıkarın.
• 4–7. gün: Talep, kişi, şirket ve fırsat kavramlarını ayırın; request_id ve kaynak alanlarını belirleyin.
• 8–11. gün: Sunucu doğrulaması, anti-bot kontrolü, dosya politikası ve kalıcı giriş kaydını kurun.
• 12–15. gün: CRM alan eşlemesi, dış kimlik ve tekrar kontrolünü test verileriyle uygulayın.
• 16–19. gün: Ürün/bölge ataması, sahipsiz talep kuyruğu ve satış görevlerini ekleyin.
• 20–23. gün: CRM kesintisi, zaman aşımı, aynı formun iki kez gönderilmesi ve kısmi hataları zorlayarak test edin.
• 24–26. gün: Kaynak/UTM ve teklif sonuçlarını rapora bağlayın; form sayısı ile nitelikli talebi ayırın.
• 27–30. gün: Küçük bir trafik yüzdesi veya tek formda canlı pilot yapın; kayıp ve çift kayıt olmadığını doğruladıktan sonra diğer formlara genişletin.

Canlıya almadan önce 12 maddelik kontrol listesi