Google Sheets ile CRM arasında veri senkronizasyonu

Pazartesi sabahı, yirmi beş kişilik bir şirkette pazarlama sorumlusu haftalık raporu hazırlıyor. CRM'den lead listesini dışa aktarıp Google Sheets'teki dosyaya yapıştırıyor, çünkü yöneticinin alışkın olduğu pivot yıllardır orada duruyor ve kimse onu yeniden kurmak istemiyor. Aynı dosyada satış ekibinden biri, yanlış girildiğini düşündüğü iki telefon numarasını düzeltiyor. Çarşamba günü çalışan içe aktarım o tabloyu CRM'e geri yazıyor ve salı günü temsilcinin güncellediği üç alanın üzerine biniyor. Kimse fark etmiyor. On gün sonra bir müşteri "beni eski numaramdan aradınız" diyor; asıl kayıp o telefon değil, aradaki on gün boyunca hiç kimsenin hangi kaydın doğru olduğunu bilmemesi.

Google Sheets ile CRM arasındaki bağ, KOBİ'lerde en sık kurulan ve en az düşünülen entegrasyondur. Bu yazıda sırayla şunları ele alıyoruz: tablonun neden hâlâ hayatta olduğu ve ona hangi rolün verilmesi gerektiği, üç senkron deseni ve her birinin tipik arızası, kayıt anahtarı meselesi, alan eşleme ile sessiz tip bozulmaları, çift yönlü senkronda çakışma kuralı, senkron sıklığının nasıl seçileceği, tablonun sekme mimarisi, yetki ve gizlilik tarafı, bağlantı koptuğunda erken uyarı ve senkron yerine tam taşımanın gerektiği durumlar.

CRMHam sekmeGörünüm sekmesiHata sekmesiRapor

Tablo neden hâlâ orada?

Yaygın tavsiye "tabloları bırakın, her şeyi CRM'e alın" der. Doğru olduğu yerlerde bile bu tavsiye eksiktir, çünkü tablonun neden hayatta kaldığını açıklamaz. Google Sheets üç şeyi CRM'lerin çoğundan daha iyi yapar: beş dakikada yeni bir sütun açmayı, veriyi geçici bir modele göre yeniden dizmeyi ve sistemde hesabı olmayan biriyle paylaşmayı. Mali müşavir, dış ajans, bir defalık hesap yapan bir ortak — hepsi tabloya saniyeler içinde dahil olur.

Dolayısıyla doğru soru "tabloyu nasıl kapatırız" değil, "tablonun ne olmasına izin veriyoruz" sorusudur. Tablo bir uç nokta olabilir: veriyi CRM'den alır, gösterir, hesaplar. Tablo bir giriş kapısı olabilir: dışarıdan gelen listeyi karşılar, temizler ve CRM'e teslim eder. Tablonun olmaması gereken tek şey, bir kaydın doğrusunun orada durmasıdır. Raporlama ihtiyacının ne kadarının sistemin içinde karşılanabileceğini özel rapor oluşturucu yazısında ele alıyoruz; o ihtiyaç kapandığında tablo trafiğinin önemli bir kısmı kendiliğinden kaybolur.

Üç senkron deseni ve her birinin kendi arızası

Senkron kurmadan önce hangi deseni kurduğunuzu adlandırın; çünkü kurulumun zorluğu değil, arıza biçimi desene göre değişir. Tek yönlü dışa aktarımda veri CRM'den tabloya gider ve tablo bir gösterge paneli gibi davranır. Tek yönlü içe aktarımda tablo bir giriş kanalıdır: fuar listesi, tedarikçiden gelen dosya, bir kampanyanın kayıt formu. Çift yönlü senkronda iki taraf da yazar ve bu, en çok istenen ama en az anlaşılan desendir.

Desen	Ne zaman doğru	Tipik arıza
CRM'den tabloya	Rapor, pivot, dışarıyla paylaşım	Tablo elle düzenlenir, ertesi tazelemede yazılan kaybolur
Tablodan CRM'e	Liste alımı, etkinlik kaydı, toplu güncelleme	Anahtar yoksa her çalışmada yeni kopya
Çift yönlü	İki ekip gerçekten aynı kaydı yönetiyorsa	Son yazan kazanır, sessiz veri kaybı
Tek seferlik aktarım	Süreç kalıcı olarak CRM'e taşınıyorsa	Tablo silinmez, paralel yaşamaya devam eder
Formülle salt okunur bağ	Küçük referans listeleri	Yavaş tazelenme ve sessizce boş dönen hücreler

Tabloyu okurken dikkat edilecek nokta şudur: aynı dosyada iki farklı desen çalıştırmayın. Bir sekme CRM'den beslenip aynı zamanda CRM'e yazıyorsa, o dosya artık ne rapor ne giriş kanalıdır; kimsenin kuralını bilmediği bir orta katmandır. İçe ve dışa aktarımın temel mekaniğini veri içe/dışa aktarma yazısında ayrıntılı anlatıyoruz.

