CRM Entegrasyonu: E-posta, Takvim, Muhasebe ve API Bağlantısı

CRM entegrasyonu neyi çözer?

Bağlantısız bir CRM’de gün şöyle geçer: müşteriye posta kutusundan yazarsınız, notu CRM’e girersiniz, toplantıyı takvime koyarsınız, teklifi ayrı bir dosyada hazırlarsınız, faturayı ön muhasebede kesersiniz. Aynı müşteri beş yerde ve hiçbiri diğerini bilmez.

Entegrasyonun işi bu beş yeri teke indirmek değil, çünkü o sistemlerin çoğu yerinde kalacak. İşi, aralarındaki elle kopyalamayı bitirmek. Ölçüsü de basit: bir bağlantı, birinin her gün yaptığı bir yapıştırma işini ortadan kaldırıyorsa iyi bir bağlantıdır.

Neyi neyle bağlarsınız sorusu kadar bağlantının nasıl kurulduğu da önemli, çünkü ne kadar yaşayacağını o belirliyor. Türkiye’de satan bir ekibin önüne pratikte dört kalıp çıkıyor. Dördü de çalışır; dördü başka bir yerden bozulur ve bakım yükünü başka birine bırakır.

Dört bağlama yöntemi

• Hazır bağlayıcı. İki ürünün üreticisi birbiri için yazmıştır; açmak birkaç ekran sürer. Karşılığında pazarlık payınız yoktur: hangi alanlar taşınıyorsa odur. Bozulduğunda elinizde ayar yapacak bir yer de olmaz, o yüzden kontrol tek soruya iner: dün gece çalıştı mı?
• Entegrasyon platformu (iPaaS). Araya giren üçüncü bir servis iki sistemi konuşturur; eşlemeyi ve koşulları kod yazmadan siz kurarsınız. Bedeli üçüncü bir abonelik ve öğrenilecek üçüncü bir arayüz. Tipik bozulması teknik değil insani: akışı kuran kişi ayrılır, o hesaba kimse girmez, aylar sonra ne yaptığını kimsenin bilmediği bir kutuya döner.
• Doğrudan API. Geliştiriciniz iki sistemi kodla bağlar. Koşulu, yeniden denemeyi ve kayıt tutmayı istediğiniz gibi yazarsınız; en çok denetim burada. Bedeli sürekliliktir: bağlantı bir proje değil, bakımı olan bir yazılım parçasıdır ve o bakımı yapacak kişinin adı bugünden belli olmalı.
• Zamanlanmış dosya aktarımı. Gece çalışan bir iş, bir sistemden aldığı listeyi diğerine yazar. Küçümsenir; oysa çoğu yerde en dayanıklısıdır, çünkü ters giden bir aktarımda elinizde açıp bakabileceğiniz bir dosya kalır. İki bedeli var: veri sabaha kadar eskir, aynı dosya iki kez işlenirse mükerrer kayıt üretir.

Yöntem seçimi bir zevk meselesi değil, kimin bakacağı meselesi. Adı belli bir sahibi olmayan bağlantıyı hiç kurmayın; kurulan her köprü, bir gün birinin sabah açıp durumuna bakacağı bir şeydir. Programın ekipteki rolü hâlâ tartışılıyorsa CRM’in ne olduğu bu kararlardan önce gelir.

Önce sahibi belirleyin

Her veri parçasının tek bir sahibi olmalı. Sahip, o bilginin doğrusunun tutulduğu sistemdir; diğerleri kopya tutar ve o kopyayı düzenlemez. Bu tek cümle, entegrasyon projelerinin yarısını daha başlamadan sadeleştiriyor.

Pratikte dağılım genelde şöyle olur: müşteri ve fırsat kaydının sahibi CRM, cari hesap ve fatura kaydının sahibi ön muhasebe, mesajların sahibi posta kutusu, toplantıların sahibi takvim. Bu tabloyu bir kere yazın; her tartışmada ona bakın.

