Özel CRM yazılımı: hazır CRM yerine ne zaman yaptırılmalı

Hazır CRM mi, özel yazılım mı sorusunun cevabı çoğu zaman yazılımda değil, satış ve müşteri süreçlerinizin ne kadar kendine özgü olduğunda. Standart bir huniyi yönetiyorsanız hazır ürün size ucuza ve hızlı hizmet eder. Süreciniz rakiplerinizden sizi ayıran şeyse ve hazır bir ürünün kalıplarına sığmıyorsa özel yazılım anlam kazanıyor. Bu ayrım ilk bakışta basit görünüyor ama pratikte karar çoğu zaman tersinden veriliyor: "bizim sürecimiz özel" diyen herkes süreci gerçekten özel değil.

Bu yazıda kararı verirken kullandığım ölçütleri, özel yazılımın gizli maliyetlerini ve yetki ile kişisel veri tarafındaki sorumlulukları sıralıyorum. Özel yazılım yapan biri olarak bu konuda çıkarım var, bunu saklamıyorum. Bu yüzden ters yönü de dürüstçe yazdım: birçok şirket için hazır ürün doğru cevap.

Ölçüt: CRM sizin için ne

Martin Fowler'ın "Utility vs Strategic" ayrımı bu soruya iyi oturuyor. Fowler, bir sistemin yardımcı (utility) mı, stratejik mi olduğunu, destek verdiği iş işlevinin şirketi rakiplerinden ayırıp ayırmadığına bakarak belirliyor. Bordro tipik yardımcı sistem: herkesin ihtiyacı var ve sorunsuz çalışması yeterli. Yardımcı sistemler için paketlenmiş ürünün ve işin ürüne uyarlanmasının genellikle uygun olduğunu söylüyor. Stratejik sistemler ise özel yazılım gerektiriyor çünkü fırsatı kaçırmanın maliyeti geliştirmenin maliyetinden çok daha yüksek. Fowler stratejik projelerin nadir olduğunu da ekliyor.

Bunu CRM'e uyarlarsak:

Satış süreciniz sektördeki herkesinkine benziyorsa (aday, görüşme, teklif, kapanış) CRM bir yardımcı sistemdir. Hazır ürün alın, sürecinizi ona uydurun.
Müşteri sürecinizin kendisi rekabet avantajınızsa, örneğin randevu, saha ekibi, tedavi ya da hizmet planı, çok adımlı onay gibi akışlar işinizin özüyse, CRM stratejik olabilir.

Hazır ürünün doğru olduğu durumlar

Süreç standart: adaylar bir hunide ilerliyor, teklif veriliyor, kapanış oluyor.
Ekip küçük ve hızlı başlamak istiyor.
Entegrasyon ihtiyacı yaygın araçlarla sınırlı (e-posta, takvim, muhasebe, formlar).
Bakım yükünü üstlenecek birini işe almak ya da dışarıdan almak istemiyorsunuz.

Hazır ürünün bir bedeli yok sayılmasın: veri modelini ürün belirliyor, kendi alanlarınızı ekleyebiliyorsanız bile ilişkiler, raporlar ve yetkiler ürünün sınırında kalıyor. Fiyatlandırma kullanıcı ve özellik bazında değişebilir, sözleşmeyi imzalamadan verinizi hangi biçimde dışarı alabildiğinizi sorun.

Özel yazılımın anlam kazandığı durumlar

Aşağıdaki işaretlerden birkaçı birlikte varsa özel yazılımı ciddi düşünürüm:

Veri modeliniz hazır ürüne sığmıyor. Müşteri, kişi, fırsat ile anlatamadığınız nesneleriniz var: cihaz, seri numarası, vaka, seans, saha ziyareti, sözleşme versiyonu. Bunları hazır bir CRM'de not alanlarına gömüyorsanız veri değerini kaybediyor.
Şirket içi başka sistemlerle derin bağlantı gerekiyor: stok, üretim, randevu, muhasebe, bir iç portal. Kopyala-yapıştır ya da elle aktarım yapıyorsanız bu süreç otomatik olmalı.
Kendi algoritmanız ya da kuralınız var: kimin hangi talebi alacağı, öncelik sırası, fiyat hesaplama, bölge ataması. Bu mantık sizin avantajınız ise başkasının ürününe gömmek zor.
Yetki yapınız karmaşık: bayiler, alt bayiler, bölge sorumluları, kullanıcı başına satır düzeyinde görünürlük.
Veriyi ve altyapıyı kendiniz kontrol etmek istiyorsunuz: nerede tutulduğu, kimin eriştiği, nasıl yedeklendiği.
Yapay zeka ajanlarıyla çalışmak istiyorsunuz. Ajanların CRM verisini okuyup yazabilmesi için temiz bir API ve kontrollü yetkiler gerekiyor. Bu yönü LangGraph ile yapay zeka ajanı yazısında ayrıca ele aldım.