Kayıt anahtarı olmayan senkron kopya üretir

Bir tablo satırının CRM'deki hangi kayda karşılık geldiğini söyleyen kararlı bir anahtar yoksa, senkron her çalıştığında tahmin yürütür. Firma adıyla eşleştirme en kötüsüdür: "Aydın Tic. Ltd. Şti." ile "Aydin Ticaret" aynı firmadır ama hiçbir eşleştirme motoru bunu güvenle bilemez. E-posta biraz daha iyidir, ancak aynı kişi iki adres kullandığında ya da bir adres iki kişide birden bulunduğunda kırılır.

Doğru yöntem sıkıcı ama kesindir: CRM kayıt kimliğini tabloda bir sütun olarak taşıyın. Bu sütun ilk dışa aktarımda dolar, sonrasında elle asla değiştirilmez, korumalı ve tercihen gizlenmiş olur. Yeni satırlar için kimlik boştur; senkron boş kimlikli satırı "yeni kayıt" olarak işler ve oluşturduğu kaydın kimliğini tabloya geri yazar. Bu tek alışkanlık, çift kayıtların büyük kısmını daha oluşmadan bitirir. Eşleştirme ve tekilleştirme mantığının bütününü veri kalitesi ve doğrulama yazısında ele alıyoruz.

Anahtar kadar önemli ikinci konu normalizasyondur ve burada Google Sheets'in kendine özgü tuzakları vardır. Tablonun otomatik biçimlendirmesi başında sıfır olan telefon numarasını sayıya çevirip sıfırı yutar, uzun bir vergi numarasını bilimsel gösterime düşürür, "3-4" gibi bir metni tarihe dönüştürür. Bunların hiçbiri hata vermez; sadece veriyi bozar. Ayrıca büyük-küçük harf dönüşümü dil ayarına bağlıdır: Türkçe metinde "İstanbul" ile "istanbul" arasındaki dönüşüm beklediğiniz gibi çalışmayabilir ve iki satır eşleşmez. Çözüm basittir: eşleştirmede kullanılan sütunları metin biçimine sabitleyin, içe aktarımda otomatik tip algılamayı kapatın ve karşılaştırmayı kırpılmış, sadeleştirilmiş bir kopya sütun üzerinden yapın.

Alan eşleme ve sessiz tip bozulmaları

İki sistemi konuşturmanın asıl işi sütun adlarını eşlemek değil, değerlerin anlamını eşlemektir. CRM'de seçenek listesi olan bir alan tabloda serbest metindir; "Bekliyor", "bekliyor" ve "Beklemede" tabloda üç farklı değerdir, CRM'de ise ikisi geçersizdir. Senkronun bu durumda ne yapacağına önceden karar verin: satırı reddetmek mi, en yakın değere yuvarlamak mı, yoksa alanı boş bırakıp satırı işlemeye devam etmek mi?

Sayı ve tarih tarafında sorun daha sinsidir. Tablonun bölge ayarı ondalık ayırıcıyı virgül yaparsa, dışa aktarılan bir tutar başka bir sistemde bin katına çıkabilir. Tarih biçimi gün/ay ile ay/gün arasında gidip geldiğinde ayın ilk on iki günü sessizce yer değiştirir ve bu hatayı ancak on üçüncü günde fark edersiniz. Çok seçimli alanlar virgülle birleştirilip tek hücreye yazıldığında, içinde virgül geçen bir değer geri okumada ikiye bölünür. Alan eşlemesinin nasıl belgelendiğini ve hangi kuralların önceden yazılması gerektiğini alan eşleme yazısında topladık.

Çift yönde çakışmayı kim kazanır?

Çift yönlü senkron isteyen ekiplerin çoğu aslında çift yönlü veri istemez; iki farklı ekibin iki farklı alanı yönetmesini ister. Bu ayrım kurtarıcıdır. Çakışmayı kayıt düzeyinde değil alan düzeyinde çözün: telefon ve adres CRM'e aittir, kampanya etiketi ve segment tabloya. Her alanın tek bir sahibi olduğunda "son yazan kazanır" kuralına hiç ihtiyaç kalmaz, çünkü aynı alana iki taraf yazmaz.

İnsanların ve robotların aynı sekmeye yazdığı her tablo, er ya da geç birinin çalışmasını kimse fark etmeden siler.

Alan sahipliği kurulamıyorsa, en azından bir zaman damgası ve bir "kim değiştirdi" sütunu tutun; çakışma çözümünü bu iki sütun üzerinden yapın. Ve tabloya yazılan her güncellemeyi üzerine yazmak yerine önce farkı gösterin: senkronun kaç alanı değiştireceğini yazmadan önce bir sekmeye dökmesi, ilk kurulumda yapılan en faydalı yatırımdır. İki yönlü senkronun genel mantığını ve çakışma kurallarını iki yönlü veri senkronizasyonu yazısında ayrıntılı anlatıyoruz.