Sahiplik belirlenmediğinde iki sistem aynı alanı birbirine yazmaya başlar ve bir süre sonra hangisinin doğru olduğunu kimse bilmez. Kayıt yapısı tarafını kayıtların nasıl ilişkilendiği rehberinde ayrıca ele aldık.

İki sistem aynı alanı değiştirdiğinde

Sahiplik tablosu ilk çakışmaya kadar teorik kalıyor. Bir gün satışçı CRM’de müşterinin yetkilisini günceller; aynı hafta muhasebeci ön muhasebede aynı kartta başka bir yetkili yazar. Gece senkron çalıştığında iki değerden biri sessizce gider. Kural yazılmazsa bu bir kereye de kalmaz: iki taraf birbirine yazdıkça her senkron diğerinin sonucunu bozan bir döngüye dönüşür.

Bu yüzden cevabı kayıt düzeyinde değil alan düzeyinde arayın. Tabloyu alan alan yazın: yetkili kimin, vergi numarası kimin, vade kimin. Sonra tek bir cümleyi proje başlamadan karara bağlayın: çakışmada hangi taraf kazanır? İki makul cevap var, alanın sahibi kazanır ya da en son yazan kazanır. Birincisi daha güvenli, ikincisi daha hızlı. Yanlış olan tek seçenek, bu soruyu ilk çakışmaya kadar ertelemek.

Kaybedeni de görünür kılın. Reddedilen yazma denemeleri bir yere düşsün ve o listeye ayda bir bakan biri olsun. Görünmeyen çakışma, aylar sonra “bu bilgi neden yanlış” diye soran kişiyi cevapsız bırakır.

Çift yönlü senkron ne zaman gerekir?

Tek yönlü senkronda bilgi bir taraftan diğerine akar ve hedef taraf onu değiştirmez. Çift yönlü senkronda iki taraf da aynı kaydı değiştirebilir ve değişiklik karşıya taşınır.

Çift yönlü senkron kulağa daha gelişmiş gelir, ama her zaman daha iyi değildir: iki sistem aynı alanı yönetirse çakışma ve geri yazma döngüsü oluşabilir, alan bazında tek sahip çoğu zaman daha güvenlidir. Çift yönün doğru olduğu tipik yer posta kutusu: CRM’den gönderdiğiniz e-posta gerçekten posta kutunuzdan çıkmalı, müşterinin cevabı da doğru kaydın üstüne düşmeli. Fatura tarafında ise çift yönlü çalışmak, aynı belgenin iki sistemde farklı hâllerini üretebilir.

Karar kuralı şu: iki tarafın da aynı alanı değiştirmesi gerçekten gerekiyorsa çift yönlü, gerekmiyorsa tek yönlü kurun. Şüphedeyken tek yönlü doğru cevap.

E-posta ve takvim entegrasyonu: ilk bağlanacak iki sistem

Bir CRM’i ikinci bir yazma yeri olmaktan çıkaran tek şey posta kutusu bağlantısıdır. Bağlantı açıldığında müşteriyle yapılan yazışma ilgili kaydın altına düşer; kimse bir e-postayı kopyalayıp nota yapıştırmaz, fırsatı devralan iş arkadaşı da yazışmanın tamamını aynı yerde okur.

Senitix CRM’de posta kutusu kullanıcı bazında bağlanır. Gmail ve Microsoft Outlook hesapları doğrudan, diğer sağlayıcılardaki kutular IMAP ve SMTP ile eklenir; takvim için Google Takvim ya da Microsoft Takvim seçilir. Bir kullanıcının bağlayabileceği posta kutusu sayısı gibi plan ayrıntıları fiyatlandırma sayfasındaki plan karşılaştırmasında yazılı.

