Web Formundan CRM'e Aktarım: Alan Eşleme, Mükerrer Kayıt ve Kaybolan Talep

Web formundan CRM’e aktarımda asıl iş iki sistemi bağlamak değil, dört kuralı yazmaktır: formdaki hangi alan CRM’de nereye gider, aynı kişi ve firma neyle tanınır, talep kime düşer, talebin nereden geldiği nasıl saklanır. Elle aktarımın kendine özgü riski ise sessiz kayıptır: gelmeyen bir kaydı kimse aramaz. Bunu, form gönderimlerini CRM’deki kayıtlarla her ay sayarak yakalarsınız.

Bu sayfa, web sitesinden gelen teklif ve servis taleplerini CRM’e ya da ortak bir Excel’e elle taşıyan satış operasyonu sorumluları için.

Örnek: bir ayda 412 form gönderimi, 17’si CRM’e hiç girmedi

Firma ve bütün rakamlar kurgudur; her rakam bir betikte sınandı. Endüstriyel kompresör ve yedek parça satan bir bayinin sitesinde üç form var: teklif iste, servis talebi, yedek parça. Her gönderim satış operasyonu sorumlusuna e-posta olarak düşüyor; sorumlu CRM’de kişi, firma ve talep açıyor. Bir ayda (22 iş günü) tablo şöyle:

Geç giren 48 talebin 31’i, sorumlunun izinli olduğu 3 iş gününe denk geldi. 19 talep yanlış temsilciye atanıp sonradan devredildi, 11 talepte var olan firma için ikinci firma kartı açıldı. Ay sonunda çıkan karar şuydu: sorun sorumlunun dikkati değil, akışın tek kişiye ve tek posta kutusuna bağlı olması. 17 talep, gerçek taleplerin %4,6’sı, kimse fark etmeden kayboldu.

Form alanları CRM’de hangi alana yazılır?

Bir form gönderimi CRM’de üç ayrı kayda dönüşür: kişi, firma ve talep. Tek bir “müşteri” satırına yazılırsa aynı firmadan ikinci kişi geldiğinde ya firma ikiye bölünür ya da kişi kaybolur. Önerdiğim eşleme:

Son satır en çok atlanan satırdır ve kaybolan talebin bulunması ona bağlıdır. Serbest metin il alanı, atamayı bozan ilk yerdir: “İzmir”, “izmir/torbalı” ve “Torbalı” üç ayrı değerdir.

Mükerrer kişi ve firma hangi alanla yakalanır?

Mükerrer kişi, aynı alanın farklı yazılışlarıyla yakalanır; bu yüzden karşılaştırmadan önce alanlar tek biçime çevrilir. Örnekteki sorumlu CRM’de yalnız e-postayı harfi harfine arıyordu. 61 talep CRM’de zaten var olan kişilerden geldi; 38’i doğru bağlandı, 23’ü yeni kişi olarak açıldı:

• 9’u e-posta yazılışı: baştaki boşluk ya da büyük harf. E-posta karşılaştırmadan önce küçük harfe çevrilip boşlukları alınır.
• 10’u telefon: kişi yeni bir e-postayla geldi, telefonu aynıydı ama “0534 300 00 00” ile “+90 (534) 300-0000” farklı göründü. Telefon, uluslararası E.164 planındaki gibi ülke koduyla ve boşluksuz tek biçimde saklanır; yabancı numara kendi ülke koduyla kalır.
• 4’ü insan kararı: yeni e-posta, telefon yok, aynı firma ve aynı ad. Bunu kural değil, kişi karar verir.

İki tuzak var. Birincisi ortak posta kutusu: örnekte 6 talep info@ gibi ortak adreslerden geldi ve sorumlu bunları o adresin CRM’deki eski kişisine bağladı; oysa yazan başka insanlardı. Ortak kutu, bir kişiyi değil bir ekibi gösteren adrestir; önek listesini siz tutarsınız, liste eskirse ortak kutu kişiye bağlanır. Ortak kutuda e-postayla otomatik bağlama yapılmaz, telefon ve ada bakılır. İkincisi boş alan: telefonu boş iki kayıt “telefonları aynı” diye eşleşmemeli.

