Bir satış ekibinin CRM’i genellikle iki durumdan birindedir: ya güncel ama elle güncellendiği için sürekli gecikmeli, ya da güncel değil çünkü kimsenin girecek vakti yok. Aradaki fark çoğu zaman bir insanın disiplini değil, bir borunun (pipeline) var olup olmadığıdır — lead geldiği anda sistemin kendi kendine kaydettiği, doğru kişiye bildirdiği ve zamanı geldiğinde hatırlattığı bir boru.

n8n satış otomasyonu, bu boruyu açık kaynak bir otomasyon motoruyla kurmak demek. Bu yazı, n8n’in genel ne olduğuyla veya nasıl kurulacağıyla ilgilenmiyor; doğrudan satış sürecine özel iş akışlarına iniyor: yeni bir lead geldiğinde CRM’e otomatik kayıt nasıl atılır, WhatsApp veya e-posta bildirimi nasıl tetiklenir, bir formdan gelen talep CRM’den geçip Slack’e nasıl düşer, teklif durumu değiştiğinde hatırlatma nasıl otomatikleşir. Her senaryoda gerçek node yapılandırmalarını ve mantığı adım adım göreceksiniz.

Kapsam notu: n8n’in Docker ile kurulumu, self-hosted/cloud kararı, domain ve SSL ayarları için n8n kurulumu rehberimize bakın — burada teknik altyapıya girmiyoruz. n8n danışmanlık sürecinin nasıl işlediği, hangi süreçlerin otomatikleştirilmemesi gerektiği için n8n otomasyon danışmanlığı yazımız var. Platform seçimiyle ilgili genel karşılaştırma için Make vs n8n vs Zapier rehberine, satış otomasyonunun platformdan bağımsız stratejik çerçevesi için satış otomasyonu nedir, nasıl kurulur yazısına yönlenebilirsiniz. Bu yazı hepsinin n8n’e özel uygulama katmanıdır.

Neden Satış Süreçleri İçin Özellikle n8n?

Satış süreçlerinin ortak özelliği, birden fazla sistemin aynı anda konuşması gerekmesidir: form veya reklam aracı, CRM, mesajlaşma kanalı (WhatsApp, e-posta, SMS), takım içi bildirim aracı (Slack, Telegram) ve bazen muhasebe. Bu kadar çok sistemi birbirine bağlarken iki şey kritikleşir: koşullu mantığın esnekliği (lead kaynağına, değerine, saatine göre farklı davranmak) ve hata durumunda sessizce veri kaybetmemek.

n8n bu iki noktada satış otomasyonuna özellikle uygun düşüyor:

Görsel ama kod seviyesinde esnek. Basit akışlar sürükle-bırak ile kurulur; lead skorlama gibi özel mantık gerektiğinde bir Function node içine JavaScript yazılabilir. Zapier’de bu genelde ek ücretli bir “Code” adımı, Make’te de benzer bir sınırlama var.
Dallanma ve birleştirme yerleşik. Bir lead’in kaynağına göre (Meta reklamı mı, web formu mu, WhatsApp mı) farklı CRM alanlarına yazılması, farklı bildirim kanallarına gitmesi tek bir workflow içinde IF/Switch node’larıyla doğal şekilde kurulur.
Hata yakalama ve yeniden deneme birinci sınıf vatandaş. Bir lead CRM’e yazılamadığında sessizce kaybolmak yerine ayrı bir hata workflow’una düşürülebilir — satış verisinde bu, gelir kaybı demektir.
Çalıştırma bazlı değil. Yoğun kampanya dönemlerinde lead hacmi arttığında maliyet aniden büyümez (self-hosted’da); Zapier/Make’in “task” bazlı fiyatlandırması yoğun dönemlerde sürpriz fatura üretebilir.

Bunun karşılığı da var: n8n’in kurulumu ve bakımı Zapier’e göre daha fazla teknik sorumluluk ister. Aşağıdaki tablo, sadece satış otomasyonu bağlamında kısa bir özet veriyor — platformların genel karşılaştırması için ayrı yazımıza bakabilirsiniz.

Kriter	n8n	Make	Zapier
Karmaşık koşullu lead yönlendirme	Function node ile tam esnek	Router + filtrelerle mümkün, sınırlı	Genelde ek paid app gerekir
Yoğun kampanya döneminde maliyet	Self-hosted’da sabit (altyapı maliyeti)	İşlem bazlı, hacimle artar	İşlem bazlı, hacimle artar
Kurulum/bakım yükü	Yüksek (self-hosted ise)	Düşük	Düşük
CRM’e özel API alanı yazma	HTTP Request node ile tam kontrol	Genelde modül üzerinden, esneklik sınırlı	Genelde modül üzerinden, esneklik sınırlı
Hata yönetimi derinliği	Ayrı error workflow, tam kontrol	Var, orta düzey	Var, temel düzey