Bugün bağlanmayan kanalları da bilerek başlayın. WhatsApp, Instagram, Messenger ve Telegram konuşmaları yakında CRM kaydına bağlanacak; ekip için ortak gelen kutusu ve kaydedilip yeniden kullanılan e-posta şablonları da henüz yayında değil. Zoom, Google Meet ve Microsoft Teams bağlantıları da henüz sunulmuyor; o güne kadar görüntülü görüşme ilgili kayda aktivite olarak işlenir. Gelen kutusunun günlük kullanımını özellik kataloğunun e-posta bölümü anlatıyor.

Takvim bağlantısının faydası daha sessiz ama gerçek: görüşme kaydın üstünde göründüğü için “bu müşteriyle en son ne zaman oturduk” sorusu bir arama işi olmaktan çıkar.

Posta kutusu bağlanırken çoğu ekibin gözden kaçırdığı bir ayar var: hangi yazışmanın kayda düşeceği. Gmail, Outlook ya da IMAP/SMTP bağlantısını değerlendirirken hangi klasörlerin, kullanıcıların ve iletilerin CRM’e kaydedileceğini tanımlayın ve özel konuşmaları ayırın. Her şeyi çekmek, iç yazışmaları ve kişisel postaları da CRM’e taşır; doğru kurgu genellikle yalnız müşteriyle yapılan yazışmanın senkronlanması, gerisinin posta kutusunda kalmasıdır. Senitix CRM’de bu eşitleme ayarları bağlı her hesap için ayrı yapılır.

Takvim tarafında da bağlantıyı açtığınız gün denenecek dört davranış var: bir toplantı iptal edildiğinde kayıt ne yapıyor, saat dilimi farkı olan bir katılımcıya toplantı hangi saatte görünüyor, davetli listesi kayda düşüyor mu ve tekrar eden bir etkinlik tek kayıt mı yoksa her hafta yeni bir kayıt mı üretiyor. Dördü de on dakikada denenir; aylar sonra fark edildiğinde temizlenmesi gün alır.

Muhasebe ve ERP entegrasyonu: teklifin faturayla buluştuğu yer

Türkiye’de satan ekipler için üçüncü bağlantı genellikle ön muhasebe ya da ERP olur. Amacı, kazanılan bir fırsatın kalemleri yeniden yazılmadan faturaya dönüşmesi ve tahsilat durumunun satış tarafında da görünmesi.

Muhasebe bağlantısında dikkat edilecek nokta sahiplik: cari kartın sahibi ön muhasebedir. CRM’in işi cari kartı yönetmek değil, aynı müşteriyi doğru cariyle eşleştirip fatura durumunu okumak. Örneğin satış fırsatı CRM’de, kesinleşen muhasebe fişi muhasebe sisteminde tutulur.

Senitix CRM’de Paraşüt ve Mikro ERP’ye hazır bağlantı var: Paraşüt cari kartlarını, satış faturalarını, e-Fatura/e-Arşiv durumunu, tahsilatları ve ürün kataloğunu getirir; Mikro ERP kendi Mikro Desktop API servisi üzerinden cari, stok, satış faturası kayıtlarını ve GİB’e iki aşamalı e-Fatura/e-Arşiv gönderimini taşır. Başka bir muhasebe programı kullanan ekipler için bugün muhasebeye giden veri CSV ya da Excel dışa aktarımıyla taşınır; REST API teklif, ürün ve fatura kayıtlarını kapsamadığı için o programlar tarafında doğru yol yine dosya aktarımıdır.

Sınır nerede: e-Fatura ve e-Arşiv

Bir noktayı net yazalım: CRM’deki fatura kaydı resmî belge değildir. Türkiye’de satış belgesi e-Fatura ya da e-Arşiv olarak düzenlenir; bu düzenleme ön muhasebe programınızda veya özel entegratörünüzde yapılır. Senitix CRM’de kabul edilen tekliften ya da siparişten bir fatura kaydı oluşturulur ve tahsilatlar bu kaydın üzerine işlenir. Senitix’in kendisi e-Fatura ya da e-Arşiv düzenleyicisi değildir; bağlı Paraşüt ya da Mikro hesabınız varsa bu belge CRM’den çıkmadan o hesap üzerinden gönderilir, yoksa ön muhasebe programınızda veya özel entegratörünüzde düzenlenir. Bir CRM’in bu zincirdeki rolü belgeyi üretmek değil, belgeyi doğuran ticari kararı kayda geçirmek: hangi müşteriye, hangi kalemlerden, hangi fiyatla ve kimin onayıyla teklif verildi.