Firma tarafında vergi numarası en güvenilir anahtardır, ama formda zorunlu tutulursa B2B talepte bile form yarıda bırakılabilir. Örnekteki 11 ikinci firma kartının 7’sinde vergi no vardı; rakam dışı karakterler atılınca hepsi eşleşiyor. Kalan 4’ünde “A.Ş.” ile “Anonim Şirketi” gibi unvan farkı vardı; bunlar “olası aynı firma” diye kişiye gösterilir.

Benim kuralım: otomatik bağlama yalnız tek biçime çevrilmiş e-posta ya da telefon birebir tutunca; geri kalan her benzerlik “olası mükerrer” kuyruğuna gider. Kayıt otomatik birleştirilmez ve silinmez. Aynı veride bu kural 61 talebin 57’sini kendisi bağlıyor, 4’ünü kişiye soruyor, ortak kutudan gelen 6 talebin hiçbirini eski kişiye bağlamıyor.

Talep hangi kurala göre kime atanır?

Atama, sırası yazılmış kurallarla yapılır ve hiçbir kurala uymayan talep bir kuyrukta görünür kalır. Örnekteki bayi için önerdiğim sıra:

1. Talep var olan bir müşteriden geldiyse o firmanın temsilcisine.
2. Servis talebi servis planlamaya, yedek parça yedek parça masasına.
3. Teklif talebi, listeden seçilen ilin bağlı olduğu bölgenin temsilcisine.
4. Yurt dışından gelen talep ihracat sorumlusuna.
5. Hiçbiri tutmuyorsa (il boş, ürün grubu “diğer”) satış operasyonu kuyruğuna.

Temsilci izindeyse talep yazılı bir vekile düşer. Geç giren 48 talebin 31’i bunun örneği: kişiye bağlı akışta izin günü, gecikme günüdür. Atanan kaydın kaç gün beklediğini ve yükün dağılımını kişiye atanan kayıtlar takip ekranı sayfasında ayrıca anlattım.

Kaynak bilgisi talebi reklama nasıl bağlar?

Kaynak bilgisi, formun gönderildiği anda gizli alanlarla talebe yazılırsa reklama bağlanır; sonradan tahminle doldurulan kaynak alanı bağlamaz. Bildirim e-postası form adını, sayfayı ve kampanyayı taşımadığı için 349 aktarılan kaydın 131’inde kaynak alanı boş kaldı; kalanında yalnız elle yazılmış serbest bir not vardı, hiçbirinde kampanya bilgisi yoktu.

Saklanacak alanlar: form adı, formun gönderildiği sayfa, ziyaretçinin siteye ilk girdiği sayfa ve adresteki kampanya parametreleri. Google Analytics’in tanımladığı parametreler utm_source, utm_medium, utm_campaign, utm_term ve utm_content; Google’a göre değerler büyük/küçük harfe duyarlıdır, “Google” ile “google” iki ayrı kaynak sayılır.

Google Ads’te otomatik etiketleme açıksa reklam tıklamasında açılış adresine gclid adlı tıklama kimliği eklenir. Google’ın çevrimdışı dönüşüm yardım sayfası, bu kimliğin formdaki gizli bir alanla alınıp talep bilgileriyle birlikte satış kayıt sisteminizde saklanmasını anlatır ve kimliğin büyük/küçük harfe duyarlı olduğunu yazar. Böylece siparişe dönen talep Google Ads’e geri yüklenebilir; ama sayfa bir şart koyuyor: tıklamadan dönüşüme geçen süre veri kaynağına göre 14 ya da 90 günden kısa olmalı. Satış döngünüz daha uzunsa geç gelen siparişler bu yöntemin kapsamı dışında kalabilir; yüklemeden önce Google’ın güncel sayfasını kontrol edin. Aynı sayfa, çevrimdışı içe aktarmaya henüz başlamamış reklamverene önce potansiyel müşteriler için gelişmiş dönüşümleri öneriyor. Ziyaretçi başka sayfaya geçince parametre genellikle adres çubuğundan düşer; ilk açılışta tarayıcıda saklanıp forma taşınması gerekir. Talebin teklif ve satışa nasıl ilerlediği ve bu sonucun reklama geri dönüşü reklam talep, teklif ve satış takibi sayfasının konusu.

Spam ve test kayıtları nereye gider?