Kısa cevap: lead hacminiz yüksek, CRM’iniz standart dışı alanlar kullanıyor veya bütçeniz sabit maliyeti tercih ediyorsa n8n öne çıkar. Basit, düşük hacimli ve hızlı kurulmak istiyorsanız Zapier/Make daha az sürtünmeli olabilir. Detaylı karar çerçevesi için Make vs n8n vs Zapier karşılaştırmasına bakın.

Bir başka pratik ayrım, ekibin büyüme hızıyla ilgilidir. Bir satış ekibi altı ayda ikiye katlanacaksa, lead hacmi ve bağlanacak sistem sayısı da katlanır; işlem bazlı fiyatlandırmayla başlayan bir kurulum, bu büyümede fatura tarafında sürpriz yapabilir. n8n’de self-hosted kurulum bu büyümeyi altyapı maliyeti sabit kalarak karşılar — tabii bakım sorumluluğunu üstlenecek biri olması şartıyla. Küçük, sabit hacimli ve büyüme planı olmayan bir ekip için bu avantaj daha az anlam ifade eder; orada kurulum kolaylığı öne çıkar.

Satış Otomasyon Mimarisinin Dört Katmanı

n8n ile kurulan bir satış otomasyonu, altta yatan tek bir mimariyi tekrar tekrar kullanır:

Tetikleyici (Trigger): Bir şey oldu — form dolduruldu, WhatsApp mesajı geldi, CRM’de bir alan değişti, belirli bir zaman geçti.
Zenginleştirme ve doğrulama: Gelen veri temizlenir, eksik alanlar tamamlanır, yinelenen kayıt kontrolü yapılır.
Aksiyon: CRM’e yazma, bildirim gönderme, görev atama.
Hata ve izleme: Aksiyon başarısız olursa ne olacağı, kimin haberdar edileceği.

Aşağıdaki dört iş akışı bu mimariyi somut senaryolara uyguluyor. Her birinde n8n’de kullanılacak node tiplerini ve mantığı görebilirsiniz; tam ekran görüntüsü değil, kopyalayıp kendi ortamınıza uyarlayabileceğiniz bir iskelet sunuyoruz.

Dört katmanı ayrı ayrı düşünmenin pratik bir faydası var: bir sorun çıktığında (“bildirim gitmedi”, “CRM’de kayıt yok”) hangi katmanda arandığını hızla daraltabilirsiniz. Tetikleyici katmanında sorun genelde “veri hiç gelmedi” (webhook URL’si yanlış, form entegrasyonu bozuk) şeklinde görünür; zenginleştirme katmanında “veri geldi ama eksik/hatalı” (Set node’unda yanlış alan eşlemesi); aksiyon katmanında “veri doğru ama sisteme yazılamadı” (API kimlik bilgisi süresi dolmuş, yetki hatası); izleme katmanında ise “her şey çalıştı ama kimse bilmiyor” (bildirim adımı unutulmuş). Bu dörtlü ayrım, otomasyon büyüdükçe hata ayıklamayı düzenli tutan en basit zihinsel modeldir.

İş Akışı 1: Yeni Lead Geldiğinde CRM’e Otomatik Kayıt

En temel ve en yüksek getirili akış budur: bir lead nereden gelirse gelsin (form, reklam, WhatsApp), CRM’de saniyeler içinde bir kayıt olarak belirir.

Node zinciri:

1. Webhook / Form Trigger  → lead verisini yakalar
2. Set (Edit Fields)       → alanları CRM'in beklediği formata dönüştürür
3. HTTP Request (GET)      → CRM'de aynı telefon/e-posta var mı sorgular
4. IF                      → kayıt var mı yok mu dallanır
5a. HTTP Request (POST)    → yoksa yeni kayıt oluşturur
5b. HTTP Request (PATCH)   → varsa mevcut kaydı günceller
6. NoOp / Log              → sonucu izleme tablosuna yazar

Set node’unda alan eşleme örneği (form alanlarını CRM’in beklediği isimlere çevirmek için):

{
  "full_name": "={{$json.ad_soyad}}",
  "phone": "={{$json.telefon.replace(/\\D/g,'')}}",
  "email": "={{$json.eposta.toLowerCase()}}",
  "source": "={{$json.form_kaynagi || 'web-form'}}",
  "created_at": "={{$now.toISO()}}"
}