Sınır pratikte şöyle çizilir. Teklif, revizyonları ve onayı satış tarafında durur. İş kazanıldığında sipariş ya da sözleşme bilgisi muhasebeye geçer; belge numarası, resmî durum ve tahsilat orada oluşur, satış tarafı bunları yalnızca okur. Ters yön de kurala bağlanmalı: muhasebede kesilen bir belge, satış tarafında bir aşamayı kendiliğinden ilerletmemeli. Bu sınırı yazmayan ekipler bir süre sonra CRM’e fatura alanları eklemeye başlıyor ve iki sistem aynı belge hakkında ayrı ayrı kayıt tutuyor.

Bağlantıyı kurmadan önce iki sayfa hazırlayın. Birincisi alan alan sahiplik listesi: müşteri kartı, ürün, vergi oranı, fiyat, teklif ve fatura satırlarının hangi tarafta doğru kabul edileceği tek tek yazılır. İkincisi bağlantının künyesi: hangi hesapla ve hangi kimlik doğrulamayla giriliyor, hangi şirket ve dönem seçili, karşı tarafın oran sınırı ne ve hata alındığında aktarım kaç kez tekrar deniyor. Bu iki sayfa yoksa bağlantıyı kuran kişi ayrıldığında bağlantının ne yaptığını kimse anlatamaz.

Eşleştirme anahtarı ve alan haritası

İki sistemin “bu iki kayıt aynı şey” diyebilmesi için sabit bir değere ihtiyacı var. Kişilerde bu genellikle e-posta adresi, firmalarda vergi numarası ya da cari kod olur.

Firma adı asla anahtar olmaz. “Yılmaz Lojistik”, “Yılmaz Lojistik A.Ş.” ve “yilmaz lojistik” üç ayrı kayıt üretir ve bu üç kayıt bir daha kendiliğinden birleşmez. Anahtar seçimi, entegrasyonun en az konuşulan ama en belirleyici kararı.

Alan haritası ise şu tabloyu ifade eder: burada hangi alan, orada hangi alana karşılık gelir. Sıkıcı bir belge ve genelde hiç yazılmaz; oysa aktarımın tutup tutmayacağına karar veren şey tam olarak o. Aşama ve alan tasarımını henüz bitirmediyseniz CRM stratejisi rehberindeki aşama, alan ve rapor kararları bu adımdan önce gelir.

Entegrasyonlar hangi sırayla kurulur?

Hepsini aynı hafta açmayın. Bir bağlantı bozulduğunda hangisinin bozulduğunu bilmek istiyorsanız sıra şu.

Her adımın içinde aynı küçük döngü döner: iş sonucunu ve veri sahibini tanımlayın, alan sözlüğünü ve kimlik eşlemesini yazın, örnek kayıtlarla bir test ortamında deneyin, hata, tekrar ve silme senaryolarını çalıştırın. Sonra bağlantıyı küçük bir kullanıcı grubuyla açın ve senkron gecikmesiyle hata oranını izleyin; hacim ancak ondan sonra gelir. Dar grup, ters gideni ilk gün söyleyecek ve söylerken de kızmayacak kişilerden kurulur; genelde iki satışçı yeter.

Bu sıra, programı sıfırdan devreye alıyorsanız daha büyük bir planın içindeki tek bir adım. Veri taşıma ve pilot kararları bağlantılardan önce gelir; hepsini ilk haftaya sıkıştırmanın tek kazancı takvimde iyi görünmektir. Adımların tamamını ve her birinin geçiş koşulunu CRM kurulumu rehberinde bulacaksınız.

