Ajanslar için white-label otomasyon: müşteri iş akışını teklif vermeden önce kapsamlamak

Tek sayfalık kapsamda neler olmalı?

1. Tetikleyici: Akışı neyin başlattığı (form gönderimi, yeni sipariş, rezervasyon, zamanlama) ve verinin nasıl geldiği: webhook, belirli aralıklarla sorgulama ya da kaynak sistemin kendi tetikleyicisi. Beklenen hacmi müşterinin kendi ifadesiyle, örneğin günlük veya haftalık olarak not edin.
2. Sistemler: Bağlanacak her sistemi, tam hesabı veya çalışma alanını ve kullanılan aboneliği yazın. Bazı API özellikleri ve sınırları aboneliğe göre değişir; teklif vermeden önce gereken işlemlerin o abonelikte kullanılabildiğini kontrol edin.
3. Alan eşleştirme tablosu: Her alan için bir satır: kaynak alan, hedef özellik (ekrandaki etiketle değil, iç adıyla), dönüşüm (boşlukları temizleme, küçük harfe çevirme, tarih biçimi, değer eşleme) ve alan boş geldiğinde ne olacağı.
4. Mükerrer kayıt kuralı: Aynı kişiyi veya kaydı hangi alanın tanımladığı (örneğin kişi kaydında normalleştirilmiş e-posta; ortak veya değişen adreslerin sınırlarını dikkate alın) ve bir güncellemenin neyin üzerine yazabileceği. Tekrar gelen bir kişinin sorumlusunu ve ilk kaynağını koruyup korumayacağına önceden karar verin.
5. Yönlendirme kuralları: Koşulları bir tablo olarak yazın; hiçbir koşula uymayanlar için bir varsayılan belirleyin.
6. Hata davranışı: Neyin yeniden deneneceği, hedef sistem erişilemezken kaydın nereye yazılacağı, kimin hangi kanalda uyarılacağı ve bekleyen kaydın mükerrer oluşturmadan nasıl yeniden işleneceği.
7. Kabul testleri: Beklenen sonuçlarıyla birlikte adlandırılmış kısa bir test listesi: yeni kayıt, mükerrer kayıt, geçersiz veri, spam, hedef sistem erişilemez. İş, akış “çalıştığında” değil, bu testler geçtiğinde biter.
8. Kapsam dışı: Eski kayıtların toplu aktarımı, ek sistemler veya raporlama ekranları gibi dahil olmayanları açıkça yazın.

Erişim, hesaplar ve sahiplik

• Her hesabın kime ait olduğunu belirleyin. Kimlik bilgileri müşterinin hesaplarına ya da müşterinin kontrol ettiği bir hesaba ait olmalı; bir serbest çalışanın kişisel girişine değil.
• Erişimi akışın ihtiyaç duyduğu en dar izinlerle isteyin; örneğin yalnızca gereken yetkilere sahip bir private app erişim anahtarı veya API anahtarı.
• Akışın nerede çalışacağına karar verin: müşterinin n8n Cloud hesabı veya kendi sunucusundaki kurulum; ajans barındırması düşünülüyorsa önce o kullanım için lisans uygunluğunu teyit edin. Bu karar barındırma maliyetini kimin üstleneceğini, çalışma verilerini kimin göreceğini ve gece bir sorun çıktığında kimin müdahale edebileceğini belirler.
• Akış kişisel veri işliyorsa veri sorumlusu ve veri işleyen rollerini, amaç ve araçları kimin belirlediğine göre değerlendirin; müşteri her durumda tek veri sorumlusu sayılmaz. Uygulanabilir KVKK veya GDPR yükümlülüklerini, gerekli sözleşmeleri, alt yüklenicileri ve veri aktarımlarını kontrol edin.
• Bazı kurulumlar müşterinin kendi kimliğini veya onayını gerektirir; örneğin müşteri hesabında OAuth bağlantısına yetki verilmesi; sağlayıcının doğrulama gereksinimleri ürüne ve kullanıma göre değişebilir. Bunları tarihleriyle müşterinin yapılacaklar listesine koyun; kurulumu durdurabilirler.
• Kullandığınız araçların lisansını kontrol edin. Müşterinin kendi iç kullanımı için lisansa uygun kurulumunda iş akışı geliştirme danışmanlığı ile n8n ürününü yeniden sunmayı ayırın. Sustainable Use License, n8n’i ücretli erişilen barındırılmış veya yeniden markalanmış bir ürün olarak satma izni vermez; böyle bir model için n8n’den ayrı ticari yetki alın. Ajans markalı hizmet ve belgeler, n8n arayüzünü yeniden markalama hakkı anlamına gelmez; lisans bildirimlerini koruyun. Lisans metnini ve OEM koşullarını kontrol edin; belirsiz barındırma modellerini n8n ile teyit edin.