Yinelenen kayıt kontrolü kritik bir ayrıntıdır: aynı kişi formu iki kez doldurursa CRM’de iki ayrı kayıt açılmamalı, mevcut kayıt güncellenmeli ve satış temsilcisine “bu kişi tekrar başvurdu” bilgisi düşmelidir. Bu yüzden 3. adımdaki sorgu — telefon numarasına göre arama — atlanmaması gereken bir kontrol noktasıdır; atlandığında CRM birkaç ay içinde aynı kişiye ait beş altı kayıtla dolar ve raporlama anlamsızlaşır.

IF node’unun koşulu tipik olarak şu şekilde kurulur: CRM sorgusu (adım 3) bir sonuç döndürdüyse “var” dalına, boş dizi döndürdüyse “yok” dalına gider. Her iki dalın sonunda da bir bildirim tetiklenmesi (aşağıdaki İş Akışı 2 ile zincirlenir) akışın satış ekibine değer üretmesini sağlar — CRM’e sessizce yazan ama kimseye haber vermeyen bir otomasyon, aslında yarım bir otomasyondur.

İş Akışı 2: WhatsApp / E-posta Bildirim Tetikleme

Lead CRM’e düştüğü anda, ilgili satış temsilcisine veya genel havuza bildirim gitmesi gerekir. n8n’de bu, kanal seçimine göre dallanan bir Switch node ile kurulur.

Node zinciri:

1. (Önceki akıştan gelen "lead kaydedildi" tetikleyicisi)
2. Switch                    → lead kaynağına/önceliğine göre dallanır
3a. WhatsApp Business API    → yüksek öncelikli lead için anlık WhatsApp mesajı
3b. Send Email (SMTP)        → standart öncelikli lead için e-posta
4. HTTP Request              → CRM'de "bildirim gönderildi" alanını günceller

Switch node koşul örneği:

{
  "rules": [
    { "condition": "={{$json.lead_value}} >= 5000", "output": "whatsapp_oncelikli" },
    { "condition": "={{$json.source}} === 'whatsapp'", "output": "whatsapp_standart" },
    { "condition": "true", "output": "email_standart" }
  ]
}

WhatsApp Business API node parametreleri (satış temsilcisine giden iç bildirim için — müşteriye değil, ekibe):

{
  "to": "={{$json.temsilci_telefon}}",
  "type": "template",
  "template_name": "yeni_lead_bildirimi",
  "variables": [
    "={{$json.full_name}}",
    "={{$json.phone}}",
    "={{$json.source}}"
  ]
}

Burada iki farklı bildirim akışını birbirinden ayırmak önemlidir: ekip içi bildirim (bu iş akışının konusu — “sana yeni bir lead atandı”) ile müşteriye giden takip mesajları (teklif hatırlatma, hoş geldin mesajı gibi) farklı amaçlara hizmet eder. Müşteriye giden WhatsApp takip mesajı dizileri ve huni aşamasına göre tetiklenen şablonlar için ayrı, derinlemesine bir kaynağımız var: WhatsApp satış otomasyonu. Bu yazıda WhatsApp node’unu yalnızca CRM-içi bildirim bağlamında ele alıyoruz.

E-posta dalında Send Email node’u SMTP kimlik bilgileriyle veya SendGrid/Mailgun gibi bir servisin API’siyle çalışabilir; n8n her ikisini de destekler. Kritik nokta, e-posta gönderiminin başarısız olduğu durumda (SMTP zaman aşımı, geçersiz adres) akışın sessizce durmaması — bu konuyu birazdan Hata Yönetimi bölümünde ele alıyoruz.

İş Akışı 3: Form → CRM → Slack Zinciri

Küçük ve orta ölçekli satış ekiplerinde en sık istenen zincir budur: web sitesindeki bir form dolduğunda, bilgi hem CRM’e düşsün hem de ekibin Slack (veya Telegram) kanalına anlık olarak yansısın — kimse CRM’i sürekli açık tutmak zorunda kalmasın.

Node zinciri:

1. Webhook (form_submit)   → form verisini yakalar
2. Function                → basit lead skoru hesaplar
3. HTTP Request (POST)     → CRM'e kaydı oluşturur
4. Slack (postMessage)     → skorla birlikte kanala bildirim düşer
5. Error Trigger (ayrı workflow) → 3. adım başarısız olursa devreye girer

Function node içinde basit skorlama mantığı (bu, ayrıntılı lead skorlama modelinin n8n’e uyarlanmış küçük bir örneği — kapsamlı skorlama kriterleri ve dağıtım mantığı için lead takip ve yönetim otomasyonu yazımıza bakabilirsiniz):

