Satış Ekipleri için Web Uygulaması Oluşturma: Lead’ler, Fırsatlar ve Pipeline’lar

Hedefi ve Uygulamanın Kimin İçin Olduğunu Tanımlayın

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?

Uygulama hangi sorunları çözmeli?

Günlük sıkıntılara bağlı kısa bir hedef cümlesiyle başlayın:

• Görünürlük: Birisi “Şu anda pipeline’da ne var?” sorusuna spreadsheet veya Slack aramadan cevap verebiliyor mu?
• Takipler: Lead’ler ve fırsatlar güvenle ilerliyor mu yoksa görevler oluşturulmadığı için mi takılıyor?
• Tahmin: Yöneticiler tahmine güveniyor mu yoksa eski güncellemeler ve tutarsız aşamalar mı etkiliyor?

En fazla 2–3 ana problemi sayamıyorsanız, kimsenin kullanmayacağı bir CRM klonu yapma riski vardır.

Kimler kullanacak (ve her rolün ihtiyacı ne)

Bir dakikadan kısa sürede yapılması gerekenleri listeleyin:

• Satış temsilcileri: lead’i hızlı kaydetmek, nitelendirmek, aktiviteleri kaydetmek, fırsat aşamasını/güncel adımı güncellemek ve takipleri kaçırmamak.
• Yöneticiler: pipeline sağlığını incelemek, takılı fırsatları tespit etmek, bağlamla koçluk yapmak ve manuel temizlik olmadan tahmin yapmak.
• Adminler: rol tabanlı erişimi, zorunlu alanları, pipeline aşamalarını ve veri kalitesi kurallarını yönetmek.
• Sales ops: lead yönetimi tutarlılığını sağlamak, yönlendirme/atanmalar, raporlama tanımları ve CRM entegrasyonları.

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.

Ölçülebilir başarı metrikleri tanımlayın

Sadece “yayınladık” demektense gerçek davranışı yansıtacak metrikler seçin:

• Benimseme: aktif temsilcilerin haftalık fırsat güncelleme yüzdesi; sistemde kayıtlı lead yüzdesi.
• Azalan kaçırılan takipler: zaman aşımına uğrayan görevlerde veya X gün içinde dokunulmamış lead’lerde azalma.
• Daha hızlı güncellemeler: toplantı/aradan sonra aşama güncellemesine geçen süre; “hafta sonu” toplu düzenlemelerin azalması.

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.

Erken dönemde ne yapmamalısınız

Benimsemeyi ve iş akışını bozan yaygın hatalar:

• Çok fazla alan: her zorunlu alan bırakma oranını artırır; başta asgari tutun ve yalnızca raporlama gerçekten gerektiğinde ekleyin.
• Belirsiz pipeline aşamaları: iki temsilci aynı aşamayı farklı yorumluyorsa raporlama ve tahmin gürültülü olur.
• Araçların çoğaltılması: temsilcilerin hem uygulamayı hem de başka bir takipçi güncellemesi gerekiyorsa uygulama değerini kaybeder. Kaynak doğruluğunu belirleyin ve diğerlerini entegre edin.

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 Kapsamını Belirleyin: Olmazsa Olmazlar vs. İyi Olur Ama Bekleyebilir

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.

Temel kullanım durumlarıyla başlayın

Günlük yapılan işleri desteklemeyi hedefleyin:

• Lead ekle (manuel giriş + temel doğrulama)
• Lead nitelendir (durum + notlar + kaynak)
• Nitelikli lead’ten fırsat oluştur (tutar, beklenen kapanış tarihi)
• Fırsatları aşamalarda ilerlet (basit geçmiş ile)
• Fırsatı kazan/kaybet olarak kapat (sebep zorunlu)

MVP çizgisini net çizin

Ç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:

• E-posta/takvim senkronizasyonu
• AI skorlama veya sonraki adım önerileri
• Gelişmiş otomasyonlar ve sekanslar
• Özelleştirilebilir rapor oluşturucular ve kapsamlı tahminler
• Çoklu para birimi, bölge yönetimi, komisyonlar

Kullanıcı hikayelerini sade dille yazın

Kısa ve test edilebilir tutun:

• “Bir satış temsilcisi olarak, lead’i kendime atayabilirim ki takip bana ait olduğunu bileyim.”
• “Bir yönetici olarak, fırsatları aşamaya göre görebilirim ki darboğazları tespit edeyim.”
• “Bir admin olarak, CSV’den lead içe aktarabilirim ki hızlı başlayabilelim.”

Veri kaynakları konusunda erken anlaşın

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.

Veri Modelini Tasarlayın (Lead'ler, Fırsatlar, Kişiler, Aktiviteler)

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.

Gerekli ana nesneler

Çoğu satış web uygulaması MVP’si beş temel nesneyle başlayabilir:

• Lead: henüz nitelendirilmemiş kişi veya şirket adayı.
• Hesap/Şirket: satış yaptığınız organizasyon.
• Kişi/Contact: birey (genellikle bir şirkete bağlı).
• Fırsat/Opportunity: pipeline aşamalarında gelir takibi yapılan satış çabası.
• Aktivite: çağrı, e-posta, toplantı, not gibi kaydedilmiş aksiyon.

Aktivite, satış iş akışını izlenebilir kılan yapıştırıcıdır.

CRM’i düzenli tutacak ilişkiler

Basit, gerçekçi ilişkiler kullanın:

• Bir şirket → birçok kişi (Acme’de birden fazla ilgili kişi olabilir).
• Bir şirket → birçok fırsat (yenileme ve upsell ayrı fırsatlar olabilir).
• Bir fırsat → birçok aktivite (tüm çağrılar/toplantılar bir yerde olur).
• Lead dönüşümü: bir Lead, Kişi (ve genellikle bir Hesap/Şirket) haline gelebilir ve bir Fırsat yaratabilir.

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.

Minimum alanlar (başta kısa tutun)

Takımınızın gerçekten kullandığıyla başlayın:

• Lead: isim, e-posta/telefon, şirket adı (serbest metin), kaynak, durum, sahibi, oluşturma tarihi.
• Şirket: isim, domain (isteğe bağlı), sektör (isteğe bağlı), sahibi.
• Kişi: ad/soyad, e-posta, telefon, şirket (bağlantı).
• Fırsat: isim, şirket (bağlantı), tutar, beklenen kapanış tarihi, aşama, sahibi.
• Aktivite: tür, tarih/saat, notlar, ilgili kayıt (lead/kiş i/fırsat).

Daha sonra alan ekleyebilirsiniz; kullanıcıların benimsediği alanları kaldırmak zordur.

Çift kayıtlar ve birleştirme kuralları

Çift kayıtlar kaçınılmazdır—erken planlayın:

• E-posta ile eşleştirme (kişiler/lead’ler) ve domain/isim ile şirket eşleştirmesi.
• İçe aktarma sırasında “olası çiftler” olarak işaretleyin, kaydı engellemeyin.
• Birleştirme kazananı kuralı belirleyin (ör. en yeni aktivite + dolu alanlar kazansın) ve her zaman bir audit trail saklayın.

Bu temel, dashboard veya CRM entegrasyonları inşa etmeden çok önce verinin dağılmasını önler.

Pipeline Aşamalarını ve Satış Süreci Kurallarını Haritalayın

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.

Giriş/çıkış kriterleriyle standart aşamalar tanımlayın

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:

• Giriş kriteri: bir fırsatın bu aşamaya girebilmesi için ne olmalı (ör. “karar verici belirlendi”).
• Çıkış kriteri: ilerlemek için hangi kanıt gerekli (ör. “demo tamamlandı ve bir sonraki toplantı planlandı”).

Kriterleri gözlemlenebilir tutun; içgüdüsel tanımlara dayandırmayın. Bu, pipeline incelemelerini daha hızlı ve tutarlı hale getirir.

Veri kalitesini koruyacak aşama kuralları ekleyin

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:

• İlerlemeden önce zorunlu alanlar (ör. tutar, kapanış tarihi, sonraki adım)
• Zorunlu sonraki adım tarihi ile fırsatların takipsiz kalmasını önleme
• Geriye hareketler için korumalar (izin ver, ama not iste)

Bu kurallar, eksik fırsatlarla dolu “yeşil” pipeline’ları engeller.

Birden çok pipeline desteği (isteğe bağlı)

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.

Kapandı-kazan ve kapandı-kaybet nedenlerini yakalayı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.

Kullanıcı Deneyimini ve Temel Ekranları Planlayın

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.

Navigasyon temel öğeleri

Ana navigasyonu sıkı ve tutarlı tutun:

• Leads: yakalama, nitelendirme, dönüşüm
• Fırsatlar: aktif fırsatlar ve sonraki adımlar
• Pipeline: görsel aşama hareketi ve toplamlar
• Görevler: kişisel ve ekip takipleri
• Raporlar: performans ve tahmin
• Ayarlar: kullanıcılar, roller, alanlar, entegrasyonlar

Daha sonra ekleyecekseniz, üst seviye menüyü genişletmek yerine “Daha Fazla” altında gizleyin.

Önce tasarlanacak temel ekranlar

İnsanların saatte dokunacağı ekranlarla başlayın:

• Liste görünümleri (Leads, Fırsatlar, Kişiler): sıralanabilir sütunlar, net durum rozeti ve belirgin “Ekle” düğmesi.
• Detay sayfaları: özet başlığı (sahip, aşama/durum, tutar) ve ardından notlar, aktiviteler, e-postalar, dosyalar bölümleri.
• Pipeline panosu: kartları aşamalar arasında sürükle-bırak, hızlı önizlemeler ve sütun başına toplamlar.
• Hızlı ekle: mevcut ekrandan çıkmadan lead, fırsat veya görev oluşturmak için hafif bir modal veya başlık düğmesi.

İş yükünü azaltan hız özellikleri

Satış ekipleri kayıtları hızlı bulup güncellemek ister:

• Hızlı arama (isim, şirket, e-posta, fırsat) ve otomatik tamamlama.
• Filtreler + kaydedilmiş görünümler (ör. “Benim sıcak lead’lerim”, “Bu ay kapanacak fırsatlar”).
• Atama, aşama/durum değişiklikleri ve dışa aktarma için toplu işlemler.
• Listelerde ve kartlarda satır içi düzenleme (sahip, aşama, sonraki adım, kapanış tarihi).

Güç kullanıcıların hızlı hareket etmesi için klavye kısa yolları (örn. N yeni, / aramaya odaklan) ekleyin.

Kimlik Doğrulama, Roller ve Veri Erişimini Kurun

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.

Küçük bir rol setiyle başlayın

Çoğu ekip üç rol ile başlayabilir:

• Satış temsilcisi: kendi lead ve fırsatları üzerinde çalışır.
• Yönetici: ekibin çalışmalarını görür, performansı inceler, engelleri kaldırır.
• Admin: ayarları, kullanıcı teminini ve veri yönetişimini yönetir.

Erken dönemde daha fazla rol eklemekten kaçının; fazladan roller genellikle sürecin belirsizliğini gizler.

Nesne ve alan bazlı izinler

İzinleri iki katmanda tanımlayın:

1. Nesne düzeyi izinler (Leads, Deals, Contacts, Activities): görüntüle / düzenle / sil / dışa aktar.
2. Alan düzeyi izinler hassas veriler için (ör. tutar, marj, indirim, müşteri telefonu): kim görüntüleyebilir veya düzenleyebilir.

Bu, kritik bilgilerin notlarda veya spreadsheet’lerde saklanmasına yol açan garip kaçışları önler.

Gerçek satışa uygun görünürlük kuralları

Kayıtların hangi seviyede paylaşılacağını kararlaştırın:

• Özel (sadece sahibi ve adminler)
• Ekip paylaşılan (sahip + yönetici + ekip)
• Şirket genelinde (genellikle yöneticiler/adminler ile sınırlı)

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.

Kritik değişiklikler için denetim geçmişi

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 Yakalama, Atama ve Nitelendirme Oluşturun

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.

Lead yakalama: veri minimal sürtünmeyle alın

İlk günden birkaç güvenilir kaynağı destekleyin:

• Web formları: kısa tutun (isim, e-posta/telefon, şirket, kaynak). Kampanya parametreleri için gizli alanlar kullanın ki pazarlama atamaları satış temsilcilerine bağlı kalmasın.
• Manuel giriş: bir satış temsilcisi lead’i bir dakikadan kısa sürede ekleyebilmeli. Yaygın alanlarda otomatik tamamlama kullanın ve varsayılanları hatırlayın.
• CSV içe aktarma: içe aktarımlar esnek olsun. Önizleme gösterin, kullanıcıların sütunları eşlemesine izin verin ve oluşturma öncesi çift kayıt uyarısı verin.

Pratik kural: her lead’in en az bir sahibi, bir kaynağı ve bir durumu olmalı—aksi halde kaybolur.

Atama kuralları: sonraki aksiyonun sahibi kim olmalı

Başlangıçta karmaşık yönlendirmeye gerek yok, ama tutarlılık gerekiyor. Yaygın desenler:

• Round-robin adalet ve hız için.
• Bölge/territory temelli atama (ülke/bölge, sektör veya şirket büyüklüğü kullanarak).
• Manuel kuyruk: yeni lead’ler “Atanmamış” gelen kutusunda bekler ve yönetici atar.

Atama değişikliklerinde kim değiştirdiğini ve nedenini kaydedin. Bu, takiplerin kaçırılması durumunda kafa karışıklığını önler.

Nitelendirme iş akışı: durumları eyleme geçirilebilir kılın

Temsilcilerin gerçekte yaptıklarıyla uyumlu küçük bir durum seti kullanın:

• Yeni: alındı, henüz temas yok.
• İletişime geçildi: ilk temas denendi veya tamamlandı.
• Nitelikli: kriterlerinizi karşılıyor (bütçe/ihtiyaç/zamanlama vb.).
• Diskalifiye: uygun değil, ulaşılamıyor veya çift kayıt.

Diskalifiye ederken kısa bir sebep zorunlu kılın; bu raporlama için faydalıdır ve fazla iş yükü getirmez.

Dönüştürme: lead’i gerçek satış kayıtlarına çevirme

Tek tıkla dönüşüm akışı tanımlayın:

• Lead → Kişi + Şirket (Account); yoksa ikisini oluştur.
• İsteğe bağlı olarak hemen bir Fırsat oluştur (ilk aşama ve değer ile) veya temsilcinin seçmesine izin verin.

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 ve Pipeline Hareketini Oluşturun

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.

Fırsat oluşturma: sıfırdan veya nitelikli lead’ten

İki giriş noktasını destekleyin:

• Sıfırdan fırsat oluşturma inbound referans veya partner lead üzerinde çalışırken.
• Nitelikli lead’ten bir tıkla fırsat oluşturma; iletişim/şirket, kaynak ve ana notları devret.

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ı.

Pipeline hareketi: pano ve açılır menü

Farklı insanlar farklı şekilde çalışır, bu yüzden her iki yöntemi de sunun:

• Sürükle-bırak pipeline panosu (Kanban tarzı) hızlı güncellemeler için.
• Aşama açılır listesi fırsat sayfasında hassas güncellemeler için (erişilebilirlik ve mobil için uygun).

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.

Duran fırsatları önlemek için zorunlu sonraki adımlar

Pipeline’ı dürüst tutmak için, bir fırsat yaratıldığında veya ileri taşındığında iki alan zorunlu olsun:

• Sonraki adım (kısa metin)
• Takip tarihi

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ırsata bağlı aktivite zaman çizelgesi

Her fırsatın kronolojik bir zaman çizelgesi olmalı:

• Çağrılar, e-postalar, toplantılar
• Notlar ve dosya bağlantıları
• Aşama değişiklikleri ve önemli alan düzenlemeleri

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, Hatırlatmalar ve Basit Otomasyon Ekleme

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.

Görev türleri, son tarihler ve günlük ajanda

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:

• Bugünün görevleri (saat sırasına göre)
• Gecikmiş görevler (üstte sabitlenmiş)
• Yaklaşan görevler (önümüzdeki 7 gün)

İhmal edilmeyen hatırlatmalar

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.

Basit otomasyon: aşama değişiminden görev tetikleme

Yüksek etkili bir kural: bir fırsat bir aşamaya girdiğinde bir görev oluştur. Örnek:

• Aşama → “Demo Planlandı” → “Gündem gönder ve katılımcıları onayla” görevini demo öncesi 24 saat olarak oluştur.

Otomasyon şablonlarını admin yönetimli tutun ki satış süreci tutarlı kalsın.

Yardımcı ama gürültü yaratmayan bildirimler

Gelire zarar verebilecek birkaç sinyale odaklanın:

• Gecikmiş görevler
• X gündür işlem görmemiş fırsatlar
• Yüksek değere sahip kapanış tarihi yaklaşan ve sonraki adımı olmayan fırsatlar

Yeni leadler için SLA kuralları

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, Raporlar ve Tahmin Tasarımı

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.

Satış panosu temel öğeleri

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:

• Pipeline değeri: açık aşamalardaki toplam fırsat tutarı (isteğe bağlı olarak sahip veya bölgeye göre ayrılabilir).
• Aşama sayıları ve değerleri: her aşamada kaç fırsat ve toplam tutar.
• Kazanma oranı: seçili dönem için basit oran (won / closed).
• Yeni vs. ilerlemiş vs. duran: X gün içinde oluşturulan, ilerleyen veya değişmeyen fırsatlar.

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.

Tahmin: iki pratik seçenek

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.

Davranışı yönlendiren aktivite raporlama

Temel aktivite türlerini (çağrı, e-posta, toplantı) takip edin ve raporlayın:

• Temsilci başına: aktivite sayısı ve son aktivite tarihi.
• Dönemsel: günlük/haftalık toplamlar.
• Aktivite→sonuç: isteğe bağlı ama güçlü—kazanılan vs. kaybedilen fırsatlar için aktivite seviyelerini karşılaştırın.

Bu, yöneticilerin sadece denetlemek yerine koçluk yapmasını sağlar.

Dışa aktarımlar ve zamanlı raporlar

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ı ve Veri Akışını Planlayı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.

E-posta ve takvim: çift iş girmeden aktivite yakalama

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ı ve zenginleştirme (veri kalitesi kontrolleriyle)

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:

• Lead otomatik oluşturulsun ve kaynak/kampanya ile etiketlensin
• İsteğe bağlı zenginleştirme çalıştırılsın (şirket bilgileri, sosyal profiller)
• Veri kalitesi doğrulamaları (geçerli e-posta, normalize telefon, e-posta/domain ile dedupe)

Zenginleştirmeyi yalnızca nitelendirmeyi doğrudan iyileştiriyorsa önceliklendirin.

Kapandı-kazan sonrası muhasebe veya sözleşme araçlarına devretme

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.

Entegrasyon yaklaşımı: API, webhooks ve geri dönüş seçenekleri

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 Yaklaşımını Seçin, Sonra Test Edin ve Dağıtın

Teknoloji seçimi trend peşinden koşmaktan çok, ekibinizin teslim edip, destekleyip, sorunsuzca geliştirebileceği bir şeyi seçmekle ilgilidir.

Basit, kanıtlanmış bir mimari

Çoğu satış web uygulaması için üç net parça ile başlayın: web frontend, backend API ve veritabanı.

• Web frontend: temsilcilerin yaşadığı yer—pipeline, fırsat sayfaları, görevler, panolar.
• Backend API: iş kuralları (aşama değişiklikleri, atama mantığı, izinler) tek yerde.
• Veritabanı: lead, kişi, fırsat, aktivite ve denetim geçmişi için yapılandırılmış kayıtlar.

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.

Atlanmaması gereken fonksiyonel olmayan ihtiyaçlar

Erken üzerinde anlaşın:

• Performans: pipeline ve fırsat ekranları için kabul edilebilir yüklenme süreleri.
• Çalışırlık beklentileri: küçük bir ekip bile kesintiler ve bakım pencereleri için bir plan istemeli.
• Yedekler ve kurtarma: otomatik günlük yedekler, test edilmiş geri yüklemeler ve saklama kuralları.

Güvenlik temel gereksinimleri

Satış verileri hassastır. Temelden başlayın:

• Veriyi aktarım sırasında şifreleyin (HTTPS) ve mümkünse saklama sırasında da şifreleme uygulayın.
• Varsayılan olarak asgari ayrıcalık (rep vs. yönetici vs. admin) kullanın.
• Oturum güvenliği: kısa ömürlü tokenlar, gerekli yerlerde CSRF koruması ve parola değişiminde oturumu kapatma.

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.

Gerçek satış kullanımına uygun test ve dağıtım

Testler pipeline’ın gerçek kullanımını yansıtmalı:

• Giriş testi: giriş, lead yakalama, fırsat oluşturma.
• Rol/izin testleri (rep diğer ekiplerin fırsatını görememeli, yönetici görebilmeli).
• Pipeline kural testleri (aşama geçişleri, zorunlu alanlar, kapanış nedenleri).

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.