Entegrasyon en sık nerede bozulur?

• Süresi dolan yetki. Posta kutusu bağlantısının izni sessizce düşer ve kimse fark etmez. Bağlantı durumunu gösteren bir ekran olmalı ve birinin ona bakması gerekir.
• Ayrılan personelin hesabı. Kapatılan kullanıcıyla birlikte ona bağlı senkron da durur; kayıtlar o günden sonra boş kalır.
• İstek sınırı. Testte sorunsuz çalışan senkron, ay sonu hacminde karşı sistemin sınırına takılır. En sık görülen “dün çalışıyordu” sebebi.
• Zayıf anahtar. Firma adına ya da telefona göre eşleşen kayıtlar, birkaç ay içinde mükerrer kayıt yığını üretiyor.
• Tekrarlanan aktarım. Aynı aktarımın iki kez çalışması ikinci seferde hiçbir şeyi değiştirmemeli. Değiştiriyorsa her yeniden deneme yeni kayıt üretir.

Bu arızaların çoğu kurulum gününde verilen kararlardan çıkar. Tipik beş hata şunlar: çift yönlü senkronu varsayılan seçmek, e-posta adresini değişmez kimlik sanmak, silmeyi iki tarafa yaymak, entegrasyon kullanıcısına tam yetki vermek ve hataları yalnızca log dosyasında bırakmak. Çift yönlü senkronu yukarıda ele aldık; kalan dördünün karşılığı şu:

• Entegrasyon kullanıcısına tam yetki. Bağlantı kendi hesabıyla çalışsın ve o hesap yalnızca dokunacağı alanları görsün. Tam yetkili bir bağlantı hesabı, bir gün yanlış çalıştığında en geniş hasarı verendir.
• Silmenin karşıya yayılması. Bir sistemde silinen kayıt diğerinde de silinmemeli. Silme tek yönde bile kalsa, önce arşivleyip sonra silen bir kural yazın.
• Değişen kimlik. E-posta sabit bir anahtar sayılır, ama kişi şirket değiştirdiğinde adresi de değişir. Anahtar değiştiğinde iki kaydın nasıl birleşeceğini önceden kararlaştırın.
• Hatanın yalnız kayıt dosyasında kalması. Sunucudaki log, kimse okumadığı sürece uyarı değildir. Hata sayısının bir insana ulaşan bir yolu olsun.

Bir de hukuki tarafı var: her entegrasyon, veriyi başka bir sisteme akıtmak demek. Senitix adına veri işleyen üçüncü tarafların ve yurt dışı aktarımların nasıl ele alındığını alt işleyenler ve yurt dışı aktarımlar sayfası anlatıyor; kendi kurduğunuz her bağlantı için de verinin nereye gittiğini gösteren bir liste tutun. Bağlantılardan sonra kurulacak hatırlatma ve görev kurallarını otomasyon kuralları bölümünde bulabilirsiniz.

Kayıt sahibi sistem

Bir bilginin doğrusunu tutan tek sistem. Diğerleri kopya tutar ve o kopyayı düzenlemez.

Çift yönlü senkron

İki tarafın da aynı kaydı değiştirebilmesi ve değişikliğin karşıya taşınması. Posta kutusu için doğru, çoğu yerde gereksiz.

Alan haritası

Buradaki hangi alanın oradaki hangi alana karşılık geldiğini gösteren tablo. Aktarımın tutup tutmayacağına karar veren belge.

Eşleştirme anahtarı

İki kaydın aynı şey olduğunu belirleyen sabit değer: e-posta, cari kod ya da vergi numarası. Firma adı olmaz.

Tekrara dayanıklı

Aynı aktarımı iki kez çalıştırmanın ikinci seferde hiçbir şeyi değiştirmemesi. Yeniden denemenin mükerrer kayıt üretmesini engelleyen özellik.