const item = items[0].json;
let score = 0;

if (item.butce && item.butce > 10000) score += 30;
if (item.source === 'google-ads') score += 20;
if (item.mesaj && item.mesaj.length > 50) score += 15;
if (item.telefon_dogrulandi) score += 20;

item.lead_score = score;
item.oncelik = score >= 50 ? 'yuksek' : score >= 25 ? 'orta' : 'dusuk';

return [{ json: item }];

Slack bildirim mesajı (öncelik ve skorla birlikte, temsilcinin tek bakışta karar verebilmesi için):

{
  "channel": "#yeni-leadler",
  "text": "Yeni lead: {{$json.full_name}} — Skor: {{$json.lead_score}} ({{$json.oncelik}}) — Kaynak: {{$json.source}} — CRM: {{$json.crm_url}}"
}

Bu zincirin pratikte en çok değer kattığı yer, form-CRM entegrasyonunu tek başına kuran ama bildirim katmanını atlayan işletmelerin durumudur: CRM’e veri düşüyor ama kimse bakmadığı için lead saatlerce bekliyor. Slack (veya Telegram/WhatsApp grup) adımının eklenmesi, ortalama ilk-temas süresini genelde saatlerden dakikalara indiriyor — ve satışta ilk temas hızı, dönüşüm oranını doğrudan etkileyen birkaç değişkenden biri.

Birden fazla kanaldan (WhatsApp, Instagram, form, Messenger) gelen talepleri tek bir CRM akışında birleştirmek isteyen işletmeler için bu zincirin “girdi” tarafı genişler; o senaryoyu ayrıntılı ele alan çok kanallı CRM entegrasyonu rehberimize bakabilirsiniz — orada anlatılan bağlantı yöntemleri, bu n8n akışının Webhook adımına giren farklı kaynaklardır.

İş Akışı 4: Teklif Durumu Değiştiğinde Otomatik Hatırlatma

Satış sürecinin en çok kaçak veren noktası genelde burasıdır: teklif gönderilir, müşteri cevap vermez, kimse hatırlamaz, fırsat sessizce soğur. n8n’de bu, zamanlanmış bir kontrol (polling) veya CRM’in webhook desteği varsa olay bazlı bir tetikleyici ile kurulur.

Node zinciri (polling yöntemi, CRM’de webhook yoksa):

1. Schedule Trigger (her gün 09:00)
2. HTTP Request (GET)        → durumu "teklif gönderildi" olan ve X günden eski kayıtları çeker
3. Split In Batches           → her kayıt için ayrı ayrı işlem yapar
4. IF                         → kaç gün geçtiğine göre dallanır (3 gün / 7 gün / 14 gün)
5a. WhatsApp/Email            → müşteriye nazik hatırlatma
5b. Slack                     → temsilciye "bu fırsat soğuyor" uyarısı
6. HTTP Request (PATCH)       → CRM'de "son_hatirlatma_tarihi" alanını günceller

IF koşulu örneği (kademeli hatırlatma mantığı):

const gunFarki = $json.gun_farki;

if (gunFarki === 3) return { dal: 'ilk_hatirlatma' };
if (gunFarki === 7) return { dal: 'ikinci_hatirlatma' };
if (gunFarki >= 14) return { dal: 'temsilci_uyarisi' };
return { dal: 'bekle' };

Bu akışın en önemli tasarım kararı, hatırlatmanın müşteriye giden nazik bir mesaj ile temsilciye giden bir uyarı arasında ayrım yapmasıdır. İlk birkaç gün müşteriye otomatik mesaj gönderilir (“Merhaba, gönderdiğimiz teklifle ilgili sorunuz varsa yardımcı olmaktan memnuniyet duyarız”); belirli bir eşikten sonra (örneğin 14 gün) artık müşteriye değil, temsilciye “bu fırsatı elle kontrol et” uyarısı gider — çünkü otomatik mesajların art arda tekrarı müşteride “spam” izlenimi bırakabilir. Bu kademeleme, otomasyonu satış sürecine saygılı hale getiren asıl detaydır.

CRM’de webhook/olay desteği varsa (durum alanı değiştiğinde n8n’e bildirim gönderme), yukarıdaki 1-2. adımlar bir Webhook Trigger ile değiştirilebilir ve gecikme sıfıra iner — polling yönteminde en kötü durumda bir günlük gecikme olabileceği unutulmamalı.

Hata Yönetimi: Sessizce Kaybolan Lead Olmasın

Satış otomasyonunda bir workflow’un başarısız olması, bir lead’in veya bir hatırlatmanın kaybolması demektir — bu da doğrudan gelir kaybıdır. n8n’de bu riski azaltan üç mekanizma:

Error Workflow ataması. Her ana workflow’a bir “hata olursa şuraya git” workflow’u bağlanır. Bu hata workflow’u en az şunu yapmalı: hatayı bir log tablosuna yazmak ve sorumlu kişiye (Slack/e-posta) bildirmek.
Retry (yeniden deneme) ayarı. HTTP Request node’larında “Retry On Fail” açılarak geçici ağ hatalarında (CRM API’sinin bir anlık yanıt vermemesi gibi) otomatik yeniden deneme yapılır — genelde 3 deneme, artan bekleme süresiyle.
Dead-letter kaydı. Yeniden denemelerin hepsi başarısız olursa, kayıt işlenemeyenler listesine düşer ve haftalık olarak elle gözden geçirilir; bu liste boş kalmıyorsa bir yerde yapısal bir sorun var demektir (API anahtarı süresi dolmuş, alan adı değişmiş gibi).

Bu üç katman kurulmadan devreye alınan bir satış otomasyonu, “çalışıyor gibi görünen ama arada sessizce veri kaybeden” bir sisteme dönüşür — ve bu tür arızalar genelde aylar sonra, “neden şu ay lead sayımız düşük görünüyor” sorusuyla fark edilir.

Vaka Kurgusu: Bir Emlak Danışmanlığı Ofisinin Lead Kaybını Durdurması

On iki kişilik bir emlak danışmanlığı ofisi düşünelim. Web sitesi formu, Meta reklamları ve WhatsApp’tan günde ortalama 35-40 lead geliyor; hepsi elle bir Excel tablosuna ve ayrı ayrı CRM’e giriliyor. Ofis sahibi, ay sonu raporunda CRM’deki kayıt sayısının Excel’dekinden belirgin şekilde az olduğunu fark ediyor — aradaki fark, kaydı elle girmeyi unutulan leadler.

Kurulan n8n akışları: form ve WhatsApp’tan gelen her talep doğrudan Webhook ile yakalanıp CRM’e yazılıyor (İş Akışı 1), aynı anda ilgili bölgeden sorumlu danışmana WhatsApp bildirimi gidiyor (İş Akışı 2), tüm ekip Slack kanalından günlük özeti görüyor (İş Akışı 3’ün genişletilmiş hali) ve gösterim sonrası “teklif bekliyor” durumundaki fırsatlar için 3-7-14 günlük kademeli hatırlatma çalışıyor (İş Akışı 4).

Uygulama penceresi: Kurulum ve test iki hafta sürüyor; ilk hafta yalnızca form ve WhatsApp akışları canlıya alınıyor, ikinci hafta hatırlatma zinciri ekleniyor. Test aşamasında gerçek müşteri verisi yerine ayrı bir test CRM alanı kullanılıyor.

Sonuç penceresi (ilk 60 gün): Excel-CRM arasındaki kayıt farkı sıfırlanıyor çünkü artık elle giriş yok. Danışmanların ortalama ilk-temas süresi belirgin şekilde kısalıyor çünkü WhatsApp bildirimi anlık geliyor. “Teklif gönderildi” durumunda unutulan fırsat sayısı azalıyor çünkü hatırlatma zinciri artık insan hafızasına bağlı değil. Ofis sahibinin gözlemlediği en somut değişiklik, ay sonu raporunun artık “kaç lead kaybettik, bilmiyoruz” değil “kaç lead’i ne aşamada kaybettik, biliyoruz” sorusuna dönmesi — çünkü her adım artık CRM’de zaman damgalı olarak görünüyor.

Beklenmeyen bir yan fayda da ortaya çıkıyor: danışmanlar arasında lead dağılımının adaletsiz olduğuna dair eski şikayetler azalıyor, çünkü Switch node’undaki bölge/öncelik mantığı herkese aynı kuralı uyguluyor — önceden “bana hep zayıf leadler düşüyor” algısı, artık kayıt altına alınmış ve tartışılabilir bir kurala dayanıyor. Kurulumun ikinci ayında ofis, hatırlatma eşiklerini de gözden geçiriyor: ilk kurguda 3-7-14 gün olan aralık, gösterim sonrası kararların genelde daha hızlı alındığı gözlemiyle 2-5-10 güne çekiliyor — bu da izleme rutininin sadece hata yakalamak için değil, akışı canlı veriyle sürekli iyileştirmek için kullanıldığını gösteriyor.

(Vaka temsilidir.)

Sık Yapılan Hatalar

