Make.com ile Güvenli Otomasyon

Make.com ile kurumsal otomasyon, tekrar eden iş süreçlerini görsel senaryolara taşımak ve her adımı veri doğrulama, hata yönetimi, yetkilendirme ve insan onayı kapılarıyla birlikte tasarlamak demektir. Kurumsal bir kurulumu kişisel bir verimlilik denemesinden ayıran şey, senaryonun sorunsuz günde çalışması değildir; bozulduğunda ne olduğunun bilinmesi, sorumlunun tanımlı olması ve sonucun hedef sistemde doğrulanabilmesidir. Bu rehber Make.com'un tanımından başlar; senaryo mimarisini, otomasyon desenlerini, adım adım tasarım yöntemini, uçtan uca somut bir örneği, güvenlik ve KVKK sorumluluğunu, sık yapılan hataları ve karar tablolarını sırayla ele alır.

Make.com Nedir ve Kurumsal Otomasyon İçin Neden Tercih Edilir?

Make.com, farklı uygulamaları görsel bir kanvas üzerinde birbirine bağlayan bir iş akışı otomasyon platformudur; kurumsal işlerde tercih edilme nedeni, veri akışının her adımının görünür, dallanabilir ve sonradan denetlenebilir olmasıdır. Bir sürecin nerede durduğunu anlamak için kod okumak yerine kanvasta hangi modülün kırmızıya döndüğüne bakarsınız. Bu görünürlük, otomasyonu yazılım ekibinin tekelinden çıkarıp süreç sahibinin de tartışabildiği bir belgeye dönüştürür.

Platformun temel kavramları sadedir. Otomatik iş akışının tamamına senaryo, senaryodaki her uygulama adımına modül denir. Tetikleyici senaryoyu başlatan olaydır; filtre hangi kaydın ilerleyeceğine karar verir; router aynı veriyi koşula göre farklı kollara ayırır; hata işleyici ise bir adım başarısız olduğunda akışın ne yapacağını tanımlar. Kavramların tek tek tanımı ve ilk kurulum için Make.com nedir rehberine bakabilirsiniz; bu sayfa kurumsal ölçekte ne değiştiğine odaklanır.

Kurumsal bağlamda asıl soru "kaç uygulamayı bağlayabiliyorum" değildir. Make'in resmî entegrasyon kataloğu Temmuz 2026 itibarıyla 3.000'den fazla uygulama bağlantısı listeliyor; ancak katalog büyüklüğü bir süreci güvenilir hale getirmez. Kurumsal kurulumda belirleyici olan; hazır bağlantısı olmayan iç sistemlere HTTP modülleriyle erişilebilmesi, aynı olayın iki kez işlenmesinin engellenmesi ve her çalışmanın izlenebilir bir kaydının kalmasıdır.

Kurumsal Otomasyon Neden Teknik Değil Yönetimsel Bir Karardır?

Kurumsal otomasyon yönetimsel bir karardır çünkü bir süreci otomatikleştirdiğinizde yalnızca hızını değil, hata biçimini de değiştirirsiniz. Elle yürüyen bir süreçte hata tek tek ve yavaş oluşur; otomatik bir süreçte aynı hata saatte yüzlerce kez tekrar eder. Bu yüzden karar, hangi aracın kullanılacağından önce hangi riskin kabul edildiği sorusudur.

Pratikte üç yönetimsel soru cevaplanmadan hiçbir senaryo canlıya alınmamalıdır. Birincisi sahiplik: bu akış bozulduğunda kim haberdar olur ve kim düzeltir? İkincisi veri sınırı: hangi alanlar hangi sisteme, hangi hukuki dayanakla gider? Üçüncüsü geri alma: yanlış çalışan bir senaryonun ürettiği kayıtlar nasıl tespit edilip düzeltilir? Bu üç sorunun yazılı cevabı yoksa otomasyon verimlilik değil, gizli bir operasyonel borç üretir.

Yapay zekâ adımları sürece girdiğinde bu sorumluluk daha da belirginleşir. ABD Ulusal Standartlar ve Teknoloji Enstitüsü'nün AI Risk Management Framework yaklaşımı riski dört işlev etrafında yönetmeyi önerir: yönetişim, haritalama, ölçüm ve müdahale. Bu çerçevenin otomasyon tarafındaki karşılığı; her akışın bir sahibi, bir risk haritası, bir ölçüm noktası ve bir müdahale yolu olmasıdır. Kurumsal çerçevenin tamamı için yapay zekâ ve iş akışı otomasyonu çözümüne bakabilirsiniz.