Spam ve test kayıtları silinmez, satış ekibinin listesinden ayrılır. Örnekteki 39 spam’in 31’i formdaki gizli tuzak alanını doldurmuştu; insanın görmediği bu alanı doldurmak bot işaretidir. Bunlar ayrı bir spam listesine düşer ve haftada bir göz atılır, çünkü yanlışlıkla işaretlenen gerçek talep orada bulunur. Kalan 8’i insan eliyle yazılmış hizmet satış mesajıydı; onları satış operasyonu tek tıkla “spam” diye kapatır.

Test kayıtları kendi alan adınızdan gelen ya da test diye işaretlenen gönderimlerdir. CRM’e aktarılmaz, raporlara girmez; yine de sayımda görünür.

Elle aktarımda kaybolan talep nasıl bulunur?

Kaybolan talep, form aracındaki gönderim listesi CRM’deki kayıtlarla gönderim numarası üzerinden karşılaştırılarak bulunur. Örnekte 17 talep ay sonunda bulundu: 366 gerçek gönderimin e-postası, telefonu ve saati CRM’deki talep kayıtlarıyla tek tek karşılaştırıldı; aynı kişinin birden çok talebi ve ortak adresler yüzünden her eşleşme gözle onaylandı. Form numarası CRM’e taşınsaydı iş tek formüldü.

Form aracının dışa aktarımını bir sayfaya (A sütunu gönderim no), CRM’in dışa aktarımını CRM adlı sayfaya (A sütunu gönderim no) koyun. Türkçe Excel’de B2’ye:

=EĞER(EĞERSAY(CRM!A:A;A2)=0;"CRM'de yok";"")

Örnekte bu formül 63 satırı işaretler: 17 kayıp, 39 spam ve 7 test. Spam ve testi ayıklayınca kalan liste kayıptır. Sayımı her ay aynı gün yapın; bağlantı otomatik olsa da yapın.

Bağlayıcı nerede yeter, doğrudan entegrasyon nerede başlar?

Zapier ya da Make gibi bağlayıcılar, tek formdan tek hedefe giden ve mükerreri tek alanla yakalayan akışta yeter. Zapier’in geliştirici belgesine göre bir uygulama entegrasyonu “bulunamazsa oluştur” seçeneğini sunabilir: önce arar, kayıt yoksa açar. CRM’inizin entegrasyonunda olup olmadığına bakın. Ortak kutu istisnasını, telefon biçimini ve aylık sayımı bir bağlayıcıda kurmayı denemedim.

Uygulamaya gerek olmayan durum da açık: CRM’inizin web formu sitenize konabiliyorsa ve aylık sayım kayıp talep ile mükerrer kişi için ard arda üç ay sıfıra yakın çıkıyorsa (üç ay önerimdir), olduğunuz yerde kalın. Hacim ölçüt değil: örnekte günde yaklaşık 17 talep tek kişiye yeter görünüyordu, yine de 17’si kayboldu. Doğrudan entegrasyon; firma ve kişinin ayrı tutulması, olası mükerrerin bir insan tarafından onaylanması ve kimin neyi değiştirdiğinin izi gerekiyorsa başlar.

Formdaki kişisel veri ve onay kutusu

Form, kişisel verinin toplandığı andır; bu yüzden onay ve aydınlatma kurgusu entegrasyondan önce hukukçunuzla yazılır. Burada hüküm vermiyorum, kurulumdan önce sorulacak soruları sıralıyorum:

• KVKK md. 10 aydınlatma yükümlülüğü, verinin kimlere ve hangi amaçla aktarılabileceğini de sayar. Form verisi bir bağlayıcı servisinden geçiyorsa aydınlatma metninin bunu kapsayıp kapsamadığını sorun.
• O servisin sunucusu yurt dışındaysa KVKK md. 9 gündeme gelebilir. Madde 7499 sayılı Kanun md. 34 ile değişti (RG 12.03.2024/32487, yürürlük 1.6.2024).
• Talebe yanıt vermek ile aynı kişiye kampanya e-postası göndermek ayrı işlerdir. 6563 sayılı Kanun md. 6 ticari elektronik ileti için önceden onay ister; aynı maddenin ikinci fıkrası esnaf ve tacirlere onaysız gönderime izin verir. Formu dolduran firma çalışanının bu istisnaya girip girmediğini hukukçunuza sorun.
• Önerim: onay kutusunu önceden işaretli bırakmayın; işaretlendiği zamanı ve o andaki metnin sürümünü kayıtta saklayın. Önceden işaretli kutunun geçerli sayılıp sayılmadığını hukukçunuza sorun.