Yinelenen kayıt kontrolünü atlamak. CRM sorgusu olmadan doğrudan yeni kayıt oluşturmak, aynı kişi için birden fazla kart açılmasına ve raporların yanılmasına yol açar.
Tüm bildirimleri tek kanaldan göndermek. Yalnızca e-posta ile bildirim yapmak, yoğun saatlerde e-postanın gözden kaçmasına ve leadin saatlerce beklemesine neden olur; öncelikli leadler için anlık kanal (WhatsApp/Slack) şart.
Hata workflow’u kurmadan canlıya almak. İlk API hatasında akış sessizce durur ve kimse fark etmeden günler geçebilir; error workflow ve bildirim, ilk günden kurulmalı.
Hatırlatma sıklığını abartmak. Müşteriye günlük otomatik mesaj göndermek rahatsız edici bulunur ve marka algısını zedeler; kademeli, azalan sıklıkta bir hatırlatma mantığı (3-7-14 gün gibi) daha sağlıklıdır.
Lead skorlama mantığını CRM ile n8n arasında ikiye bölmek. Skor hem CRM’de hem n8n’de farklı kurallarla hesaplanırsa iki sistem zamanla birbirinden sapar; tek kaynak (genelde n8n Function node’u) belirlenip CRM sadece sonucu göstermelidir.
Test ortamı kullanmadan canlı veri üzerinde deneme yapmak. Yanlış yapılandırılmış bir Switch node, gerçek müşterilere yanlış mesaj gitmesine yol açabilir; her yeni akış önce test CRM alanı ve test telefon numarasıyla doğrulanmalı.
Webhook URL’lerini güvensiz bırakmak. Kimlik doğrulaması olmayan bir Webhook node, dışarıdan tahmin edilip sahte lead kayıtlarıyla doldurulabilir; en azından basit bir token kontrolü (header’da gizli bir anahtar) eklenmelidir.

Karar Çerçevesi: Hangi İş Akışıyla Başlamalı?

Dört akışın tamamını aynı anda kurmaya çalışmak, sık yapılan hatalardan biri olan “test ortamsız devreye alma” riskini büyütür. Aşamalı bir sıralama önerilir:

Aşama	Kurulacak akış	Beklenen getiri
1	Lead → CRM otomatik kayıt (İş Akışı 1)	Elle giriş hatasının ve unutmanın sıfırlanması
2	Bildirim tetikleme (İş Akışı 2)	İlk temas süresinin kısalması
3	Form-CRM-Slack zinciri (İş Akışı 3)	Ekip görünürlüğü, skorlu önceliklendirme
4	Teklif hatırlatma (İş Akışı 4)	Soğuyan fırsatların azalması

Her aşama canlıya alındıktan sonra en az bir hafta izlenip hata oranı düşükse bir sonraki aşamaya geçilmesi, “tek dev workflow” tuzağına düşmeden ilerlemenin en güvenli yoludur.

İzleme ve Bakım: Otomasyonun Sağlığını Nasıl Takip Edersiniz

Bir satış otomasyonu kurulduktan sonra “kur ve unut” mantığıyla bırakılırsa, sessizce bozulmaya başladığı an fark edilmez — ve fark edildiğinde genelde haftalarca birikmiş kaybedilmiş lead anlamına gelir. Bu yüzden kurulumun bir parçası, akışların sağlığını düzenli olarak gözden geçirecek basit bir izleme rutinidir.

Haftalık kontrol listesi:

Dead-letter (işlenemeyen kayıtlar) listesi boş mu? Boş değilse, hangi node’da ve neden hata alındığı incelenmeli.
CRM’e yazılan kayıt sayısı, form/reklam/WhatsApp’tan gelen ham lead sayısıyla eşleşiyor mu? Belirgin bir fark varsa bir yerde kayıp var demektir.
Bildirim gönderim başarı oranı (WhatsApp/e-posta/Slack) yüzde kaç? API kotası dolmuşsa veya bir anahtar süresi geçmişse bu oran düşer.
Hatırlatma zincirinin son çalıştığı tarih, Schedule Trigger’ın beklenen sıklığıyla uyumlu mu?

n8n’in kendi çalıştırma geçmişi (execution log) bu kontrollerin çoğu için yeterli veri sağlar; ayrıca her ana akışın sonuna, çalıştırma özetini basit bir tabloya (Google Sheets veya CRM’in kendi içinde bir “otomasyon logu” sekmesi) yazan bir adım eklemek, teknik olmayan bir ekip üyesinin bile haftalık kontrolü yapabilmesini sağlar.

