B2B SaaS’ların erken aşamasında onboarding süreci genellikle manuel. Kurucu veya kurucu-seviye engineer her yeni müşteriye elle hesap açıyor, DB kayıtları yaratıyor, permission’ları ayarlıyor, welcome email gönderiyor.
Müşteri sayısı 20-30’a çıkınca bu manuel süreç saatlerinizi yemeye başlıyor, 50’de patlıyor, 100’e çıkınca ekip sadece onboarding için çalışıyor.
Son 2 yılda bu geçişi 3 farklı B2B SaaS projede yaşadım. Manuel’den otomasyona geçişin nasıl tasarlandığını anlatıyorum.
Manuel onboarding’in gizli maliyeti
Açık maliyet: 45-60 dakikalık elle iş, her yeni müşteri için.
Gizli maliyet:
– Hata olasılığı yüksek (unutulan step, yanlış tıklama)
– Consistency yok (bir engineer farklı step’leri farklı yaparsa)
– Scalability yok (aynı anda 5 müşteri onboard edemiyor)
– Ölçüm yok (hangi step yavaş, hangi step fail ediyor görünmüyor)
– Knowledge silo’su (sadece belirli kişi biliyor nasıl yapılacağını)
3 ayda manuel onboarding’in maliyeti: ayda 50 saat engineer zamanı. Otomasyon yatırımı 2 ayda geri döndü.
İlk adım: süreci yaz
Otomatize etmeden önce süreci yazmak gerek. Her step’i, her sub-step’i, her decision point’i.
Mevcut manuel süreci 3 engineer’dan ayrı ayrı istedim. Her biri 7-10 step yazdı ama farklı step’ler, farklı sıralarda. “Biz aynı işi yapıyoruz sanmıyordum” dedi biri.
Uzlaşılmış süreç dokümanı:
- Tenant metadata’sını DB’de oluştur (company_name, slug, admin_email)
- Default workspace structure’ı (folders, permissions) kur
- Admin user account’ını oluştur
- Billing provider’da customer record
- Email service’de template variables
- CDN bucket’ı tenant için provision et
- Default notification preferences
- Welcome email gönder
- Customer success CRM’e entry
- Analytics event “tenant_created”
Her step için: input, output, failure mode, rollback path.
Bu dokümantasyon otomasyon spec’i olarak kullanılıyor.
İkinci adım: step’leri idempotent yap
Otomasyon fail edebilir. Bir step başarısız olduğunda sürecin başından başlamak istemezsiniz.
Her step idempotent olmalı: ikinci kez çalıştırılırsa aynı sonucu üretsin, duplicate kayıt yaratmasın.
DB insert’lerini upsert yap. Existing check + insert yerine INSERT ... ON CONFLICT DO UPDATE.
External API call’ları idempotency key ile. Stripe customer creation’da idempotency header, rerun’da aynı customer.
File/folder creation’larda exist check. mkdir -p gibi, yoksa yarat, varsa sessizce geç.
Email gönderme sadece bir kere. “Bu event için email gönderildi mi?” flag’i tutulmalı, retry’da iki kere gönderilmesin.
Üçüncü adım: orchestration layer
Adımları orchestrate edecek bir layer gerekli. Seçenekler:
A. Lineer script. Basit, küçük projeler için yeterli. Her step sequentially, fail olduğu yerde dur, retry sonra kaldığı yerden.
def onboard_tenant(tenant_data):
steps = [
create_tenant_record,
create_workspace,
create_admin_user,
create_billing_customer,
setup_email_templates,
provision_cdn_bucket,
set_notification_defaults,
send_welcome_email,
add_to_crm,
track_analytics_event
]
state = load_state(tenant_data['id'])
for step in steps:
if step.__name__ in state.completed_steps:
continue
try:
step(tenant_data)
state.completed_steps.append(step.__name__)
save_state(state)
except Exception as e:
log.error(f"{step.__name__} failed: {e}")
raiseBu pattern küçük ölçekte (1-2 dakika runtime) yeterli.
B. Workflow engine (Temporal, AWS Step Functions, Airflow). Büyük orchestration, long-running task, retry policy, observability yerleşik.
Temporal iyi seçim: Go veya Java’da yazıyorsunuz, compensation (rollback) desteği var, workflow history kalıcı, debug UI güzel.
C. Queue-based (BullMQ, Celery, Sidekiq). Her step bir job, step’ler arası data pass queue ile. Paralel execution imkanı.
Ben orta ölçek projelerde queue-based tercih ediyorum. Step’ler paralel işlenebildiği zaman overall süre kısalıyor.
Dördüncü adım: self-service portal
Otomasyon backend’i hazır. Şimdi müşterinin kendi onboard olabileceği portal:
- Landing page’de “Try free” butonu
- Signup form (email, company name, slug)
- Email verification
- Default password set veya magic link
- Otomasyon tetikleniyor backend’de
- “Hesap hazır” email’i + login link
Tüm süreç kullanıcı için 3-5 dakika. Backend’de 30-60 saniye. Engineer zamanı 0.
Design consideration’lar:
– Slug conflict: mevcut slug varsa alternatif öner
– Invalid email: inline validation
– Enterprise müşteri farklı yol: büyük account’lar hala sales-led onboarding, ama automation tarafında da aynı pipeline çağrılıyor
Beşinci adım: monitoring ve iyileştirme
Otomasyon kurduk, şimdi ölçüm:
- Funnel: signup form başlattı → tamamlandı (conversion rate)
- Time to value: ilk feature kullanımı kaç dakika sonra
- Onboarding step failure rate: hangi step fail ediyor, ne sıklıkta
- Manual intervention rate: kaç tenant otomatik tamamlanamadı, manuel müdahale gerekti
Bu metrikler dashboard’a konuyor, haftalık review.
İlk ay: %12 tenant manuel intervention istedi (edge case’ler). İkinci ay edge case’leri code’a eklendi, %3’e düştü. Üçüncü ay %1.
Hedef 0 olmasa da %1-2 manuel intervention kabul edilebilir. Genelde enterprise edge case veya fraud suspect olabiliyor.
Altıncı adım: rollback pathı
Tenant onboarding otomatik ama bazen tenant vazgeçiyor (free trial sonu hiç kullanmadan), bazen fraud çıkıyor, bazen müşteri yanlış hesap açtı. Tenant offboarding da gerekiyor.
Offboarding pipeline:
- User data export (GDPR right to access)
- Billing cancellation
- Tenant workspace backup
- Admin user deactivate
- Email notification
- Analytics “tenant_churned” event
- Scheduled hard-delete (örn. 30 gün sonra)
GDPR compliance nedeniyle hard-delete zorunlu. Grace period koyun (30-90 gün) kullanıcı fikrini değiştirirse geri dönebilsin.
Yedinci adım: data migration pattern’ı
Mevcut tenant’lar manuel onboard edilmişti. Yeni automated flow’a geçiş döneminde iki system paralel yaşıyor.
Backfill script: eski tenant’lara yeni flow’daki eksik step’leri uygula (eğer yeni step eklendiyse). İdempotent olduğu için zarar vermiyor.
Historical audit: eski tenant’ların onboarding’i eksik / bozuk mu? Query ile check, bulduklarını backfill.
Performans notları
Orchestration’da dikkat:
- Sequential vs parallel. Bazı step’ler bağımsız (billing + CRM), parallel. Bazıları dependent (user create sonrası permission), sequential.
- External API timeout’ları. Stripe, SendGrid gibi third-party timeout 30 saniye olabilir, worker’ı uzun süre bloklamayın, queue’dan devam.
- Rate limit’lere dikkat. 100 tenant aynı anda onboard olursa Stripe rate limit’e takılabilir. Throttling/queue ile.
Gerçek sonuçlar
Bir B2B SaaS’ta otomasyon öncesi/sonrası:
– Onboarding süresi: 47 dakika → 90 saniye
– Engineering time per tenant: 45 min → 0
– Manuel error rate: %8 → %0.5
– Parallel onboard capacity: 1 → 50+
– Customer success satisfaction: “çok teknik” → “müthiş hızlı”
Otomasyon 3 ay sonra amortize oldu.
Son ders
Onboarding otomasyonu bir engineering projesi değil, business enabler. Manuel onboard sabit 100 müşteride şirketin büyümesi durur, otomasyon 10.000 müşteriye ölçekleniyor.
Erken aşamada “süreç oturmasın” deyip manuel tutmak mantıklı, ama müşteri sayısı 20’ye çıkınca otomasyon yatırımını başlatmanın zamanı geldi.