Make.com Senaryoları Teknik Olarak Nasıl Çalışır?

Bir Make senaryosu, bir tetikleyiciden gelen veri paketini modülden modüle taşıyarak çalışır; her modül kendisine gelen paketi işler ve sonucu bir sonraki adıma verir. Tetikleyici zamanlanmış bir kontrol, bir uygulamadaki yeni kayıt veya anlık bir webhook çağrısı olabilir. Anlık olayların senaryoya nasıl alındığı Make'in resmî webhook belgelerinde açıklanır.

Kurumsal bir senaryo, bu temel akışın üzerine beş kontrol katmanı ekler:

1. Giriş doğrulama: Zorunlu alanlar, veri biçimi ve beklenen değer aralığı senaryonun ilk adımlarında kontrol edilir; uygun olmayan kayıt ilerlemez, ayrı bir hata yoluna düşer.
2. Tekilleştirme: Aynı webhook iki kez geldiğinde ikinci çağrının yeni kayıt üretmemesi için benzersiz bir anahtar (sipariş numarası, e-posta, dış kimlik) üzerinden mevcut kayıt aranır.
3. Dallanma: Router ve filtrelerle kayıt türüne göre doğru iş kolu seçilir; her kol kendi doğrulama ve hedef sistemine sahiptir.
4. Hata rotası: Dış servis yanıt vermediğinde senaryo sessizce durmaz; kontrollü yeniden deneme uygulanır, çözülemeyen kayıt bir görev kuyruğuna yazılır ve sorumluya bildirim gider.
5. Denetim kaydı: Her çalışma benzersiz bir işlem kimliğiyle kaydedilir; hangi girdinin hangi çıktıyı ürettiği sonradan yeniden kurulabilir.

Hazır bağlantısı bulunmayan iç sistemler için jenerik HTTP modülleri kullanılır ve kimlik doğrulama, sayfalama, hız sınırı gibi konular akışın içinde ele alınır. Platformun kendi yönetim işlemlerini otomatikleştirmek gerekirse Make'in resmî API dokümantasyonu başlangıç noktasıdır. Akış mimarisinin daha teknik ayrıntısı için akıllı iş akışları tasarımı yazısına geçebilirsiniz.

Workflow Automation Türleri: Hangi Süreç Hangi Otomasyon Desenine Uyar?

Workflow automation tek bir desen değildir; sürecin tetiklenme biçimine, hata toleransına ve insan kararına duyduğu ihtiyaca göre dört ana desene ayrılır. Yanlış deseni seçmek, doğru aracı seçmiş olsanız bile sonucu bozar; örneğin anlık yanıt gereken bir süreci saatlik toplu işe bağlamak müşteri deneyimini otomasyondan önceki haline geri götürür.

• Olay tetikli akış: Yeni form, sipariş veya mesaj geldiği anda çalışır. Anlık yanıt gerektiren müşteri süreçleri için uygundur; karşılığında tekilleştirme ve yeniden deneme tasarımı zorunludur.
• Zamanlanmış toplu akış: Belirli aralıklarla veri çeker, karşılaştırır ve yazar. Raporlama, mutabakat ve senkronizasyon işleri için uygundur; anlık olmadığı için hata penceresi daha geniştir ve yeniden çalıştırmak daha kolaydır.
• İnsan onaylı akış: Sistem veriyi hazırlar, kararı yetkili kişi verir. Fiyat teklifi, dışa dönük iletişim ve geri alınamaz işlemler bu desende kalmalıdır. Onay kapısının nasıl kurulacağını human-in-the-loop rehberinde ayrıntılı anlattım.
• Yapay zekâ destekli akış: Sınıflandırma, özetleme, dil tespiti veya taslak üretimi gibi esnek adımlarda model devreye girer; veri akışının iskeleti ise deterministik kalır. Model çıktısı doğrudan işlem tetiklemez, önce doğrulanır.