Hazır CRM'in uzun listesindeki özelliklerin çoğunu kullanmayacağınız iddiası pazarlama dilinde sık geçer. Bunun genel bir rakamı yok, ve ben de bir yüzde vermeyeceğim. Kendi kullanım verinize bakın: ekibiniz gerçekte hangi ekranları açıyor?

Ara yol: hazır ürün ve özel katman

Karar ikili olmak zorunda değil. Birçok durumda en sağlıklı yapı, standart işi hazır bir üründe bırakıp farkınızı yaratan kısmı ayrı bir uygulamada yazmak. Hazır ürünün API'si üzerinden iki sistemi konuşturursunuz. Bu hem riski hem ilk maliyeti düşürür. Tek dikkat edeceğiniz, verinin hangi sistemde "doğru kayıt" sayıldığını baştan belirlemek. İki yerde aynı müşteri bilgisi tutulursa, bir süre sonra hangisinin güncel olduğunu kimse bilmiyor.

Özel yazılımın gizli maliyetleri

Özel CRM'in maliyeti geliştirmeyle bitmiyor.

Bakım. Kütüphane güncellemeleri, güvenlik yamaları, sunucu ve yedekleme, işletim sistemi ve veritabanı sürümleri. Bunları kim yapacak?
Dokümantasyon ve sahiplik. Yazılımı yapan kişi ayrıldığında sistemi başka biri devralabilmeli. Kod, ortam bilgisi ve süreç yazılı değilse şirket tek kişiye bağımlı kalıyor.
Güvenlik. Hazır üründe bu işi satıcı yapıyor. Özel yazılımda siz yapıyorsunuz.
Kullanıcı eğitimi ve değişiklik talepleri. İhtiyaç değişir. Yeni alan, yeni rapor, yeni akış. Bu taleplerin bir bütçesi ve bir sırası olmalı.

Bunların çoğunu yazılımın ilk fiyat teklifinde göremezsiniz. Özel yazılım teklifinde "bakım ve destek" satırı yoksa bunu mutlaka sorun.

Mevcut verinin taşınması

Hangi yolu seçerseniz seçin ilk gerçek iş veri taşıma. Mevcut müşteri listeleri çoğunlukla elektronik tablolarda, e-postalarda ve birkaç farklı araçta dağınık duruyor. Taşımadan önce kayıtları tekilleştirmek, hangi alanların gerçekten gerektiğine karar vermek ve eski verinin ne kadarının yeni sisteme geçeceğini yazmak gerekiyor. Eski bir sistemden çıkış yolu da baştan düşünülmeli: verinizi hangi biçimde, ne kadar kolay dışarı alabildiğinizi, hazır ürün satın alırken de özel yazılım yaptırırken de sözleşmede netleştirin.

Yetki ve güvenlik

CRM müşteri verisi tuttuğu için en önemli güvenlik konusu erişim kontrolü. OWASP'ın 2025 listesinde bozuk erişim kontrolü birinci sırada. Tanım şu: kullanıcıların kendilerine verilen izinlerin dışında hareket edebilmesi. OWASP'ın iki ilkesi tasarıma doğrudan uygulanıyor: herkese açık kaynaklar dışında varsayılan olarak reddet ve kullanıcının yalnızca sahip olduğu kayıtlara erişebilmesini sağla. Kontrol de saldırganın değiştiremeyeceği, sunucu tarafındaki güvenilir kodda yapılmalı.