Ne sıklıkta senkronlamalı?

Sezgi "ne kadar sık o kadar iyi" der. Tablolarda bu sezgi yanlıştır. Google Sheets'in bir "satır tamamlandı" olayı yoktur; kullanıcı yazarken hücreler tek tek kaydedilir. Beş dakikada bir çalışan bir senkron, insanın henüz yarısını doldurduğu satırı okur ve CRM'e adı olan ama telefonu olmayan bir kayıt açar. Ertesi tazelemede o kayıt güncellenir, ama arada birine atanmış ve birine bildirim gitmiştir.

Çözüm açık bir onay sinyalidir. Tabloya bir durum sütunu koyun ve senkronun yalnızca "Hazır" işaretli satırları okumasını sağlayın. Böylece sıklık meselesi büyük ölçüde önemsizleşir: saatte bir çalışan bir akış bile, insan onayı olmadan hiçbir yarım satıra dokunmaz. Sıklık kararını verirken ayrıca kota sınırlarını gözetin; hem tablo tarafı hem CRM tarafı belirli bir çağrı sayısından sonra istekleri yavaşlatır ve gece yarısı sessizce kuyruğa giren bir senkron, sabaha hâlâ bitmemiş olabilir. Zamanlayıcı ve tetikleyici kuran platformların karşılaştırmasını Zapier ve Make karşılaştırması yazısında bulabilirsiniz.

Tabloyu bir arayüz sözleşmesine dönüştürmek

Bir tabloyu makineye açtığınız anda o dosya artık bir belge değil, bir arayüzdür. Arayüzlerin sözleşmesi olur ve sözleşme yazılmadığında, birinin araya eklediği boş satır bütün akışı durdurur. Aşağıdaki yedi kural, senkronlanan tabloların büyük çoğunluğunu ayakta tutar.

• Tek başlık satırı: Başlıklar birinci satırda, tek satır hâlinde ve birleştirilmiş hücre olmadan durmalıdır; iki satırlık başlık, çoğu bağlayıcı için okunamayan bir tablodur.
• Sütun adları değişmez: Ekranda görünen ad değişecekse bile eşleme, sütun adına değil sabit bir teknik ada bağlanmalıdır; "Telefon" sütununu "Cep" yapmak sessiz bir kesintidir.
• Boş satır yok: Görsel ayırıcı olarak bırakılan boş satır, çoğu okuyucu için verinin bittiği yerdir ve altındaki her şey görünmez olur.
• Seçenek sütunlarında veri doğrulama: Serbest metin girilen bir durum sütunu, üç ay içinde kaçınılmaz olarak yedi farklı yazım biçimine ulaşır.
• Kimlik sütunu korumalı: Kayıt kimliğini taşıyan sütun düzenlemeye kapatılmalı, sıralama yaparken satırla birlikte taşındığından emin olunmalıdır.
• Formül yok, en azından ham sekmede: Senkronun yazdığı alana konan bir formül ilk yazmada silinir; hesaplamalar ayrı bir sekmede yaşamalıdır.
• Sabit sütun sırası: Sütun eklemek gerektiğinde sona ekleyin; araya eklenen bir sütun, konuma göre çalışan her eşlemeyi bir hücre kaydırır.

Ham sekme, görünüm sekmesi, hata sekmesi

Bu kuralların hepsini tek hamlede uygulamanın yolu, dosyayı üç sekmeye bölmektir. Ham sekmeye yalnızca senkron yazar ve insanlar oraya dokunmaz. Görünüm sekmesi ham veriyi formüllerle çeker, biçimlendirir, pivotu besler; insanlar burada çalışır ve buraya yazdıkları hiçbir şey geri gitmez. Hata sekmesine ise işlenemeyen satırlar sebebiyle birlikte düşer: eşleşmeyen kimlik, geçersiz seçenek değeri, zorunlu alanı boş satır. Bu üçlü, "tabloyu kim bozdu" sorusunu ortadan kaldırır çünkü insan ile makinenin yazdığı yerler artık aynı değildir.

Paylaşılan tablo aynı zamanda kalıcı bir dışa aktarımdır

Bir CRM'de bir kullanıcının yetkisini kaldırdığınızda erişimi biter. Bir tabloda erişimi kaldırdığınızda, o kişinin daha önce aldığı kopya yerinde durmaya devam eder. Müşteri listesini senkronlayan bir dosya, bağlantıya sahip herkese açık bırakıldığında ya da bir kez indirildiğinde, geri alınamayan bir dışa aktarım hâline gelir. Bu, teknik değil idari bir risktir ve teknik önlemle tam olarak kapanmaz.