Bu desenler birbirini dışlamaz. Olgun bir kurulum çoğu zaman olay tetikli bir girişle başlar, yapay zekâ ile sınıflandırır, kritik adımda insan onayı bekler ve gece çalışan zamanlanmış bir mutabakat akışıyla kendini denetler.

Make.com Senaryo Tasarımı Adım Adım Nasıl Yapılır?

Make.com senaryo tasarımı, modülleri kanvasa dizmekle değil, sürecin veri sözleşmesini yazmakla başlar: hangi alanlar zorunlu, hangi değerler geçerli, hangi kayıt benzersiz sayılır ve başarı nasıl doğrulanır? Bu dört soruyu yazılı cevaplamadan kurulan senaryo, ilk beklenmedik veride sessizce yanlış sonuç üretir.

1. Süreci ve gerçek hata örneklerini çıkarın. Son bir ayda elle düzeltilen kayıtlara bakın; otomasyonun karşılaması gereken uç durumlar oradadır.
2. Veri sözleşmesini yazın. Alan adları, zorunluluk, biçim, benzersizlik anahtarı ve hedef sistemdeki karşılıkları tek tabloda tanımlanır.
3. Tetikleyiciyi seçin. Anlık yanıt gerekiyorsa webhook, kaynak sistem izin vermiyorsa zamanlanmış kontrol kullanılır.
4. Doğrulama ve tekilleştirmeyi ilk adımlara koyun. Hatalı veriyi akışın sonunda değil girişinde yakalayın; sonradan yakalanan hata çoktan yan etki üretmiş olur.
5. Dallanmayı router ile görünür kılın. Koşulları modül içine gömmek yerine kanvasta ayrı kollar olarak gösterin; bakım yapan kişi süreci okuyabilsin.
6. Hata yolunu ve bildirimi kurun. Başarısız kayıt kaybolmasın; kuyruğa düşsün, sorumluya bildirilsin ve yeniden işlenebilir olsun.
7. Karşıt senaryolarla test edin. Eksik e-posta, bozuk telefon, zaman aşımı, yetkisiz API yanıtı ve aynı webhook'un tekrarı ayrı test vakalarıdır.
8. Sınırlı hacimle açın ve ölçün. Önce dar bir segmentte çalıştırın, hata türlerini ve tüketimi gözlemleyin, sonra genişletin.

Bu sıralamanın önemi şudur: adımların çoğu kanvasta değil, kanvas açılmadan önce yapılan işlerdir. Uygulamada senaryo kurma süresinin büyük kısmı modül bağlamaya değil, veri sözleşmesini netleştirmeye ve uç durumları listelemeye gider.

Uçtan Uca Örnek Senaryo: Web Formundan CRM Kaydına Bir Talebin Yolculuğu

Aşağıdaki örnek, bir web formundan gelen ham talebin nasıl normalize edilip CRM kaydına dönüştüğünü somut girdi ve çıktıyla gösterir. Örnek temsilidir; gerçek bir müşteri verisi değil, tipik bir form yükünün nasıl işlendiğini göstermek için kurgulanmış bir veri setidir. Amaç, "otomasyon kurduk" cümlesinin altındaki dönüşümü görünür kılmaktır.

Ham girdi (webhook ile gelen form yükü): ad alanı " mehmet yilmaz ", e-posta alanı "Mehmet.Yilmaz@Example.COM", telefon alanı "0532 111 22 33", mesaj alanı "teklif almak istiyorum, 3 depomuz var", kaynak alanı boş, gönderim zamanı "25.07.2026 14:03".

Normalizasyondan sonra senaryo şu kararları verir. Önce e-posta anahtarıyla CRM'de arama yapar; kayıt varsa yeni kişi açmak yerine mevcut kayda not ve etkinlik ekler, böylece aynı kişi formu üç kez doldurduğunda üç ayrı müşteri kaydı oluşmaz. Kayıt yoksa yeni kişi açılır, kaynak ve segment etiketleri yazılır, sorumlu temsilciye takip görevi oluşturulur. Eksik alan işareti taşıyan kayıtlar "bilgi tamamlanacak" kuyruğuna düşer; temsilci ilk temasta hangi bilginin eksik olduğunu bilerek arar.