Bir tasarım partnerine brief mi vereceksiniz? White-label üretim brief’ine bakın.

İşi büyüten etkenler

Teklif vermek, bir akışı neyin büyüttüğünü bildiğinizde kolaylaşır. Teklif öncesinde şunları kontrol edin:

• Sistem sayısı ve yön: Formdan CRM’e tek yönlü aktarım, iki sistem arasında çift yönlü eşitlemeden daha küçük bir iştir.
• Bilinmeyen API’ler: Belgelenmiş bir API’si olmayan ya da daha önce kullanmadığınız bir sistem, sabit teklif öncesinde kısa bir deneme gerektirir.
• Veri kalitesi: Serbest metin alanları, tutarsız açılır liste değerleri ve CRM’de zaten bulunan mükerrer kayıtlar temizleme kuralları gerektirir.
• Eski veriler: Geçmiş kayıtların toplu aktarımı, kendi istek sınırları ve kontrolleri olan ayrı bir iştir.
• Dallanma: Her yönlendirme kuralı ve istisna yeni test senaryoları ekler.
• Test ortamı: Önce ayrı test ortamı veya sentetik veri kullanın. Canlı ortamda test zorunluysa müşteriyle izin, dış mesajları ve yan etkileri sınırlama, geri alma ve test kayıtlarını temizleme adımlarını önceden belirleyin.

Sabit fiyatı yazılı kapsama göre verin; kapsam dışındaki her şeyi ayrı bir değişiklik talebi olarak ele alın. Bu, kapsam değişikliklerinin maliyet ve beklentilere etkisini yönetmeyi kolaylaştırır.

Ajansın markasıyla teslim

• Tek sayfalık özet: Akış ne yapar, neyle tetiklenir, hangi sistemlere dokunur.
• Teslim edildiği hâliyle alan eşleştirme tablosu ve yönlendirme kuralları.
• Uyarıların neye benzediği ve bir uyarı geldiğinde ne yapılacağı.
• Kapsamdaysa, akış mantığını değiştirmeden bir yönlendirme kuralının veya sorumlunun nasıl değiştirileceği.
• Kabul testlerinin sonuçları ve yapıldıkları tarih.

Akışları, düğümleri ve kimlik bilgilerini nötr adlarla (müşteri ve amaç) adlandırın; böylece belgeler ajansın kendi belgesi gibi okunur.

Biz nasıl çalışıyoruz?

Ajanslar için bu tür tek akışlık talep aktarımlarını, yazılı kapsam ve üzerinde anlaşılan kabul testleriyle, ajansın markasıyla kuruyoruz; paket ajans ortaklığı sayfasında (İngilizce) anlatılıyor. Kendi talep kaydımızı, gelen kutusu ayıklamamızı ve uyarılarımızı n8n üzerinde nasıl çalıştırdığımızı n8n ile nasıl çalışıyoruz sayfasında görebilirsiniz.

İlgili proje ve hizmet