CRM Yazılımı Nasıl Geliştirilir? Adım Adım Rehber

CRM yazılımı geliştirme, kişi, firma, fırsat ve görüşme kayıtlarını tek bir veri modelinde toplayan sistemi işletmenin satış akışına göre yazmaktır. CRM yazılımı nasıl yapılır sorusunun teknik cevabı dört karara dayanır: veri modeli, modül sırası, yetki ve entegrasyon. Aşağıda bu kararları sırayla anlatıyoruz. Eski Excel ya da hazır CRM verisinin taşınmasını, test ve yayın adımlarını da ekledik. CRM'in ne olduğunu önceki yazılarımızda ele aldık; burada yalnızca yapım işi var.

CRM yazılımı geliştirmeye nereden başlanır?

Koddan önce satışın bugünkü yolu çizilir: talep nereden gelir, kim arar, teklif nasıl çıkar, satış nerede kapanır. Bu çizim hem veri modelinin hem ekranların taslağıdır. Akış çıkarılmadan yazılan CRM, Excel'in pahalı bir kopyası olur.

İlk toplantıya yöneticiyle değil, satışı her gün yapan kişiyle oturmak gerekir. Kullandığı Excel dosyaları, teklif şablonları ve WhatsApp yazışmaları en dürüst kaynaktır. Aynı müşteriyi iki kişinin ayrı ayrı aradığı anlar da not edilir; CRM'in çözeceği asıl sorun çoğunlukla oradadır.

Ardından satış hunisinin aşamaları yazılır. Her aşamanın bir çıkış koşulu olmalı. Örneğin "Teklif gönderildi" aşaması, sistemde bir teklif kaydı yoksa seçilemez. Koşulsuz aşamalar, raporları birkaç hafta içinde anlamsız hâle getirir.

Analiz, kapsam belgesi ve onay adımlarının genel akışını yazılım geliştirme sürecinin aşamaları yazımızda anlattık. CRM projesi de aynı sırayla ilerler.

Temel veri modeli neye benzer?

Bir CRM'in iskeleti beş varlıktan oluşur: kişi, firma, fırsat, aktivite ve teklif. Aralarındaki ilişkiler doğru kurulursa raporlar kendiliğinden doğru çıkar. Yanlış kurulursa hiçbir ekran bunu sonradan düzeltemez.

Fırsat, belirli bir firmayla beklenen tutar ve kapanış tarihiyle yürüyen tek bir satış ihtimalidir. Müşteri değil, satış izlenir. Aynı firmayla yıl içinde üç ayrı iş konuşuluyorsa üç fırsat açılır.

• Firma ve kişi: Bir firmada birden çok yetkili olur. Bireysel müşteride firma alanı boş kalabilir.
• Firma ve fırsat: Bir firmanın birden çok fırsatı olur. Her fırsatın tek sahibi bir kullanıcıdır.
• Fırsat ve teklif: Bir fırsata birden çok teklif sürümü bağlanır. Yalnızca biri "kabul edildi" olabilir.
• Teklif ve kalem: Ürün ya da hizmet, miktar, birim fiyat, indirim ve KDV satır satır tutulur.
• Aktivite: Arama, toplantı, e-posta, WhatsApp mesajı ve görev. Kişiye ve fırsata bağlanır.

En sık hata, firma adını kişi kartında serbest metin olarak tutmaktır. "ABC Ltd." ile "ABC Limited" iki ayrı müşteriye dönüşür. Firma ayrı bir tablo olmalı, kişi ona bağlanmalıdır. Teklif tutarını yalnızca fırsatın üstüne yazmak da revizyon geçmişini siler.

Telefon numaraları tek biçimde saklanmalıdır. Uluslararası E.164 biçimi (+90 ile başlayan yazım) tekilleştirmeyi ve WhatsApp eşleşmesini kolaylaştırır. Kayıtlar da silinmek yerine pasife alınır. Kimin neyi, ne zaman değiştirdiği ayrı bir değişiklik günlüğünde durur.

Sektöre özel alanlar nereye eklenir?

Her işletmenin kendine özgü alanları vardır ve bunlar için iki yol bulunur. Sık kullanılan, rapora girecek alanlar tabloya gerçek sütun olarak eklenir. Seyrek kullanılanlar esnek bir ek alan yapısında tutulur.

Bir klinik için "ilgilendiği tedavi", bir inşaat firması için "metrekare" rapora girecek alanlardır. Bunları esnek yapıya koymak, filtre ve raporu yavaşlatır. Öte yandan her küçük alan için sütun açmak da tabloyu şişirir. Bizim kuralımız basit: listede filtrelenecek ya da raporda toplanacak alan sütun olur. Gerisi esnek kalır.

İlk sürümde hangi modüller olmalı?

İlk sürüm, satış ekibinin her gün açacağı kadar küçük, işe yarayacak kadar da eksiksiz olmalıdır. Bizim tercihimiz kayıt, fırsat hunisi, aktivite ve teklifle başlamak. Raporlar ve otomasyonlar veri biriktikten sonra gelir.