Aylık gözden geçirme ise daha stratejik bir sorudur: lead skorlama eşikleri hâlâ doğru mu (örneğin “yüksek öncelik” eşiği kampanya bütçesi değiştiğinde güncellenmiş mi), hatırlatma sıklığı müşteri şikayetine yol açıyor mu, CRM’in API’si bir güncelleme geçirip alan isimleri değişti mi. Bu tür sorular otomasyonun ilk kurulumundan aylar sonra bile ortaya çıkabilir; bu yüzden bakımı bir kerelik proje değil, sürekli bir sorumluluk olarak planlamak gerekir. Bu sorumluluğun içeride mi yoksa bir danışmanlık ilişkisiyle mi yürütüleceği, n8n otomasyon danışmanlığı yazımızda ayrıntılı ele alınıyor.

Ölçeklenme işareti: Lead hacmi arttıkça (örneğin kampanya dönemlerinde günlük yüzlerce lead), Schedule Trigger tabanlı polling akışlarının sorgu aralığı darboğaz oluşturabilir; bu noktada n8n’in queue mode ile çalışan bir kurulumuna geçmek gerekebilir. Bu, saf teknik bir altyapı kararıdır ve kurulum rehberimizde ayrıntılı işleniyor.

Bir diğer ölçeklenme işareti, akış sayısının kendisidir. İlk kurulumda dört akışla başlayan bir işletme, birkaç ay içinde bölge bazlı yönlendirme, kampanya bazlı özel skorlama veya farklı ürün hatları için ayrı zincirler eklemek isteyebilir. Bu noktada akışları tek tek büyütmek yerine ortak parçaları (örneğin CRM’e yazma adımı) ayrı bir alt-workflow’a taşıyıp diğer akışlardan çağırmak, bakımı önemli ölçüde kolaylaştırır — n8n’de bu “Execute Workflow” node’uyla yapılır ve her ana akışın kendi mantığını tekrar tekrar kopyalamasının önüne geçer.

Sık Sorulan Sorular

n8n ile satış otomasyonu kurmak için CRM’imin API’sinin olması şart mı?

Evet, HTTP Request node’unun çalışabilmesi için CRM’in bir API sunması gerekir — REST tabanlı olması yeterlidir, özel bir n8n entegrasyonuna ihtiyaç yok. Çoğu güncel CRM (yerli ve yabancı) API sunuyor; API dokümantasyonu olmayan çok eski veya kapalı sistemlerde n8n’in HTTP Request node’u çalışamaz, o durumda ya CRM değişikliği ya da ara katman (örneğin bir e-tablo) gerekir. Kurulum öncesi CRM’inizin API dokümantasyonunu kontrol etmeniz ilk adım olmalı.

Satış otomasyonu için n8n mi Make mi tercih edilmeli?

Lead hacminiz yüksekse, CRM’inizde standart dışı alanlar veya özel skorlama mantığı varsa ve teknik kapasiteniz (kendi ekibiniz veya danışman) mevcutsa n8n avantajlıdır — hem esneklik hem de yoğun dönemde sabit maliyet sağlar. Düşük-orta hacim, hızlı kurulum önceliği ve teknik bakım isteksizliği varsa Make (veya Zapier) daha az sürtünmeli bir başlangıç olur. İki platformun fiyatlandırma mantığı, öğrenme eğrisi ve yapay zekâ yetenekleri gibi boyutlarıyla ayrıntılı karşılaştırma için Make vs n8n vs Zapier rehberimize bakabilirsiniz.

n8n lead takip sistemi kurmak ne kadar sürer?

Bu yazıdaki dört iş akışının tek tek kurulumu, CRM’in API karmaşıklığına bağlı olarak akış başına birkaç günden bir haftaya kadar sürebilir. Aşamalı yaklaşımla (önce lead-CRM kaydı, sonra bildirim, sonra Slack zinciri, en son hatırlatma) toplam süreç genelde birkaç haftaya yayılır; bunun nedeni hız değil, her aşamanın canlıda bir süre izlenip doğrulanması gerekliliğidir. Acele edilen kurulumlar, sık yapılan hatalar bölümünde sayılan sorunları büyütür.

CRM’de webhook desteği yoksa n8n’e nasıl bağlanır?

Webhook desteği olmayan CRM’lerde polling yöntemi kullanılır: n8n’de bir Schedule Trigger belirli aralıklarla (örneğin her 15 dakikada bir) CRM API’sini sorgular ve son sorgudan bu yana değişen kayıtları yakalar. Bu yöntem webhook’a göre bir miktar gecikme (sorgu aralığı kadar) getirir ama pratikte çoğu satış senaryosu için yeterlidir; teklif hatırlatma gibi günlük kontrol yeten akışlarda zaten polling tercih edilir.