Veritabanı düzeyinde bunun karşılığı satır düzeyi güvenlik. PostgreSQL'de bir tabloda satır güvenliği etkinleştirildiğinde, bir ilke izin vermedikçe hiçbir satır görünmüyor ya da değiştirilemiyor, yani varsayılan reddetme. İlkeler komuta ve role göre tanımlanabiliyor. Dikkat edilecek nokta, tablo sahipleri ve BYPASSRLS yetkisi olanların bu ilkeleri varsayılan olarak atlaması. Uygulama, tablo sahibi bir kullanıcıyla bağlanıyorsa ilkeler hiç çalışmıyor olabilir. Bu tür ayrıntılar özel yazılımda tasarım kararı olarak sizin sorumluluğunuzda.

Yetki testlerini de yazın. "Satış temsilcisi A, temsilci B'nin müşterisini göremez" gibi basit bir test, çok pahalı bir hatayı önler.

Kişisel veri sorumluluğu

CRM kişisel veri tutuyor ve bu, 6698 sayılı KVKK kapsamında sizi veri sorumlusu yapıyor. Kanunun 12. maddesi veri sorumlusuna, kişisel verilerin hukuka aykırı işlenmesini ve erişilmesini önlemek ve muhafazasını sağlamak için uygun düzeyde teknik ve idari tedbirleri alma yükümlülüğü getiriyor. Kurumun yayımladığı veri güvenliği rehberleri ve veri sorumlularının yükümlülükleri (aydınlatma, VERBİS kaydı, ilgili kişi başvurularının cevaplanması) kurumun sitesinde. Hukuki danışmanlık vermiyorum, ama bir yazılım tasarımcısı olarak şunları sistemin içine koymayı öneririm:

Kim hangi kaydı ne zaman gördü ya da değiştirdi: denetim kaydı.
Veri silme ve anonimleştirme için bir mekanizma (sistemde silme düğmesi olmayan bir CRM, ilgili kişi başvurusunda sorun çıkarır).
Rol bazlı erişim ve ayrılan çalışanın yetkisinin kapatılması.
Yedeklerin şifrelenmesi ve yedeğe kimin eriştiğinin bilinmesi.
Hangi alanın hangi amaçla toplandığının kayıt altında tutulması.

Talebin geldiği yerleri bağlamak

CRM'in değeri, taleplerin nereden geldiğini ve sonunda ne olduğunu aynı yerde görmenizden doğuyor. Reklamdan, aramadan ve formdan gelen talebi kaynağıyla birlikte kaydedin. Bu, bir reklam hesabı sorun yaşadığında da hayat kurtarıyor, çünkü hangi kampanyanın satış getirdiğini hesabın dışında biliyorsunuz. Bu kısmı Google Ads hesap askıya alındı yazısında anlattım. Organik arama için de aynı mantık geçerli: teknik SEO çalışmasının işe yarayıp yaramadığını görmek, talebin satışa dönüşünü izleyebilmenize bağlı.

Kendi verinizi bir değer olarak kullanmanın başka bir yolu da şablonlu sayfa üretimi. Envanter, hizmet ya da vaka verisi sistemde düzenliyse bunun sayfaya dönüştürülmesi mümkün, ama bunun riskleri var ve programmatic SEO yazısında anlattım.

Karar tablosu

Durum	Eğilim
Standart satış hunisi, küçük ekip, hızlı başlangıç	Hazır CRM
Standart süreç, ama bir iç sistemle entegrasyon şart	Hazır CRM ve API ile özel katman
Veri modeli hazır nesnelere sığmıyor (cihaz, vaka, seans)	Özel yazılım ya da güçlü bir özelleştirilebilir platform
Süreç rekabet avantajınız, kural ve algoritma size ait	Özel yazılım
Bakım ve güvenliği üstlenecek kimse yok	Hazır CRM
Yetki yapısı çok katmanlı (bayi, alt bayi, bölge)	Özel yazılım ya da hazır ürünün yetki sınırlarını önceden test edin

Tek bir öneri vermem gerekirse: karar vermeden önce şirketinizin müşteri sürecini bir sayfaya çizin ve hazır bir CRM'in demo hesabında o süreci kurmayı deneyin. Süreç ürüne iki günde sığıyorsa özel yazılıma ihtiyacınız yok. Sığmayan yerleri not alın, özel yazılımın kapsamı o notlardır. Detay istiyorsanız iletişim sayfasından yazabilirsiniz, yaptığım işler işler sayfasında.