1. Sürüm 1: Kişi ve firma kayıtları, fırsat hunisi, aktivite ve görev, PDF teklif, temel roller, Excel'den içe aktarma.
2. Sürüm 2: Web formu, reklam formu, e-posta ve WhatsApp bağlantısı, hatırlatma bildirimleri.
3. Sürüm 3: Raporlar ve panolar, otomasyon kuralları, muhasebe bağlantısı, telefon için uygulama.

Orta ölçekli bir projede örnek plan şöyle olabilir. Analiz ve prototip 3 hafta, birinci sürüm 10 hafta sürer. İkinci ve üçüncü sürüm altışar hafta alır. Toplam 25 hafta eder ve ekip ilk kayıtlarını 13. haftada girer.

Raporu ilk sürüme koymamak bilinçli bir seçimdir. Boş bir veritabanı üzerine çizilen pano, kimsenin sormadığı soruları cevaplar. Üç ay sonra yöneticinin gerçekten neye baktığı bellidir. Telefon tarafında ise çoğu zaman ayrı bir mağaza uygulaması gerekmez. Projelerimizde kullandığımız PWA ve web push bildirimi, hatırlatma gibi işleri tarayıcı üzerinden çözer.

Yetki ve roller nasıl kurulur?

Yetki, kimin hangi kaydı görebileceğini ve neyi değiştirebileceğini belirleyen kurallar bütünüdür. Varsayılan cevap "hayır" olmalı; her izin tek tek açılır. Kontrol yalnızca ekranda değil, sunucuda her istekte yapılır.

OWASP'ın yetkilendirme rehberi üç kuralı öne çıkarır: en az yetki, varsayılan ret ve her istekte kontrol. Pratikteki karşılığı basittir. Adres çubuğundaki kayıt numarasını değiştiren temsilci, başkasının fırsatını görmemelidir. Dışa aktarma da ayrı bir izindir; kim, ne zaman, kaç kayıt indirdi, günlüğe yazılır.

KVKK açısından CRM'de neler tutulmalı?

CRM kişisel veri tutar; bu yüzden saklama süresi, silme ve erişim kaydı tasarımın parçasıdır. Hukuki metinler avukatla hazırlanır. Yazılımın görevi bu kuralları uygulanabilir kılmaktır.

Kişisel verilerin silinmesine ilişkin yönetmeliğe göre periyodik imha aralığı altı ayı geçemez. Yapılan imha işlemlerinin kaydı en az üç yıl saklanır. Bu yüzden her kayıt türüne bir saklama süresi alanı ve otomatik bir imha listesi koymak gerekir. KVKK'nın 12. maddesi de veriyi işleyen yazılım ekibini güvenlik tedbirlerinden müştereken sorumlu tutar.

Hangi entegrasyonlar önce bağlanmalı?

Önce talebin geldiği kanallar bağlanır: web formu, reklam formu, e-posta ve WhatsApp. Talep CRM'e elle girildiği sürece kayıp da sürer. Muhasebe bağlantısı, satış tarafı oturduktan sonra gelir.

• Web formu: Gönderim doğrudan kişi ve fırsat kaydı açar. Kaynak bilgisi (UTM) ayrı alanlarda tutulur.
• Reklam formu: Meta potansiyel müşteri formları, leadgen webhook'uyla anında bildirim gönderir. Form verisi bu kimlikle API'den çekilir.
• E-posta: Gelen ve giden yazışma, adresinden tanınan kişinin kartına bağlanır.
• WhatsApp: Müşteri yazınca 24 saatlik bir pencere açılır. Pencere dışında yalnızca onaylı şablon mesaj gider.
• Muhasebe: Kabul edilen teklif, cari kart ve fatura taslağına dönüşür. Tek yönlü başlamak yeterlidir.

Kaynak bilgisi satış kapanana kadar korunmalıdır. Reklamdan gelen formda tıklama kimliği de saklanırsa, kapanan satış reklam platformuna geri bildirilebilir. Google Ads'in çevrimdışı dönüşüm içe aktarma özelliği bu kimlikle çalışır. Böylece reklam, form sayısına göre değil gerçek satışa göre değerlendirilir.

Toplu e-posta ve SMS ayrı bir kurala tabidir. İleti Yönetim Sistemi (İYS) dışında alınan onaylar, üç iş günü içinde İYS'ye kaydedilir. Ret bildirimi gelen kişiye de üç iş günü içinde gönderim durdurulur. CRM'deki izin alanı bu yüzden İYS ile eşleşmelidir.

Formlarımızda botları Cloudflare Turnstile ile süzüyoruz; CRM'e sahte kayıt düşmesini en ucuz yoldan önler. Sitemizin yönetim panelini ve Search Console API bağlantısını da kendimiz yazdık. Dış API'lerle çalışırken her bağlantıya hata kaydı ve yeniden deneme koymayı tercih ediyoruz. WhatsApp ve e-posta akışlarının kullanıcı tarafını CRM seçim rehberimizde anlattık.