Doğrulanabilir çıktı: Aynı form iki kez gönderildiğinde CRM'de tek kişi kaydı ve iki etkinlik kaydı bulunur; telefon alanı geçersiz olduğunda kayıt oluşur ama "telefon doğrulanamadı" etiketiyle işaretlenir ve otomatik arama görevi açılmaz. Başarı ölçütü senaryonun yeşil dönmesi değil, bu iki cümlenin hedef sistemde gözle doğrulanabilmesidir. CRM tarafındaki alan eşleştirme ve mükerrer kayıt konusunun ayrıntısı için CRM ve kurumsal otomasyon entegrasyonu rehberine bakabilirsiniz.

CRM Entegrasyonu Kurulurken Alan Eşlemesi ve Çift Kayıt Nasıl Yönetilir?

Kurumsal otomasyon projelerinin çoğu er ya da geç bir CRM entegrasyonuna dayanır, çünkü müşteriye dokunan hemen her süreç kaydını orada tutar. Buradaki teknik iş modülleri bağlamak değildir; bağlantı birkaç dakikalık iştir. Asıl iş, iki sistemin aynı gerçeği aynı biçimde anlamasını sağlayan sözleşmeyi yazmaktır.

Bu sözleşmenin ilk maddesi alan eşleme tablosudur. Her kaynak alanının hangi hedef alana, hangi dönüşümle ve hangi zorunluluk kuralıyla gideceği yazılı olmalıdır. Serbest metin bir alanın seçim listesine yazılması, tarih biçimlerinin farklı olması ve para biriminin alan adında saklanması en sık görülen sessiz veri bozulmalarıdır. Tablo yazılı değilse eşleme senaryonun içine gömülür ve altı ay sonra kimse bir alanın neden o alana gittiğini açıklayamaz.

İkinci madde tekillik anahtarıdır. Aynı kişinin iki kayıt olarak açılmasını engelleyen şey, kayıt oluşturmadan önce yapılan aramadır. Anahtar seçilirken hangi alanın gerçekten benzersiz olduğu düşünülmelidir: e-posta çoğu B2C süreçte iyi bir anahtardır ama kurumsal satışta aynı şirketten birden çok kişi aynı ortak adresi kullanabilir. Anahtar ne olursa olsun karşılaştırmadan önce normalize edilmelidir; büyük-küçük harf farkı ya da başında ülke kodu olmayan bir telefon numarası, aramanın hiçbir zaman eşleşme bulmamasına ve CRM'in ikizlerle dolmasına yol açar. Kayıt varsa güncelle, yoksa oluştur deseni bu aramanın üzerine kurulur.

Üçüncü madde hız sınırı ve yeniden deneme davranışıdır. CRM API'leri belirli bir zaman aralığında sınırlı sayıda çağrı kabul eder; toplu bir aktarımda bu sınır aşıldığında istekler reddedilir. Doğru davranış, reddedilen isteği kaybetmek yerine artan bekleme süreleriyle yeniden denemek ve hâlâ başarısızsa ayrı bir hata kuyruğuna yazmaktır. Yeniden deneme kurarken işlemin tekrarlanabilir olması şarttır: aynı isteğin iki kez ulaşması iki kayıt üretmemelidir.

Son madde çift yönlü senkron kararıdır. İki sistem birbirini karşılıklı güncelliyorsa, bir güncelleme diğerini tetikleyip sonsuz bir döngü oluşturabilir. Bunu engellemenin yolu, her alan için tek bir doğruluk kaynağı belirlemek ve otomasyonun yaptığı değişiklikleri işaretleyerek kendi tetiklemesini görmezden gelmesini sağlamaktır. Çoğu kurumda tek yönlü senkron yeterlidir; çift yönlü ihtiyacı çoğu zaman gerçek bir gereksinim değil, süreç sahipliğinin belirlenmemiş olmasının belirtisidir.

Bulut Otomasyonunda Veri Güvenliği, KVKK Sorumluluğu ve Ölçülebilir Kanıt

Bulut otomasyonunda güvenlik iki ayrı katmanda değerlendirilir: platformun kendi sertifikasyonu ve sizin kurduğunuz senaryonun veri davranışı. İkincisi platform tarafından devralınmaz; sorumluluk veri sorumlusu olarak sizde kalır. Bu ayrımı atlamak, en sık görülen uyum hatasıdır.

