Satış web uygulamasını adım adım planlayın: lead’ler, fırsatlar, pipeline aşamaları, izinler, panolar ve entegrasyonlar. Teknik olmayan ekipler için pratik rehber.
Tek bir ekran bile tasarlamadan önce, satış web uygulamanızın hangi sorunu çözeceğini netleştirin. Satış ekipleri nadiren özellik eksikliğinden başarısız olur—başarısızlık genellikle netlik eksikliğinden kaynaklanır: kim neye sahip, sırada ne var ve rakamlar güvenilir mi?
Günlük sıkıntılara bağlı kısa bir hedef cümlesiyle başlayın:
En fazla 2–3 ana problemi sayamıyorsanız, kimsenin kullanmayacağı bir CRM klonu yapma riski vardır.
Bir dakikadan kısa sürede yapılması gerekenleri listeleyin:
Tasarım kararları, bir “birincil kullanıcı” seçildiğinde daha kolaylaşır. Birçok ekip için bu temsilcidir—çünkü benimseme her şeyi sürükler.
Sadece “yayınladık” demektense gerçek davranışı yansıtacak metrikler seçin:
Her metriği, göndermeyi planladığınız belirli bir özellikle (görevler, hatırlatmalar, aşama kuralları, panolar) ilişkilendirin, böylece neyin işe yaradığını doğrulayabilirsiniz.
Benimsemeyi ve iş akışını bozan yaygın hatalar:
Net bir hedef, kullanıcılar ve ölçülebilir sonuçlarla veri modeli, pipeline aşamaları ve panolar gibi sonraki kararların temeli sağlam olur.
MVP, satış web uygulamanızın uçtan uca iş akışını kanıtlayan en küçük halidir. Bir temsilci yeni bir lead’i kapatılmış bir fırsata çeviremiyorsa, MVP çok küçük demektir. Eğer e-posta senkronizasyonu, AI önerileri ve tam raporlama setini, pipeline hiç kullanılmadan önce inşa ediyorsanız, çok büyük demektir.
Günlük yapılan işleri desteklemeyi hedefleyin:
Çoğu ekip için pratik bir MVP: lead ve fırsat kayıtları, pipeline aşamaları, temel arama/filtre ve aktivite notları.
Genellikle benimsemeyi doğrulayana kadar bekleyebilecek özellikler:
Kısa ve test edilebilir tutun:
Sisteminizi ilk günden hangi kaynakların besleyeceğini kararlaştırın: web formları, CSV içe aktarımları ve hangi CRM entegrasyonlarının (varsa) başlatma için gerekli olduğu. MVP en az bir güvenilir giriş yoluna sahip olmalı ki yeni lead’ler sadece test sırasında değil, sürekli olarak gelsin.
Ekranları inşa etmeden önce uygulamanızın hangi “şeyleri” saklayacağını ve bunların nasıl ilişkileneceğini belirleyin. Temiz bir veri modeli lead yönetimini ve fırsat pipeline’ını tutarlı kılar, satış raporlamayı kolaylaştırır ve ekip büyüdükçe kaosu önler.
Çoğu satış web uygulaması MVP’si beş temel nesneyle başlayabilir:
Aktivite, satış iş akışını izlenebilir kılan yapıştırıcıdır.
Basit, gerçekçi ilişkiler kullanın:
Pratik bir kural: Kişiler bir fırsat olmadan da var olabilir; fırsatlar ise neredeyse her zaman bir şirket ve bir birincil kişi ile ilişkilendirilmelidir.
Takımınızın gerçekten kullandığıyla başlayın:
Daha sonra alan ekleyebilirsiniz; kullanıcıların benimsediği alanları kaldırmak zordur.
Çift kayıtlar kaçınılmazdır—erken planlayın:
Bu temel, dashboard veya CRM entegrasyonları inşa etmeden çok önce verinin dağılmasını önler.
Pipeline, bir fırsatın ne anlama geldiği ve sırada ne olması gerektiği konusunda ortak kaynak olmalıdır. Aşamalar belirsizse (veya herkes farklı kullanıyorsa), tahmin ve koçluk hızla tahmine dönüşür.
Ekiplerinizin nasıl sattığını yansıtan küçük bir aşama setiyle başlayın. Tipik örnekler: Yeni, Nitelikli, Demo/Keşif, Teklif, Pazarlık, Closed Won, Closed Lost.
Her aşama için iki kısa tanım yazın:
Kriterleri gözlemlenebilir tutun; içgüdüsel tanımlara dayandırmayın. Bu, pipeline incelemelerini daha hızlı ve tutarlı hale getirir.
Satış uygulaması, temsilcileri eksiksiz ve kullanılabilir kayıtlar oluşturmaya yönlendirmeli. Kullanıcı bir fırsatı ilerletmeye çalıştığında hafif doğrulamalar ekleyin:
Bu kurallar, eksik fırsatlarla dolu “yeşil” pipeline’ları engeller.
Süreciniz ekip, ürün veya bölgeye göre farklıysa, ayrı pipeline’lar düşünün. Amaç karmaşıklık değil—doğruluk. Aşamalar veya tanımlar gerçekten farklı olmadıkça bölmeyin; bunun yerine raporlama için “Ürün Hattı” gibi alanlar kullanın.
Bir fırsat kapandığında bir sebep zorunlu tutun (isteğe bağlı olarak rakip). Zamanla bu, daha iyi raporlama, net koçluk ve gerçekçi tahminler sağlar—fazladan toplantı gerektirmeden.
Satış web uygulaması, insanların “yeni lead”ten “sonraki aksiyon”a ne kadar hızlı geçtiğine bağlı olarak yaşar veya ölür. Deneyimi günlük alışkanlıklara göre tasarlayın: bugünkü görevleri kontrol et, pipeline’a göz at, kaydı güncelle, devam et.
Ana navigasyonu sıkı ve tutarlı tutun:
Daha sonra ekleyecekseniz, üst seviye menüyü genişletmek yerine “Daha Fazla” altında gizleyin.
İnsanların saatte dokunacağı ekranlarla başlayın:
Satış ekipleri kayıtları hızlı bulup güncellemek ister:
Güç kullanıcıların hızlı hareket etmesi için klavye kısa yolları (örn. N yeni, / aramaya odaklan) ekleyin.
Kimlik doğrulama ve erişim kontrolü, uygulamanızın güvenli veya riskli hissetmesini belirler. Başlangıçta basit tutun, ama kuralları açık yapın ki kazara “herkes her şeyi görebiliyor” durumuna düşmeyin.
Çoğu ekip üç rol ile başlayabilir:
Erken dönemde daha fazla rol eklemekten kaçının; fazladan roller genellikle sürecin belirsizliğini gizler.
İzinleri iki katmanda tanımlayın:
Bu, kritik bilgilerin notlarda veya spreadsheet’lerde saklanmasına yol açan garip kaçışları önler.
Kayıtların hangi seviyede paylaşılacağını kararlaştırın:
Yaygın bir yaklaşım: lead’ler ekip paylaşılan olabilir; fırsatlar ise varsayılan olarak özel olsun ve “ekiple paylaş” seçeneği bulunsun.
Satış ekipleri sayılara güvenmek ister. Aşama değişiklikleri, tutar düzenlemeleri ve sahip atamaları gibi önemli güncellemeler için kim, neyi ve ne zaman değiştirdiğini kaydedin; yöneticilerin pipeline incelemelerinde bunu kolay görmelerini sağlayın.
Lead yönetimi, uygulamanızın ya zaman kazandırdığı ya da ek iş yükü yarattığı yerdir. Amaç basit: yeni lead’leri hızlıca sisteme almak, doğru kişiye yönlendirmek ve sırada ne olması gerektiğini belirgin kılmak.
İlk günden birkaç güvenilir kaynağı destekleyin:
Pratik kural: her lead’in en az bir sahibi, bir kaynağı ve bir durumu olmalı—aksi halde kaybolur.
Başlangıçta karmaşık yönlendirmeye gerek yok, ama tutarlılık gerekiyor. Yaygın desenler:
Atama değişikliklerinde kim değiştirdiğini ve nedenini kaydedin. Bu, takiplerin kaçırılması durumunda kafa karışıklığını önler.
Temsilcilerin gerçekte yaptıklarıyla uyumlu küçük bir durum seti kullanın:
Diskalifiye ederken kısa bir sebep zorunlu kılın; bu raporlama için faydalıdır ve fazla iş yükü getirmez.
Tek tıkla dönüşüm akışı tanımlayın:
Dönüşüm sırasında çift kayıt kontrolleri çalıştırın (aynı e-posta, domain veya şirket adı) ki müşteri geçmişi birden fazla kayıtla parçalanmasın.
Fırsat yönetimi, uygulamanızın bir veritabanı olmaktan çıkıp günlük çalışma aracına dönüştüğü yerdir. Amaç: fırsat oluşturmayı, ilerletmeyi ve “sonraki ne”yi gözardı etmeyi zorlaştıracak şekilde yapmayı kolaylaştırmaktır.
İki giriş noktasını destekleyin:
Dönüştürme sırasında kayıtların tekrarlanmasını önleyin: fırsat mevcut kişi/şirkete referans vermeli, yeni kayıtlar sessizce oluşturulmamalı.
Farklı insanlar farklı şekilde çalışır, bu yüzden her iki yöntemi de sunun:
Bir fırsat aşama değiştirdiğinde bunu otomatik kaydedin (kim, ne zaman, nereden → nereye). Bu geçmiş koçluk ve tahmin için hayati önem taşır.
Pipeline’ı dürüst tutmak için, bir fırsat yaratıldığında veya ileri taşındığında iki alan zorunlu olsun:
Temsilci bunları eklemeden aşama ilerletemezse, net bir satır içi uyarı gösterin. Yardımcı olmak için aşama başına yaygın sonraki adımları önerin.
Her fırsatın kronolojik bir zaman çizelgesi olmalı:
Bu, fırsat devirlerinde bağlam eksikliğini azaltır. Bonus: her yerden aktivite eklenebilsin ve doğru fırsata tek tıkla ilişkilendirilebilsin.
Görevler pipeline ile gerçek iş arasındaki bağdır. Onlar yoksa, uygulamada hareket eden fırsatlar takip edilmez. Özelliği basit, hızlı kullanılabilir ve lead/fırsatlarla doğrudan bağlantılı tutun.
Temsilcilerin gerçek işlerine uyan küçük bir görev setiyle başlayın: Çağrı, E-posta, Toplantı, Demo ve Takip. Her görevde son tarih/saati, sahibi ve Lead veya Fırsat bağlantısı (ve ilişkili kişi) olsun.
Bir Günlük Ajanda görünümü ekleyin ki cevap versin: “Bugün ne yapmam gerekiyor?” İçerik:
Hatırlatmalar öngörülebilir ve ayarlanabilir olmalı. Birkaç varsayılan (örn. 15 dakika önce, 1 saat önce, zamanında) sunun ve kullanıcıların görev bazında kapatmasına izin verin. Hatırlatmaları bir “gelen kutusu” tarzı bildirim listesiyle eşleştirerek toplantı sonrası kolayca toparlanma sağlayın.
Yüksek etkili bir kural: bir fırsat bir aşamaya girdiğinde bir görev oluştur. Örnek:
Otomasyon şablonlarını admin yönetimli tutun ki satış süreci tutarlı kalsın.
Gelire zarar verebilecek birkaç sinyale odaklanın:
Lead’e hızlı dönmenin önemli olduğu durumlarda SLA uygulayın: “Yeni lead’ler X saat içinde aranmalı.” Lead üzerinde bir SLA sayacı gösterin, süre yaklaşınca sahibine uyarı verin ve ihlal edilirse yöneticiyi bilgilendirin veya yeniden atama yapın. Bu en iyi pratiği ölçülebilir bir alışkanlığa dönüştürür.
Panolar ve raporlar şu soruları hızlı yanıtlamalı: “Pipeline’da ne var?”, “Bu hafta ne değişti?” ve “Hedefe ulaşacak mıyız?” İlk sürümü basit ve tutarlı tutun, derinliği kullanıcılar gerçekten kullandıkça ekleyin.
Hem yöneticiler hem de bireysel temsilciler için bir “Pipeline Genel Bakış” görünümüyle başlayın.
Bazı temel widget’lar:
Filtreleri görünür tutun: tarih aralığı, sahip, ekip, pipeline ve ürün hattı. “Benim pipeline’ım”a tek tıkla erişim sağlayın.
Karmaşık AI olmadan işe yarayan:
Ağırlıklı pipeline her fırsat tutarını aşama olasılığı ile çarpar (ör. Teklif %50, Pazarlık %75). Açıklaması kolay ve trend takibi için uygun.
Commit / best-case yöntemi temsilcilere kontrol sağlar: fırsatlar Commit, Best-case veya Pipeline olarak etiketlenir; yöneticiler bunları haftalık/aylık toplar.
Ağırlıklı tahmin yapılıyorsa, aşama olasılıklarının her pipeline için yapılandırılmasına izin verin.
Temel aktivite türlerini (çağrı, e-posta, toplantı) takip edin ve raporlayın:
Bu, yöneticilerin sadece denetlemek yerine koçluk yapmasını sağlar.
Her tablo raporunda CSV dışa aktarımı sunun (pipeline listesi, aktivite kaydı, closed-won fırsatlar). İhtiyaç varsa basit bir abonelikle zamanlanmış e-posta raporları (ör. Pazartesi pipeline özeti) ekleyin ve canlı rapora geri dönülecek bir bağlantı sağlayın.
Raporları "kaydedilmiş görünümler" olarak tasarlayın ki kullanıcılar filtreleri tekrar tekrar kurmak zorunda kalmasın.
Entegrasyonlar, satış web uygulamanızın ya zaman kazandırdığı ya da daha çok iş yarattığı yerlerdir. Ne verinin uygulamanızda oluşturulacağı vs. nereden senkronlanacağı hakkında karar verin ve her alan için bir “kaynak” belirleyin. Bu, sessiz üzerine yazmaları ve kafa karıştıran çift kayıtları önler.
Satış ekipleri posta kutusunda yaşar. E-postaları gönderilen aktiviteleri veya toplantıları otomatik veya tek tıkla kaydetmeyi hedefleyin. Tam senkronizasyon MVP için ağır geliyorsa, başlangıçta e-posta iletme ile aktivite oluşturma, takvim etkinliği içe aktarma ve “arama/toplantı kaydet” gibi basit eylemler sunun.
Lead kaynaklarınızı listeleyin: web formları, sohbet widget’ları, webinar araçları, reklam platformları, partner listeleri. Geliş anında ne olacağına karar verin:
Zenginleştirmeyi yalnızca nitelendirmeyi doğrudan iyileştiriyorsa önceliklendirin.
Bir fırsat closed-won olduğunda uygulamanız baton’u devretmeli. Gönderilecek bilgiler: yasal varlık, fatura irtibatları, ürünler, ödeme koşulları; gönderim zamanlaması (anında kapanışta veya onay sonrası) belirleyin. Devri "Sent to finance" gibi bir durum ve zaman damgası ile denetlenebilir yapın.
Veri okuma/yazma için API’ları ve gerçek zamanlı olaylar için webhooks’u tercih edin. Yine de edge-case’ler, taşıma ve kurtarma için import/export (CSV) gibi güvenli geri dönüş seçenekleri planlayın.
Ekip için bu kararları belgelemek isterseniz, internal bir sayfa ekleyin (ör. /blog/data-flow-checklist).
Teknoloji seçimi trend peşinden koşmaktan çok, ekibinizin teslim edip, destekleyip, sorunsuzca geliştirebileceği bir şeyi seçmekle ilgilidir.
Çoğu satış web uygulaması için üç net parça ile başlayın: web frontend, backend API ve veritabanı.
Bu düzen uygulamayı sürdürülebilir kılar ve entegrasyon eklemeyi daha kolay yapar.
Eğer ilk çalışan sürümü hızlandırmak isterseniz, Koder.ai gibi bir hızlandırıcı platform pratik bir kestirme olabilir: iş akışını (lead→nitelendirme→fırsat→pipeline→görevler) chat ile tarif edersiniz, ve üretime hazır bir stack (React frontend, Go backend, PostgreSQL) oluşturulmasında yardımcı olur—aynı zamanda planlama modu, kaynak kodu dışa aktarma ve anlık görüntü/geri alma gibi kolaylıklar sağlar.
Erken üzerinde anlaşın:
Satış verileri hassastır. Temelden başlayın:
Birden fazla bölge için inşa ediyorsanız, verinin nerede barındırılacağını planlayın. Bazı platformlar (Koder.ai dahil) küresel olarak AWS üzerinde çalışabilir ve farklı ülkelerde dağıtım yapabilir—bu, veri ikametgahı gereksinimleri için faydalıdır.
Testler pipeline’ın gerçek kullanımını yansıtmalı:
Dağıtıma pilot bir ekip ile başlayın, kısa bir eğitim kontrol listesi uygulayın ve haftalık geribildirim döngüsü kurun. İyileştirmeleri düzenli (ör. 1–2 haftada bir) yayınlayın ki temsilciler uygulamanın sürekli gelişeceğine güvensin.
Günlük bir soruna bağlı 1–2 cümlelik bir hedefle başlayın; örneğin pipeline görünürlüğünü artırmak, kaçırılan takipleri azaltmak veya tahminleri güvenilir kılmak.
Ardından bir birincil kullanıcı seçin (çoğunlukla satış temsilcisi olur) ve 2–3 ölçülebilir başarı metriği tanımlayın (ör. haftalık fırsat güncelleme yüzdesi, gecikmiş görevlerde azalma, toplantıdan aşama güncellemesine geçen süre).
MVP, yeni lead’den kapatılmış anlaşmaya kadar iş akışını yan çarelere ihtiyaç duymadan desteklemeli.
Pratik bir MVP genellikle şunları içerir:
E-posta senkronizasyonu, AI skorlaması, gelişmiş otomasyonlar ve karmaşık raporlayıcılar gibi ağır özellikleri benimseme doğrulanana kadar erteleyin.
Temel nesneler ve basit ilişkilerle başlayın:
Alanları küçük tutun (sahip, durum/aşama, tutar/kapanış tarihi gibi) ve yalnızca raporlama gerçekten ihtiyaç duyduğunda alan ekleyin.
Çift kayıt (duplicate) sorununu baştan planlayın:
Bu, müşteri geçmişinin parçalanmasını ve hatalı raporları önler.
Gerçeğe uygun küçük bir aşama seti tanımlayın (ör. Yeni → Nitelikli → Keşif/Demo → Teklif → Pazarlık → Kapandı Kazan/Kapandı Kaybedildi).
Her aşama için iki kısa tanım yazın:
Ayrıca ilerleme sırasında zorunlu alanlar (tutar, kapanış tarihi, sonraki adım vb.) gibi hafif doğrulamalar ekleyin, böylece pipeline temiz kalır ve tahminler güvenilir olur.
Erken aşamada üç rol yeterli olur: satış temsilcisi, yönetici ve admin.
İzinleri iki katmanda tanımlayın:
Ayrıca kritik değişiklikler için (aşama değişimi, tutar düzenlemesi, sahip atama) denetim kaydı tutun ki sayılara güvenilsin.
Güvenilir birkaç kaynaktan veri alın:
Her lead’in en az bir sahibi, kaynağı ve durumu olmalı; aksi halde kaybolur. Atama için round-robin, bölge/tabanlı veya atanmamış bir kuyruk kullanılabilir ve sahip değişiklikleri neden ile kaydedilmelidir.
Bir fırsat oluşturulduğunda veya aşama ilerletildiğinde mutlaka iki alan girilmesini zorunlu kılın:
Ayrıca aşama girildiğinde otomatik görev oluşturan basit kurallar ekleyin (ör. Demo aşaması → demo öncesi 24 saat kala görev). Bildirimleri yalnızca değer taşıyan olaylara (gecikmiş görevler, uzun süre işlem görmemiş fırsatlar vb.) odaklayın, böylece gürültü yaratılmaz.
Karmaşık analitikler olmadan işe yarayan iki hafif yaklaşım vardır:
Ağırlıklı tahmin yapacaksanız, aşama olasılıklarının pipeline bazında yapılandırılmasına izin verin. Filtreleri açık tutun (tarih aralığı, sahip, ekip) ve “duran fırsatlar” görünümü ekleyin.
Her alan için kaynak sistemi (source of truth) önceden belirleyin: sahip, şirket adı, fırsat tutarı gibi.
MVP için daha hafif seçenekleri düşünün:
Her zaman CSV içe/dışa aktarımını yedek plan olarak tutun ve kararları ekip içinde belgeleyin (örneğin data-flow-checklist gibi iç kontrol sayfası).