Eski Excel ya da hazır CRM verisi nasıl taşınır?

Veri taşıma yedi adımda yapılır: kaynakları listeleme, eşleme, temizlik, tekilleştirme, deneme aktarımı, doğrulama ve son aktarım. En çok zamanı temizlik alır. Son aktarımdan önce eski sistem kısa bir süre salt okunur yapılır.

1. Kaynakları listeleyin: Excel dosyaları, eski CRM'in dışa aktarımı, e-posta rehberleri.
2. Alan eşleme tablosu yazın: Her eski sütunun yeni sistemdeki karşılığı belirlenir.
3. Temizleyin: Telefon biçimi, il adları ve boş satırlar düzeltilir.
4. Tekilleştirin: Vergi numarası, e-posta ya da telefonu aynı olan kayıtlar birleştirilir.
5. Deneme aktarımı yapın: Test ortamında önce 100 kayıtla başlanır.
6. Doğrulayın: Kayıt sayıları kaynakla karşılaştırılır, her temsilci kendi 10 müşterisine bakar.
7. Son aktarımı yapın: Eski sistem salt okunur olur, aradaki fark aktarılır.

Karşılığı olmayan sütunlar atılmaz, not alanına taşınır. Açık fırsatlar ve son dönemin aktiviteleri tam aktarılır. Çok eski notlar ise kişinin kartına arşiv dosyası olarak eklenebilir. (Her eski satırı yeni bir alana zorlamak, temiz bir modeli ilk günden bozar.)

Deneme aktarımında mümkünse maskelenmiş veri kullanılır. Aktarım dosyaları e-postayla dolaşmaz, iş bitince silinir.

Test ve yayın nasıl planlanır?

Test üç katmanda yapılır: yetki, entegrasyon ve gerçek kullanıcıyla kabul. Yayın tek seferde değil, küçük bir pilot ekiple başlar. Pilot bitince herkes geçer ve eski tablo kapatılır.

Yetki testleri otomatik yazılır; OWASP da yetki mantığı için birim ve entegrasyon testi önerir. Her rol için "göremeyeceği kayıt" senaryosu en az bir kez denenir. Entegrasyonlarda deneme formu gönderilir, şablon mesaj ve fatura taslağı uçtan uca izlenir.

Kabul testi, kapsam belgesindeki gerçek iş senaryolarıyla yapılır. "Formdan gelen talep, temsilciye atanır, aranır, teklif alır ve kabul edilir" gibi uçtan uca bir akış seçilir. Satış ekibi bu akışı kendi verisiyle baştan sona yürütür. Takıldığı her adım bir düzeltme maddesi olur.

Pilot için iki üç temsilciyle iki hafta çoğu zaman yeterlidir. Asıl risk teknik değil, alışkanlıktır. Eski Excel paralel açık kalırsa ekip ona döner. Geçiş günü eski dosyayı salt okunur yapmak bu yüzden önemlidir. Günlük yedek alınır ve geri yükleme yayından önce bir kez denenir.

Yayından sonraki ilk ayda neye bakılır?

İlk ay, sistemin kullanılıp kullanılmadığını gösteren birkaç basit sayıyla izlenir. Bu sayılar teknik hatadan çok alışkanlık sorununu ortaya çıkarır. Haftada bir kısa toplantı, düzeltmeleri erken yakalamaya yeter.

• Haftada en az bir kez giriş yapan kullanıcı oranı
• Son 14 günde hiç aktivite girilmemiş açık fırsat sayısı
• Sahibi atanmamış kişi ve fırsat kayıtları
• Formdan gelip 24 saat içinde aranmayan talepler

Sayılar yükseliyorsa sorun çoğunlukla ekranın kendisindedir. Bir alan gereksiz yere zorunluysa ya da bir kayıt üç tıklamadan fazla istiyorsa ekip kestirme yol bulur. İlk ayın düzeltmeleri, ikinci sürümden önce bu tür sürtünmeleri gidermeye ayrılmalıdır.

Süreyi ve maliyeti ne belirler?

Süre ve maliyeti en çok entegrasyon sayısı, rol sayısı ve taşınacak verinin dağınıklığı belirler. Ekran sayısı sanıldığı kadar belirleyici değildir. Sabit bir rakam yerine bu etkenlerin listesiyle teklif istemek daha doğru karşılaştırma sağlar.

• Her entegrasyon ayrı bir geliştirme, test ve bakım kalemi demektir.
• Rol sayısı arttıkça yetki testleri de artar.
• Dağınık bir Excel, temizlik işini haftalarca uzatabilir.
• Teklif ve fatura kuralları karmaşıksa teklif modülü büyür.

Hazır paketle yan yana maliyet hesabını özel CRM maliyet analizi yazımızda yaptık. Kapsamı birlikte çıkarmak isterseniz CRM uygulaması hizmetimiz sayfasından bize ulaşabilirsiniz. İlk görüşmeye bugünkü Excel dosyanızla gelmeniz yeterli.