Geçmiş yükleme

Canlı bağlantı açıldıktan sonra eski verinin bir kerelik aktarılması; kayıt boş başlamasın diye yapılır.

İstek sınırı

Bir sistemin diğerine ne sıklıkta cevap vereceğinin tavanı. Ay sonunda bozulan senkronların olağan sebebi.

Yetki süresi

Bağlantının izninin geçerli olduğu süre. Sessizce dolduğunda senkron durur, hata mesajı çıkmaz.

CRM API entegrasyonu ve webhook

API çağrısı istek üzerine veri okur veya yazar; webhook ise bir olay olduğunda hedef sistemi kendiliğinden bilgilendirir. İkisinde de kimlik doğrulama, en az yetki, tekrara dayanıklılık (idempotency), oran limiti, imza doğrulama, tekrar deneme ve başarısız olay kuyruğu üretim tasarımının parçasıdır.

Senitix CRM’in REST API’si dört kayıt tipini kapsar: kişi, firma, fırsat ve aktivite. Bu, geliştiricinizin doğrudan bağlanacağı açık bir uç değildir: bağlantı, Senitix’in sizin için kaydettiği bir uygulama üzerinden kurulur ve o uygulamanın okuma, yazma ve silme için ayrı yetki kapsamı, kendi istek sınırı vardır.

Bayi portalınızdan gelen bir talebi fırsat olarak açmak, çağrı merkezi yazılımınızdaki bir görüşmeyi aktivite olarak işlemek ya da firma listesini ERP’deki cari listesiyle eşlemek gibi ihtiyaçlar bu dört kayıt tipiyle karşılanabilir, ama entegrasyonu siz baştan yazmazsınız. Aday, teklif, ürün, sipariş, fatura ve özel nesne kayıtları kapsam dışıdır, özel alanlar da API üzerinden yazılmaz. Böyle bir bağlantıya ihtiyacınız varsa kapsamı ve erişimi işe başlamadan Senitix ekibiyle netleştirin; bağlantı, ekibimizin kaydettiği bir uygulama üzerinden açılır.

Giden webhook’lar, yani bir kayıt değiştiğinde ilgili adrese kendiliğinden bildirim gönderen yönetilen uçlar, yakında geliyor. O güne kadar değişikliği izlemek isteyen taraf, kayıtlı uygulama üzerinden API’yi belirli aralıklarla sorgular; bu, zamanlanmış dosya aktarımına benzer bir çözümdür ve gecikme payını siz seçersiniz. Sorgunun kaldığı yeri kaydetmesi ve aynı sorgunun iki kez çalışmasının yeni kayıt üretmemesi, bu yöntemin olmazsa olmaz koşuludur.

Posta kutusu, takvim, API ve dosya aktarımının Senitix CRM’de nasıl çalıştığını özellik kataloğunun entegrasyon bölümü gösteriyor; bir CRM satın alırken hangi yeteneklere bakılacağını ise CRM’de aranması gereken yetenekler rehberinde sıraladık.

Entegrasyonun çalıştığını nasıl ölçersiniz?

Kabul testinde yeni, güncellenen, silinen, birleştirilen, aynı anda değiştirilen ve hatadan sonra tekrar çalışan kayıtları deneyin. Canlıya geçtikten sonra izlenecek KPI’lar şunlar: senkron gecikmesi, hata ve tekrar oranı, üretilen mükerrer kayıt, eşleşmeyen alan, yetkisiz erişim denemesi ve elle düzeltmeye harcanan süre.

Bu ölçüleri ayrı bir panoya koymayın. Zaten her hafta okunan satış raporunun altına iki satır olarak düşürün: dün gece kaç kayıt taşındı, kaçı hata verdi. Kimsenin açmadığı bir pano, bozulmuş bir bağlantıyı kimseye haber vermez. Bu ritmi ayakta tutan alışkanlıkları CRM en iyi uygulamaları rehberinde topladık.