Lead skorlama mantığını n8n’de mi CRM’de mi tutmalıyım?

Genel öneri, skorlama mantığının tek bir yerde, tercihen n8n’in Function node’unda tutulmasıdır — çünkü orada kod olarak versiyonlanabilir, test edilebilir ve değiştirilmesi kolaydır. CRM ise yalnızca hesaplanmış skoru bir alan olarak gösterir. İki sistemde de ayrı ayrı skorlama kuralı tanımlanırsa zamanla ikisi birbirinden sapar ve hangi skorun “doğru” olduğu belirsizleşir. Kapsamlı skorlama kriterleri için lead takip ve yönetim otomasyonu rehberimize bakabilirsiniz.

n8n iş akışı geliştirme hizmeti almak mı, kendim kurmak mı daha mantıklı?

Tek-iki akışlık basit senaryolar (örneğin sadece form-CRM kaydı) için bu yazıdaki node yapılandırmalarını temel alarak kendiniz kurabilirsiniz. Dört akışın tamamının birbirine bağlı, hata yönetimli ve ölçeklenebilir şekilde kurulması — özellikle yüksek lead hacminde — teknik deneyim ister; burada bir n8n iş akışı geliştirme hizmeti süreci hızlandırır ve sık yapılan hataların çoğunu baştan önler. Karar eşiği, kritiklik (satış verisi kaybı kabul edilebilir mi), karmaşıklık (kaç sistem bağlanacak) ve iç kapasitedir.

WhatsApp bildirimlerini n8n üzerinden göndermek için resmi API mi gerekir?

Evet, güvenilir ve ölçeklenebilir bir kurulum için WhatsApp Business API (resmi) kullanılmalıdır; kişisel WhatsApp hesabını otomasyona bağlamaya çalışan yöntemler (resmi olmayan kütüphaneler) hesap askıya alma riski taşır ve ticari kullanımda önerilmez. Resmi API’nin kurulumu ayrı bir onay ve şablon mesaj sürecine tabidir; bu sürecin detayları ve müşteriye giden mesaj dizileri için WhatsApp satış otomasyonu rehberimize bakabilirsiniz.

Teklif hatırlatma akışı müşteriyi rahatsız etmeden nasıl kurulur?

Kademeli ve azalan sıklıkta bir yapı önerilir: ilk hatırlatma birkaç gün sonra nazik bir mesajla, ikinci hatırlatma daha uzun bir aradan sonra, üçüncü eşikten sonra ise müşteriye değil temsilciye uyarı gider. Her hatırlatma mesajının müşteriye “istersen bizi bilgilendirebilirsin, aksi halde rahatsız etmeyeceğiz” gibi bir çıkış kapısı sunması da algıyı olumlu tutar. Günlük tekrarlanan otomatik mesajlar, satış otomasyonunda en çok şikayete yol açan uygulamadır.

Bu iş akışlarını kurduktan sonra CRM değiştirirsem ne olur?

n8n’deki HTTP Request node’ları belirli bir CRM’in API adreslerine ve alan isimlerine göre yapılandırıldığı için CRM değişikliğinde bu node’ların yeniden yapılandırılması gerekir; iş akışının genel mantığı (tetikleyici, dallanma, bildirim sırası) aynı kalır, değişen yalnızca CRM’e bağlanan adımlardır. Bu nedenle akışları kurarken CRM’e özel alan isimlerini mümkün olduğunca en başta (Set node’unda) merkezi hale getirmek, ileride CRM değişse bile değişikliği tek bir noktaya sıkıştırır.

Sonuç

n8n ile kurulan bir satış otomasyonunun özü, dört basit ama birbirine bağlı boru hattıdır: lead geldiğinde kaybolmadan CRM’e düşmesi, doğru kişiye anında haber verilmesi, ekibin ortak görünürlüğe sahip olması ve fırsatların sessizce soğumaması. Her biri tek başına küçük bir workflow; birlikte kurulduklarında satış sürecinin en pahalı sızıntı noktalarını kapatıyorlar.

Kritik olan, dördünü aynı anda ve hatasız kurmaya çalışmak değil, aşamalı ilerlemek ve her aşamada hata yönetimini atlamamaktır — çünkü satış verisinde sessizce kaybolan bir kayıt, fark edilene kadar geçen sürede gerçek bir gelir kaybına dönüşür.

Kendi satış sürecinize özel n8n iş akışlarının kurulmasını istiyorsanız yapay zeka otomasyon hizmetleri sayfasına göz atabilir veya doğrudan iletişime geçebilirsiniz.