Pratik yaklaşım üç adımdır. Senkronlanan dosyalarda paylaşımı kişi bazında verin, bağlantıyla erişimi kapatın ve indirme ile kopyalamayı kısıtlayın. Tabloya yalnızca ihtiyaç duyulan sütunları taşıyın; kimlik numarası, tam adres ve yazışma geçmişi çoğu rapor için gereksizdir. Bağlantıyı kuran hesabın yetkisini de dar tutun: senkron, o hesabın gördüğü her şeyi görebilir. Google tarafındaki hesap, takvim ve dosya bağlantılarının nasıl kurulduğunu CRM-Google entegrasyonu yazısında ele alıyoruz.

Bağlantı koptuğunda önce siz haberdar olun

Senkronların çoğu gürültüyle değil sessizce ölür. Yetki süresi dolar, biri dosyayı başka bir klasöre taşır, bir sütun adı değişir; akış çalışmaya devam eder ama hiçbir satır işlemez. Bunu fark etmenin en pratik yolu, tabloya görünür bir sağlık göstergesi koymaktır: son başarılı senkron zamanını yazan tek bir hücre. Dosyayı açan herkes tarihin dün değil geçen çarşamba olduğunu bir bakışta görür.

İkinci kontrol satır sayısıdır. Her çalışmada işlenen satır sayısını bir yere yazın; sayı sıfıra düştüğünde ya da beklenmedik biçimde ikiye katlandığında haber verecek basit bir eşik kurun. Üçüncüsü hata sekmesinin dolmasıdır: hata sekmesi sessizce dolan bir kuyruksa kimse bakmaz, dolduğunda bir bildirim gitmelidir. Bağlantı sağlığını izlemenin genel yöntemlerini entegrasyon izleme yazısında, kod yazmadan kurulan bağlantı seçeneklerini ise CRM entegrasyonları yazısında bulabilirsiniz.

Ne zaman senkron yerine tamamen taşımalı?

Burada yaygın tavsiyenin sınırını söylemek gerekir. Senkron, iki sistemin de kalıcı olarak var olacağı durumlar için doğru cevaptır. Tablo bir sürecin gerçek merkeziyse — sipariş takibi orada yapılıyor, kim ne yaptı orada yazıyor, karar orada veriliyorsa — senkron kurmak o düzensizliği kalıcı hale getirir ve üstüne bir de bakım yükü ekler.

Ayırt etmenin basit bir testi vardır: tabloyu bir hafta boyunca salt okunur yapsanız iş durur mu? Duruyorsa orası bir sistemdir ve taşınması gerekir, senkronlanması değil. Durmuyorsa tablo gerçekten bir uç noktadır ve senkron yerinde bir çözümdür. Süreci tamamen taşımaya karar verdiyseniz, aşama aşama nasıl ilerleneceğini Excel'den CRM'e geçiş yazısında adım adım anlatıyoruz.

Yaygın hatalar ve iki haftalık başlangıç planı

En sık görülen dört hata şunlardır. Birincisi, kayıt kimliği taşımadan içe aktarım kurmak; sonuç, aynı müşterinin dört kaydıdır. İkincisi, insanların ve senkronun aynı sekmeye yazması. Üçüncüsü, hata satırlarını yok saymak: işlenemeyen satırlar bir yere düşmüyorsa, senkron her çalıştığında sessizce veri kaybediyorsunuz demektir. Dördüncüsü, tabloyu yedek sanmaktır; senkronlanan bir dosya yedek değildir, çünkü hatalı bir silme işlemi tabloya da aynı hızla yansır.

Başlamak için iki haftalık bir plan yeterlidir. İlk hafta yalnızca tek yönlü çalışın: CRM'den tabloya, kimlik sütunu dahil, günde bir kez. Bu bir hafta boyunca kimsenin tabloyu düzenlemediğinden emin olun ve ham sekme ile görünüm sekmesini ayırın. İkinci hafta ters yönü açın ama sadece "Hazır" işaretli satırlar için ve yalnızca iki üç alanla. Hata sekmesini kurun, son senkron zamanı hücresini ekleyin ve iki hafta sonunda hangi satırların neden hata verdiğine bakın; o liste, kalıcı kuralınızı size zaten yazmış olur.

Tabloyu tamamen bırakmak zorunda değilsiniz; onu doğru yere koymak yeterli. Kayıtların, alan tanımlarının, içe aktarım kurallarının ve raporların aynı sistemde durması, tablo trafiğini kendiliğinden azaltır. Rocketly'de veri içe aktarımı, özel alanlar, iş akışı kuralları ve raporlar tek yerde çalışıyor; ücretsiz hesap açarak kendi senkron akışınızı kurup deneyebilirsiniz.