Platform tarafında Make'in resmî güvenlik sayfası, ISO 27001 sertifikalı bir bilgi güvenliği programı yürütüldüğünü, SOC 2 Type II ve SOC 3 denetimlerinin tamamlandığını, aktarımda TLS 1.2/1.3 ve depolamada AES-256 şifreleme kullanıldığını belirtir. Bu kontroller altyapı için anlamlıdır; senaryonuzun hangi kişisel veriyi neden taşıdığını ise tanımlamaz.

Türkiye'de kişisel veri işleyen bir akışta veri sorumlusu; işleme amacını, hukuki dayanağı, saklama süresini, erişim yetkisini ve yurt dışına aktarım mekanizmasını belirlemekle yükümlüdür. Kişisel Verileri Koruma Kurumunun yurt dışına aktarım açıklaması, standart sözleşmeler ve diğer uygun güvence yöntemlerini tanımlar. Bulut tabanlı bir otomasyon platformu kullanmak, aktarımın hukuki dayanağını kendiliğinden sağlamaz.

Uygulamada işe yarayan kontroller şunlardır:

• Senaryoya gereksiz kişisel veriyi hiç almayın; alan minimizasyonunu tasarım aşamasında uygulayın.
• API anahtarlarını modül içindeki serbest metin alanlarına yazmayın; bağlantı ve gizli değer yönetimini kullanın.
• Çalışma geçmişinde hassas alanların görünürlüğünü ve saklama süresini sınırlayın; loglar görünmez bir veri deposuna dönüşmesin.
• Sağlık, finans ve hukuk verisi taşıyan akışlarda insan onayı kapısını zorunlu tutun.
• Erişim yetkilerini kişiye değil role bağlayın; ekipten ayrılan kişinin bağlantıları senaryoyu kilitlemesin.

Ölçülebilir kanıt tarafında ise şu ilke geçerlidir: bir iyileştirme hangi araçla iddia ediliyorsa, uygulamadan önce ve sonra aynı araçla ölçülür. Otomasyonda bu, senaryonun başarı oranı, hata kuyruğu uzunluğu ve elle düzeltilen kayıt sayısının önce/sonra karşılaştırmasıdır. Bu üç sayı ölçülmüyorsa, kazanç iddiası kanıtlanabilir değildir.

Kurumsal Make.com Projelerinde En Sık Görülen Hata Desenleri ve Riskler

Kurumsal otomasyon projelerinde en sık görülen hata, senaryonun mutlu yol üzerinde test edilip uç durumlar için hiç denenmemesidir. Demo verisiyle çalışan bir akış, üretimde ilk boş alanla veya ilk zaman aşımıyla karşılaştığında beklenmedik davranır ve bu davranış çoğu zaman fark edilmez.

• Sessiz durma: Hata işleyici tanımlanmadığı için senaryo durur, kimse haberdar olmaz ve veri günlerce akmaz. Her senaryonun bir hata rotası ve bildirim hedefi olmalıdır.
• Mükerrer kayıt: Tekilleştirme anahtarı belirlenmediği için aynı olay iki kez işlenir ve hedef sistemde çift kayıt oluşur. Yeniden gönderim, otomasyonun istisnası değil normalidir.
• Kişiye bağlı bilgi: Senaryonun amacı, alan eşleştirmeleri ve kritik bağlantıları belgelenmez; kuran kişi ayrıldığında akış dokunulamaz hale gelir.
• Aşırı otomasyon: Geri alınamaz veya dışa dönük adımlar insan onayı olmadan otomatikleştirilir. Yanlış giden bir mesaj, kazanılan zamandan pahalıya mal olur.
• Kapsam sürüklenmesi: Tek bir dev senaryo onlarca işi üstlenir; bakımı ve hata ayıklaması imkânsızlaşır. Süreçleri ayrı, küçük ve tek sorumluluklu senaryolara bölün.
• Maliyet körlüğü: Tüketim modeli anlaşılmadan hacim büyütülür. Make'in resmî fiyat sayfası 18 Temmuz 2026'da doğrulandığında ücretsiz planda ayda 1.000 kredi ve 15 dakikalık asgari çalışma aralığı listeliyordu; koşullar değişebileceği için hacim kararından önce güncel sayfa yeniden kontrol edilmelidir.

