Web Formundan CRM’e Nitelikli Talep Akışı

Aynı kişi farklı tarihlerde iki proje için teklif isteyebilir. Kişi kaydı ile talep kaydı aynı şey değildir. E-posta eşleşti diye yeni talebi eskisinin üzerine yazmak, satış geçmişini ve hangi talebe dönüş yapıldığını belirsizleştirir.

Örneğimizde kişi iletişim bilgisini, şirket kurumsal ilişkiyi, talep ise belirli bir ürün ihtiyacını taşır. Formun ürettiği sabit başvuru kimliği, her yeniden denemede aynı talebi bulmaya yarar. Bir kişinin ikinci başvurusu yeni bir talep kimliği alır; mevcut kişiyle ilişkilendirilebilir. Ortak e-posta adresleri kullanılıyorsa otomatik kişi birleştirme kararı ayrıca değerlendirilir.

Her alan için kaynağı, zorunluluğu, dönüşümünü ve hata davranışını yazın. Serbest metin olan ürün ihtiyacını doğrudan CRM’in sınırlı seçenek alanına göndermek aktarımı bozabilir. Geçersiz değer sessizce kaybolmak yerine inceleme kuyruğuna alınmalıdır.

Bir kullanıcı önce bir rehberden, daha sonra reklam bağlantısından gelerek form doldurabilir. İlk bilinen kaynak ve başvuru anındaki kaynak ayrı alanlarsa rapor daha anlaşılır olur. Bilinmeyen kaynağı tahmin ederek doldurmayın; bilinmiyor olarak işaretleyin.

Kampanya parametreleri kontrolsüz metindir. Alan uzunluğunu ve izin verilen yapıyı sınırlandırın; URL’nin tamamını körlemesine CRM veya analitik sistemine taşımayın. E-posta ve telefon gibi iletişim bilgilerini kampanya parametresine koymayın. Formun kabulü ile pazarlama kanalına atıf, ayrı doğrulanan iki sonuç olmalıdır.

Tarayıcıdan gelen isteği sunucu tarafında doğrulayın. API anahtarı tarayıcıya gönderilmemeli; CRM bağlantısı sunucu üzerinden kurulmalıdır. Kayıt güvenle alındığında kullanıcıya kabul mesajı gösterilebilir; ancak bu mesajın “satış temsilcisi atandı” anlamına gelip gelmediği açık olmalıdır.

CRM geçici olarak erişilemiyorsa kayıt kaybolmasın. Bekliyor, aktarıldı ve inceleme gerekli gibi aktarım durumlarını izleyin. Yeniden deneme aynı başvuru kimliğini kullanmalı; CRM kaydı oluşturduktan sonra cevabın kaybolması ikinci kayıt üretmemelidir. Başarısız denemelerin sayısı ve son hata, operasyon ekibinin takip edebileceği bir yerde görünmelidir.

Ürün grubu veya bölgeye göre atama yapılıyorsa varsayılan sorumlu da tanımlayın. Bir eşleme bulunamadığında talep sahipsiz kalmamalıdır. Atanan kullanıcı ekipten ayrıldığında açık taleplerin devri bir işletim görevidir.

Satış aşamalarını “yeni”, “incelendi”, “görüşüldü” ve “teklif hazırlandı” gibi işte gözlenebilen olaylarla tanımlayın. Her geçiş için sorumlu ve gerekli bilgi belli olsun. “Nitelikli” ifadesini yalnızca form dolduran herkese uygulamayın; ihtiyaç uygunluğu gibi işletmenizin belirleyeceği ölçütleri kayda bağlayın.

Kurgusal kişiler ve başvurularla test yapın. Aynı kişi için iki farklı ihtiyaç ile aynı başvurunun iki kez gönderilmesini ayrı senaryolar olarak değerlendirin. İşlem kayıtları gereksiz kişisel veri kopyalamadan teşhis sağlamalıdır.

Formu kısaltmak gönderim sayısını artırabilir; fakat satış ekibinin ihtiyaç duyduğu temel bilgileri kaldırmak takip yükünü büyütebilir. Alan bazlı hataları, yarım kalan başvuruları ve satış tarafından değerlendirilen talepleri ayrı gözlemleyin. Ölçüm yapılmadan bir tasarım değişikliğine satış artışı atfetmeyin.

Kapsam belgesine alan sözlüğünü, atama kurallarını, tekrar politikasını ve izleme sorumlusunu ekleyin. Böylece yeni bir CRM’e geçiş veya formun değişmesi sırasında hangi davranışın korunacağı anlaşılır olur.

API kapsam rehberi · Kurumsal sitede dönüşüm · Proje brief oluşturucu