Kurulacak uygulamada form kaydı nasıl akar?

Kurulacak uygulamada form gönderimi önce numaralı bir ham kayıt olarak saklanır, sonra kurallardan geçerek kişi, firma ve talebe dönüşür. Aktarım başarısız olursa gönderimin kaybolmaması için “aktarılamadı” durumunda bekletilmesi kapsamda tanımlanabilir. Tek biçime çevirme, otomatik bağlama ve olası mükerrer kuyruğu, sıralı atama kuralları, vekil, kaynak ve gclid alanları, spam ve test listeleri ve aylık sayım ekranı bu akışa alınabilir. CRM’inizin programlama arayüzü izin veriyorsa uygulamanın onun yerine geçmek yerine ona yazması kapsamda tanımlanabilir; arayüz yoksa ya da kısıtlıysa bu ilk adımda görülür.

Yapay zekâ yalnız öneri yapabilir (ürün grubu, il, olası mükerrer çiftleri); atamayı ve birleştirmeyi insan onaylar.

İhtiyaca göre kurulabilir, kapsam ilk adımda yazılı belirlenir. Sunucu (VPS) şirketiniz adına açılabilir. Veri sizindir; istediğiniz an Excel ya da CSV olarak alırsınız. Küçük ve orta ölçekli ekipte kullanıcı başına lisans ödenmez, maliyet sunucu ve bakımdır. Kaynak kod erişiminizdeki depoda çalıştırma talimatı, bağımlılık listesi ve bilinen sınırlarla durur. Genel çalışma biçimi ekibinize özel web uygulamaları sayfasında.

İlk görüşme ücretlidir. Formlarınızın alan listesini ve CRM alanlarınızı getirirseniz eşleme tablosuyla başlarız; iletişim sayfasından yazabilirsiniz.

Kaynaklar (01.11.2026’da okundu): Google Ads otomatik etiketleme ve GCLID ile çevrimdışı dönüşüm; Google Analytics kampanya parametreleri; Zapier search or create; ITU-T E.164; mevzuat.gov.tr’deki güncel metinlerden 6698 sayılı KVKK md. 9, 10, 11 ve 6563 sayılı Kanun md. 6.

Doğrulamadığım noktalar

• Eşleştirme kurallarını ve kontrol formülünün mantığını betikte sınadım; formülü Excel’de, kuralları bir CRM ya da bağlayıcıda denemedim.
• Zapier belgesi aramanın birden çok kayıt bulduğunda ne yaptığını yazmıyor; Make’teki karşılığını okumadım.
• Vergi numarasının hane sayısını birincil kaynaktan doğrulamadım; bu yüzden hane kontrolü önermiyorum, yalnız rakam dışı karakterleri atıyorum.
• Onay ve aydınlatma konularında hüküm vermiyorum.

Sıkça Sorulan Sorular

CRM yoksa hedef paylaşılan bir Excel ya da Google Sheets olabilir mi?

Olabilir; kurallar aynıdır, yalnız uygulandıkları yer değişir. Tabloda mükerrer kontrolü ve atama formülle ya da elle yapılır, kimin neyi değiştirdiği izlenemez. Kişi, firma ve talebi üç ayrı sayfada tutup gönderim numarasını taşırsanız sonradan CRM’e ya da uygulamaya geçiş kolaylaşır.

Formu dolduran kişi bilgisinin düzeltilmesini isterse ne olur?

KVKK md. 11 kişiye eksik ya da yanlış işlenen verinin düzeltilmesini isteme hakkı verir. Düzeltme kişi kaydında bir kez yapılır, bağlı talepler aynı kişiyi gösterdiği için hepsine yansır.

Bir talepte hem satış hem servis isteniyorsa tek kayıt mı açılır?

Kişi ve firma tek kayıttır, talep ikiye ayrılır: biri satış temsilcisine, biri servis planlamaya düşer ve ikisi aynı gönderim numarasını taşır. Tek talepte bırakılırsa ya iki ekip aynı kaydı bekler ya da biri hiç görmez.