Hazır Şablon, Uzman Kurulumu ve Özel Kod: Hangi Yol Ne Zaman Doğru?

Doğru yol, sürecin hacmine değil kırılma maliyetine göre seçilir. Düşük riskli ve tek kişilik bir iş için hazır şablon yeterlidir; müşteri verisi taşıyan, birden fazla ekibi ilgilendiren ve yanlış kararın maliyeti yüksek bir süreçte ise tasarım kararları şablonun ötesine geçer.

Platform seçimi de aynı mantıkla yapılır: mevcut kurumsal araç setiniz, veri yerleşimi kısıtlarınız ve ekibin öğrenme eşiği belirleyicidir. İki platformu yan yana değerlendirmek için Make.com ve Power Automate karşılaştırmasını okuyabilirsiniz. Aynı kurumda birden fazla otomasyon platformunun birlikte kullanılması sorun değildir; sorun, hiçbirinin sahibi ve denetim kaydı olmamasıdır.

Make.com Danışmanı İçin Uygulama Kontrol Listesi

Make.com danışmanı sadece senaryo kuran kişi değil; hata toleransı, loglama, veri doğrulama, onay kapısı ve sürdürülebilir bakım modelini birlikte tasarlayan kişidir. Kurumsal işlerde asıl fark, senaryonun çalışması değil, bozulduğunda ne olduğunun bilinmesidir.

Make.com Ekosisteminde Hangi Araçlar ve Resmî Kaynaklar Kullanılır?

Kurumsal bir Make kurulumunda araç listesi platformun kendisiyle bitmez; tetikleyici kaynağı, hedef sistem, gizli değer yönetimi, izleme kanalı ve resmî doküman seti birlikte bir çalışma ortamı oluşturur. Karar verirken üçüncü taraf blog yazılarına değil, aşağıdaki birincil kaynaklara başvurun.

• Anlık olaylar: Make webhook belgeleri — olayın senaryoya nasıl alındığı, sıraya alma ve veri yapısı.
• Platform yönetimi: Make API dokümantasyonu — senaryo, bağlantı ve organizasyon işlemlerinin programatik yönetimi.
• Güvenlik ve uyum: Make güvenlik sayfası — sertifikasyonlar, şifreleme ve altyapı kontrolleri.
• Kapsam doğrulama: Make entegrasyon kataloğu — ihtiyacınız olan uygulamanın gerekli tetikleyici ve aksiyonları destekleyip desteklemediği.
• Maliyet planlama: Make fiyat sayfası — kredi tüketim modeli ve plan sınırları.
• Hukuki çerçeve: KVKK yurt dışına aktarım açıklaması — kişisel veri taşıyan akışlar için dayanak.

Sektöre özel bir kurulumun neye benzediğini görmek isterseniz e-ticaret Make entegrasyonu çözümü, sipariş, stok ve müşteri iletişimi akışlarının aynı mimariyle nasıl kurulduğunu anlatır.

Sonraki Adım: Otomasyon Olgunluğunuzu Nasıl Ölçersiniz?

Otomasyon olgunluğunuzu ölçmenin pratik yolu, mevcut akışlarınıza dört soru sormaktır: her akışın bir sahibi var mı, her akışın bir hata rotası var mı, her akış bozulduğunda haber veriyor mu ve her akışın çıktısı hedef sistemde doğrulanıyor mu? Dört sorunun tamamına "evet" diyemiyorsanız, öncelik yeni senaryo kurmak değil mevcutları sağlamlaştırmaktır.

Pratik bir başlangıç sırası şudur. Önce son bir ayda elle düzeltilen kayıtları listeleyin; bu liste otomasyonun gerçek gereksinim belgesidir. Ardından tek bir düşük riskli süreci seçin, veri sözleşmesini yazın ve dar bir segmentte pilot yapın. Pilotun başarı ölçütünü baştan tanımlayın: hangi sayının, hangi araçla, ne zaman ölçüleceği belli olsun. Ancak bu kanıt elde edildikten sonra kapsamı genişletin.

Mevcut süreçlerinizi bu çerçeveyle değerlendirmek isterseniz yapay zekâ ve iş akışı otomasyonu çözüm sayfasından başlayabilir, kapsam ve çalışma biçimi için iletişim ve hizmetler sayfasını kullanabilirsiniz.