Müşteri Onaylarıyla Kampanya Web Uygulaması Nasıl Oluşturulur

Ürün Hedeflerini ve Hedef Kullanıcıları Tanımlayın

Ekran taslağı çizmeden veya teknoloji yığını seçmeden önce temel sorunu netleştirin: pazarlama kampanyaları ve onaylar e-posta, sohbet ve paylaşılan sürücülerde dağınık. Bir kampanya web uygulaması briefleri, varlıkları, geri bildirimleri ve onayı tek bir yerde toplamalı ki herkes sıradaki adımı görebilsin—izleri kovalamadan.

Kimler için inşa ediyorsunuz

Çoğu ajans onay iş akışı dört grup içerir ve her birinin farklı ihtiyaçları vardır:

• Hesap yöneticileri / proje yöneticileri: güvenilir bir zaman çizelgesine, net sahipliğe ve daha az takip mesajına ihtiyaç duyar.
• Kreatifler (tasarımcılar, metin yazarları, editörler): odaklanmış geri bildirim, daha az çelişkili not ve revizyon yüklemek için basit bir yol ister.
• Müşteriler: kolay bir inceleme deneyimi, en son sürümü gördüklerinden emin olma ve hızlı onay yolları ister.
• Onaycılar (hukuk, marka, yöneticiler): bağlam, risk görünürlüğü ve denetlenebilir bir “onaylayan” kaydı ister.

Tasarıma karşı koymanız gereken ortak zorluklar

E-posta tabanlı onaylar öngörülebilir sorunlar yaratır: en son isteği kimse görmediği için kaçırılan teslim tarihleri, “daha canlı yap” gibi belirsiz geri bildirimler, birden fazla sürümün dolaşması ve geç veya çelişkili girdiler yüzünden tekrar çalışmaları tetikleyen döngüler.

Gerçekten önemli başarı metrikleri

Ürünün işe yarayıp yaramadığını değerlendirebilmek için ölçülebilir sonuçlar tanımlayın:

• Onay dönüş süresi (istek gönderildi → nihai onay)
• Varlık başına revizyon döngüleri
• Kampanya kilometre taşlarının zamanında teslim oranı
• Müşteri memnuniyeti sinyalleri (ör. daha az “neredeyiz?” mesajı)

“v1” içinde olması gerekenler

v1 için kampanyaları ve onayları birlikte tutacak en küçük sete odaklanın:

• Kampanya zaman çizelgesi
• Varlık yükleme + önizleme
• Belirli sürümlere bağlı yorum dizileri
• Tarihli net onay/reddetme adımı

İyi olanakları sonradan ekleyin: gelişmiş raporlama, derin entegrasyonlar, otomasyon kuralları ve özel onay yolları.

Kampanya ve Onay İş Akışını Haritalayın

Ekranlara veya teknolojiye geçmeden önce, işin ajansınızda gerçek hareketini yazın. Net bir iş akışı “Bu nerede?” sorusunu öngörülebilir adımlara çevirir; uygulamanız bu adımları zorlayabilir, otomatikleştirebilir ve raporlayabilir.

Temel nesnelerle başlayın

Çoğu kampanya onay uygulaması küçük bir yapıtaşı setiyle tanımlanabilir:

• Müşteriler (ve müşteri ekipleri)
• Kampanyalar (genellikle hedef, bütçe ve tarih aralığına bağlı)
• Projeler (kampanyanın teslimatlara veya kanallara bölünmesi)
• Görevler (kim ne yapar, ne zamana kadar)
• Varlıklar (dosyalar: kavramlar, metin belgeleri, görseller, videolar, açılış sayfaları)
• Onaylar (bir varlık/sürümle ilişkili karar kaydı)

İlişkileri belgeleyin: bir kampanya projeleri içerir; projeler görevleri içerir; görevler varlık üretir; varlıklar onaylardan geçer.

Onay yaşam döngüsünü tanımlayın

Basit ve ajansa uygun bir akış şöyle olabilir:

Taslak → İç inceleme → Müşteri incelemesi → Onaylandı

Her durumu operasyonel olarak anlamlı kılın. Örneğin “İç inceleme”, bir müşteri görmeden önce yaratıcı lider ve hesap yöneticisinin onayını gerektirebilir.

Geri bildirimin nasıl yakalanacağını belirtin

Üründeki geri bildirim formatını karar verin:

• Yorumlar (dizili, @bahsetmeler ile)
• Anotasyonlar (bir resim/video karesine pin yorumlar)
• Değişiklik istekleri ("kesinlikle düzeltilmeli" vs "iyi olur" gibi yapılandırılmış alanlar)

Anahtar, geri bildirimi bir varlık sürümüne bağlamaktır, böylece hangi dosyanın incelendiği konusunda tartışma olmaz.

Tıkanıklıkları bulun ve otomatikleştirin

Yaygın yavaşlamalar: inceleyicilerin beklemesi, belirsiz sonraki adımlar ve tekrarlayan kurulum. En çok yardımcı olan otomasyonlar:

• Hatırlatıcı kuralları (ör. “Müşteri incelemesinde” 48 saat sonra hatırlatma)
• Onay şablonları (varsayılan inceleyiciler, son tarihler, gerekli kontroller)

Kenar durumlarını erken yakalayın

Gerçek onaylar her zaman temiz olmaz. Planlayın:

• Kısmi onaylar (metin onaylandı, görseller reddedildi gibi)
• Reddedilen öğeler (gerekli nedenle + sonraki teslim tarihi)
• Son dakika değişiklikleri (onaylı varlığı yeniden açma, onayları yeniden tetikleme, kim yaptığını kaydetme)

Bu kuralları düz bir dille açıklayabiliyorsanız, ekranlara ve veri modellerine dönüştürmeye hazırsınız.

UX Planlaması: Panolar, Zaman Çizelgeleri ve İnceleme Görünümleri

Mükemmel bir kampanya uygulaması UX'i, ajansların zaten düşündüğü basit bir bilgi hiyerarşisiyle başlar: Müşteri → Kampanya → Teslimatlar (varlıklar). Kullanıcılar her zaman “Neredeyim?” ve “Sonraki ne?” sorularına cevap bulabilirse, onaylar hızlanır ve daha az şey gözden kaçar.

Net bir hiyerarşi seçin (ve tutarlı tutun)

Müşteriyi üst düzey çapa olarak kullanın, altında kampanyaları, en altta teslimatları (reklamlar, e-postalar, açılış sayfaları, sosyal gönderiler) gösterin. Navigasyon, kırıntı yolları ve aramada aynı yapıyı koruyun ki insanlar her ekranda uygulamayı yeniden öğrenmek zorunda kalmasın.

Pratik bir kural: her teslimat her zaman bir bakışta müşteri, kampanya, teslim tarihi, durum ve sorumlu göstermeli.

Önemli ekranları tasarlayın ("günlük kullanılanlar")

Gösterge Paneli: Ajansın ana sayfası. Bugün dikkat gerektirenlere odaklanın: yaklaşan teslim tarihleri, iç inceleme bekleyen öğeler ve müşteri onayı bekleyenler.

Kampanya zaman çizelgesi: Bağımlılıkları (ör. "Metin onaylandı" → "Tasarım final") görünür kılan takvim ya da faz bazlı görünüm. Okunabilir tutun—insanlar ilerlemeyi saniyeler içinde anlamalı.

Varlık inceleme görünümü: Zaman burada kazanılır veya kaybedilir. Önizlemeyi büyük yapın, yorumları kolay bulunur kılın ve sonraki eylemi net gösterin.

Gelen Kutusu: "Cevaplamam gerekenler" için tek bir yer (yeni geri bildirim, onay isteği, mentionlar). Bu e-posta ve sohbet arasındaki ping-pong'u azaltır.

Gerçek sorulara uygun filtreler

Hızlı filtreler yaygın ajans sorularını yanıtlamalı:

• Müşteri bazında (bağlamı anında değiştir)
• Teslim tarihi (geciken, bu hafta teslim)
• Durum (taslak, incelemede, değişiklik istendi, onaylandı)
• Atanan kişi (kimin sorumluluğunda)

Onayı gözden kaçırmayı imkansız kılın

Birincil çağrı eylemi açık olmalı: Onayla / Değişiklik iste. İnceleme görünümünde sabit (sticky footer/header) tutun ki müşteriler yorumları kaydırdıktan sonra butonu aramasın.

Mobil dostu müşteri incelemelerini planlayın

Müşteriler sık sık toplantılar arasında inceler. Mobil okunabilirliğe öncelik verin: temiz bir önizleme, büyük butonlar ve kısa geri bildirim formları. Bir dokunuşla varlığı açıp diğer dokunuşla onaylayabilirse dönüş süreleri hızlanır.

Roller, İzinler ve Müşteri Erişimi

Bir kampanya onay uygulaması güvene bağlı yaşar veya ölür: müşteriler yalnızca görmeleri gerekenleri gördüklerinden emin olmalı; ekibinizin üzerine yazılmaması veya yanlış kişinin onaylamaması için net sınırlar olmalı.

Temel roller (basit başlayın)

Çoğu ajans ihtiyaçların çoğunu beş rol ile karşılayabilir:

• Ajans yöneticisi: çalışma alanı ayarlarını, faturalamayı, şablonları ve kullanıcı yönetimini yönetir.
• Hesap yöneticisi: kampanyalardan, zaman çizelgelerinden ve müşteri ilişkilerinden sorumludur; müşterileri davet edebilir ve onaycıları atayabilir.
• Katkıda bulunan (tasarımcı/metin yazarı): varlık yükler, geri bildirimlere cevap verir, yeni sürümler oluşturur.
• Müşteri: kendi kampanyalarını ve varlıklarını görebilir, yorum yapabilir ve değişiklik isteyebilir.
• Onaycı: müşteri tarafında (veya dahili) açık onay yetkisine sahip rol.

Nesne başına izinler ("tek beden herkese uyar" değil)

Sadece global izinler yerine, nesne türü başına (kampanya, teslimat, varlık, yorum) eylemler tanımlayın. Tipik eylemler: görüntüle, yorum yap, yükle, onayla, düzenle, sil.

Pratik varsayılan: katkıda bulunanlar kendi varlıklarını yükleyip düzenleyebilir; kampanya ayarlarını silme veya değiştirme ise hesap yöneticileri/yoneticilerle sınırlı olsun.

Müşteri-özel erişim

Müşteriler yalnızca kendi kampanyalarını, varlıklarını ve tartışmalarını görmelidir. Diğer hesapları istemeden açığa çıkaran paylaşılan "müşteri klasörlerinden" kaçının. Bu, her kampanyanın bir müşteri hesabına bağlı olması ve erişim kontrollerinin sayfalar, indirmeler ve bildirimler genelinde tutarlı uygulanmasıyla en kolay sağlanır.

Çoklu onaycı kuralları

Teslimat başına iki onay modu destekleyin:

• Herhangi bir onaycı: tek onay yeterli (hızlı sosyal gönderiler için).
• Tüm onaycılar gerekli: herkesin onayı gerekli (marka açısından hassas işler için).

Genel verileri ifşa etmeden güvenli paylaşım

Kolaylık için paylaşım linkleri sunun, ancak varsayılan olarak özel tutun: zaman sınırlı tokenler, isteğe bağlı şifre ve iptal etme özelliği. İyi bir kural: paylaşım asla müşteri sınırını atlamamalı—sadece kullanıcının normalde görebileceği öğelere erişim vermeli.

Onay Durumları, Geri Bildirim ve Varlık Sürümleme

Bir müşteri onay özelliği netliğe bağlıdır. Ekip ve müşteriler kimin ne için beklediğini söyleyemezse, onaylar tıkanır ve “onaylandı” tartışmalı hale gelir.

Basit, tutarlı bir durum modeli

Herkesin tanıyacağı küçük bir durum setiyle başlayın:

• Taslak: dahili üzerinde çalışılıyor
• İncelemede: müşteri (veya dahili inceleyici) ile paylaşıldı ve geri bildirim bekleniyor
• Değişiklik istendi: geri bildirim alındı; ekipin yanıt vermesi gerekiyor
• Onaylandı: kullanıma kabul edildi

Her kenar durumu için yeni bir durum eklemekten kaçının. Daha fazla nüans gerekirse etiketler (ör. “hukuk incelemesi”) kullanın.

Sürümleme: geçmişi asla üzerine yazmayın

Her yüklemeyi yeni, değiştirilemez bir sürüm olarak ele alın. Dosyaları yerinde değiştirmeyin—aynı varlığa bağlı v1, v2, v3… oluşturun.

Bu, temiz konuşmalar sağlar ("Lütfen v3'ü güncelleyin") ve kazara kayıpları önler. UI'da geçerli sürümü belirgin yapın ve önceki sürümleri karşılaştırma için açılabilir tutun.

Eyleme dönük yapılandırılmış geri bildirim

Sadece serbest biçimli yorumlar karmaşadır. Yapı ekleyin:

• Gerekli düzeltmeler için kontrol listesi maddeleri (her biri tamamlandı olarak işaretlenebilir)
• Gerekli değişiklikler ile “iyi olur” önerileri ayrımı
• İşte yönlendirmek için @bahsetmeler

Zaman kodları (video) veya sayfa/alan pinleri (PDF/görseller) desteklenirse geri bildirim çok daha uygulanabilir olur.

Onay meta verisi ve sonraki adımlar

Birisi onayladığında kaydedin:

• Onaycı kimliği (kullanıcı + rol)
• Zaman damgası
• Onaylanan sürüm ID'si

Onayın ardından kuralları tanımlayın: genellikle onaylı sürümü düzenlemeye kapatın, ancak küçük bir revizyon oluşturmaya izin verin (yeni sürüm oluşturur ve durumu yeniden İncelemede'ye çeker). Bu, onayları savunabilir kılar ama meşru son dakika düzeltmelerini engellemez.

Varlık Yönetimi: Yüklemeler, Önizlemeler ve Depolama

Yaratıcı onaylar, insanların doğru dosyaya doğru zamanda kolayca erişebilmesine bağlıdır. Varlık yönetimi birçok kampanya uygulamasının gizlice sinir bozucu olduğu yerdir—yavaş indirmeler, kafa karıştıran dosya adları ve hangi sürümün son olduğu konusunda sonsuz döngüler.

Dosyalar ve meta veriyi ayrı tutun

Temiz bir desen: nesne depolama gerçek dosyalar için (hızlı, ölçeklenebilir, ucuz) ve veritabanı meta veriler için (aranabilir ve yapılandırılmış).

Veritabanınız şunları izlemeli: varlık adı, türü, kampanya, geçerli sürüm, kimin yüklediği, zaman damgaları, onay durumu ve önizleme URL'leri. Depolama katmanı ikili dosyayı ve isteğe bağlı türetilmiş öğeleri (küçük resimler) tutar.

Ajansların gerçekten kullandığı formatları destekleyin

Çoğu iş akışını kapsayan küçük bir set hedefleyin:

• Görseller (JPG/PNG/WebP)
• PDF'ler (marka yönergeleri, baskı onayları)
• Video (yüklüyorsanız; ya da Vimeo/YouTube/Frame.io tarzı barındırma için linkler)
• Metin taslakları (ya metin alanı ya da yorumlu basit belgeler)

UI'da hangi öğelerin yüklenebileceği vs sadece link verilebileceği açık olsun. Bu başarısız yüklemeleri ve destek taleplerini azaltır.

Önizlemeler ve küçük resimler (gereksiz indirmeleri önlemek için)

Önizlemeler incelemeyi hızlandırır ve müşteriye daha dost canlısı olur. Üretin:

• Görsel küçük resimleri ve daha büyük bir önizleme boyutu
• PDF ilk sayfa küçük resimleri + tarayıcı içi görüntüleyici
• Video poster kareleri (veya bir link verildiyse gömülü oynatma)

Bu, paydaşların tam çözünürlük dosyalarını indirmeden teslimat panosunu taramasını sağlar.

Güvenli yüklemeler: limitler, doğrulama ve tarama

Dosya limitlerini erken tanımlayın (maks boyut, kampanya başına maksimum dosya sayısı, desteklenen uzantılar). Hem dosya türünü hem içeriğini doğrulayın (uzantıya güvenmeyin). Kurumsal müşteriler veya büyük dosyalar kabul ediyorsanız, yükleme hattına virüs/malware taraması eklemeyi düşünün.

Saklama ve silme kuralları

Onaylar genellikle izlenebilirlik gerektirir. "Silme"nin ne anlama geldiğini belirleyin:

• Yumuşak silme günlük temizlik için (kurtarılabilir, hâlâ denetlenebilir)
• Kalıcı silme yasal talepler ve depolama yönetimi

Bunu kampanya bitiminden sonra 12–24 ay saklama gibi saklama politikalarıyla eşleştirin ki depolama maliyetleri kontrolden çıkmasın.

Mimari Genel Bakış: Önyüz, Arka uç ve Servisler

Müşteri onaylı bir kampanya uygulaması egzotik altyapıya ihtiyaç duymaz. İnsanlar için dost bir arayüz, kuralları uygulayan bir API, dosya ve veri depolama ve hatırlatmalar gibi zaman tabanlı işleri yöneten arka plan işçileri gerekir.

Ekibinizin gönderebileceği bir yığın seçin

Takımınızın inşa edip işletmekten emin olduğu ile başlayın. Zaten React + Node, Rails veya Django biliyorsanız, v1 için genellikle doğru seçim budur. Barındırma tercihleri de önemlidir: "push to deploy" basitliği istiyorsanız, yığına iyi destek veren ve loglar, ölçekleme ve gizli yönetimini kolaylaştıran bir platform seçin.

Ağır sıfırdan inşa döngüsüne kilitlenmeden daha hızlı ilerlemek istiyorsanız, Koder.ai gibi bir vibe-coding platformu iş akışı (kampanyalar, varlıklar, onaylar, roller) üzerinde prototip oluşturmanıza yardımcı olabilir—sonra hazır olduğunuzda kaynak kodunu dışa aktarabilirsiniz.

Temel katmanlar (ihtiyacınız olan minimum)

Önyüz (web uygulaması): Panolar, kampanya zaman çizelgeleri ve inceleme ekranları. API ile konuşur ve gerçek zamanlı UX detaylarını yönetir (yüklenme durumları, yükleme ilerlemesi, yorum dizileri).

Arka uç API: Kim onaylayabilir, bir varlık ne zaman kilitlenir, hangi durum geçişleri izinli—bütün iş kurallarının kaynağı. Sıkıcı ve öngörülebilir tutun.

Veritabanı: Kampanyalar, görevler, onaylar, yorumlar ve denetim olaylarını saklar.

Dosya depolama + önizleme: Yüklemeleri nesne depolamada saklayın (S3 uyumlu). Önizlemeler üreterek müşterilerin büyük dosyaları indirmeden incelemesini sağlayın.

Arka plan işleri: Kullanıcıyı bloklamaması gereken her şey: e-postalar, önizleme üretimi, planlı hatırlatıcılar, gece raporları.

Monolit vs servisler (v1'de basit tutun)

Çoğu ajans için modüler bir monolit idealdir: iyi ayrılmış modüller (varlıklar, onaylar, bildirimler) ile tek bir arka uç kod tabanı. Gerçekten fayda sağladığında (ör. işçiye ayrım) servislere ayırabilirsiniz.

Bildirimler ve iş kuyruğu

Bildirimleri birinci sınıf özellik olarak ele alın: uygulama içi + e-posta, tercih opt-out'leri ve net threading ile. Bir iş kuyruğu (BullMQ, Sidekiq, Celery vb.) hatırlatmaları güvenilir şekilde göndermenizi, hataları yeniden denemenizi ve yüklemeler/onaylar sırasında yavaşlamayı önlemenizi sağlar.

Ortamlar: geliştirme, staging, üretim

Başından üç ortam planlayın:

• Dev: hızlı yineleme, örnek kampanyalarla seed edilmiş.
• Staging: üretimi taklit eden ayarlar ile dahili kullanıcı testi için.
• Production: sertleştirilmiş konfigürasyon, yedekler, izleme.

Veri tarafına daha derin girmek isterseniz, /blog/data-model-and-database-design ile devam edin.

Veri Modeli ve Veritabanı Tasarımı

Temiz bir veri modeli, kampanya uygulamanızı büyüdükçe basit hissettiren şeydir. Amaç, ortak ekranları—kampanya listeleri, varlık kuyrukları, onay sayfaları—hızlı ve öngörülebilir yapmak, aynı zamanda ileride ihtiyaç duyacağınız geçmişi yakalamaktır.

Temel tablolar (minumum, sonra sevinirsiniz)

Ajansların gerçek çalışmasına uyan küçük bir tablo setiyle başlayın:

• organizations: her ajans için bir satır (tenant)
• users: dahili ekip üyeleri, organization ile bağlı
• clients: bir organizasyon altındaki müşteri şirketleri
• campaigns: iş konteynerleri, bir müşteri tarafından sahiplenilir
• assets: yaratıcı dosya veya linkler, bir kampanya tarafından sahiplenilir
• approvals: bir varlık (veya varlık sürümü) için geçerli onay durumu

ID'leri tutarlı tutun (UUID veya sayısal ID—her ikisi de uygundur). Önemli kısım, her alt kaydın (clients, campaigns, assets) bir organization_id taşımasıdır; böylece veri izolasyonunu zorlayabilirsiniz.

Denetim + etkinlik: hikayeyi yakalayın, sadece durumu değil

Sadece durumlar ne olduğunu açıklamaz. Aşağıdaki gibi tablolar ekleyin:

• comments: varlıklar üzerindeki dizili geri bildirimler (yazar ve zaman damgası ile)
• events (veya activity): “varlık yüklendi”, “inceleme istendi”, “onaylandı”, “değişiklik istendi” gibi
• status_changes: çevrim süresi raporu gerekiyorsa odaklı bir günlük

Bu, denetim izlerini ve hesap verebilirliği çekirdek tabloları şişirmeden kolaylaştırır.

Gerçek dünya listeleri için indeksleme

Çoğu ekran müşteri, durum ve teslim tarihi ile filtreler. Aşağıdaki indeksleri ekleyin:

• (organization_id, client_id)
• (organization_id, status)
• (organization_id, due_date)

Ayrıca “şimdi inceleme gereken” için bileşik bir indeks düşünün: (organization_id, status, updated_at).

Göçler ve şablonlar için seed verisi

Şemanızı ürün kodu gibi ele alın: her değişiklik için migration kullanın. Birkaç kampanya şablonu (varsayılan aşamalar, örnek statüler, standart onay adımları) seed edin ki yeni ajanslar hızlı başlayabilsin ve test ortamlarınız gerçekçi veriyle dolu olsun.

Kimlik Doğrulama, Davetler ve Güvenlik Temelleri

Bir müşteri onay uygulaması güvene bağlıdır: müşteriler basit bir giriş ister, ekibiniz ise yalnızca doğru kişilerin doğru işleri gördüğünden emin olmak ister. Ajans hazır hissettirene kadar en küçük kimlik özellik setiyle başlayın, sonra genişletin.

Doğru oturum açma yöntemini seçin

Kullanıcılarınız çoğunlukla ara sıra oturum açan müşterilerse, e-posta + parola genellikle en pürüzsüz yoldur. Daha büyük kuruluşlar için SSO (Google/Microsoft) düşünün. Her ikisini de daha sonra destekleyebilirsiniz—ancak SSO'yu kullanıcılar beklemiyorsa zorunlu kılmayın.

Davetler iş akışını yavaşlatmamalı

Davetler hızlı, role duyarlı ve affedici olmalı:

• E-posta ile ekip üyelerini ve müşterileri davet edin; davet sırasında rol atayın
• Davetleri yeniden gönderin ve kabul öncesi rolleri değiştirin
• Davet edilen kullanıcıları e-posta doğrulanana kadar “beklemede” tutun

İyi bir desen, yeni kullanıcıların parola hatırlamak zorunda kalmaması için magik link ile parola ayarlamaktır.

Güvenli oturumlar ve parola kurtarma

Güvenli oturum yönetimi kullanın (kısa ömürlü erişim tokenları, döndürülebilen refresh tokenlar, mümkünse httpOnly cookie). Parola sıfırlama akışı tek kullanımlık, süresi dolan tokenlarla ve net onay ekranlarıyla olmalı.

Her istekte yetkilendirme

Kimliğiniz "siz kimsiniz?" cevabını verir; yetkilendirme "ne yapabilirsiniz?" sorusunu. Her endpoint'i izin kontrolleriyle koruyun—özellikle kampanya varlıkları, yorumlar ve onaylar için. Sadece UI gizlemeye güvenmeyin.

Hassas içerik toplamadan loglama

Giriş denemeleri, davet kabulü, rol değişiklikleri, şüpheli etkinlik gibi denetim dostu loglar tutun; ancak gizli bilgileri saklamaktan kaçının. Tanımlayıcılar, zaman damgaları, IP/cihaz ipuçları ve sonuçlar kaydedilsin—ham parolalar, tam dosya içerikleri veya özel müşteri notları asla saklanmasın.

Bildirimler, Hatırlatıcılar ve Müşteri Dostu Güncellemeler

Bildirimler kampanya uygulamalarını ya yardımcı ya da yorucu yapar. Amaç: işi ilerletmek, her yorumu gelen kutusu yangınına çevirmemek.

Önemli olayları tanımlayın

Başlangıç için küçük, yüksek sinyal tetikleyicilerle başlayın ve bunları e-posta ile uygulama içinde tutarlı yapın:

• Yeni inceleme isteği (müşteriden belirli bir varlık/sürüm onayı isteniyor)
• Yeni yorum veya mention (özellikle biri @bahsettiyse)
• Onay veya reddetme (bir durumu değiştirerek sonraki adımları açar)
• Teslim tarihi hatırlatmaları (yakında/on tarih geçmiş öğeler)

Her bildirime “ne” ve bir sonraki eylemi (doğrudan doğru görünüme bağlanan) dahil edin.

Kullanıcılara kanal ve sıklık seçme hakkı verin

Farklı roller farklı detay seviyeleri ister. Kullanıcı düzeyinde kontrol verin:

• Kanallar: e-posta, uygulama içi (ve ileride isteğe bağlı Slack)
• Sıklık: gerçek zamanlı, günlük özet veya "sadece atandığımda/mentionlandığımda"

Akıllı varsayılanlar kullanın: müşteriler genellikle iç ekipten daha az e-posta ister.

Gürültüyü toplama ve akıllı kurallarla önleme

Benzer güncellemeleri gruplayın (ör. “Ana Sayfa Banner üzerinde 3 yeni yorum”) yerine her yorum için ayrı e-posta göndermeyin. Koruyucular ekleyin:

• İşlemi yapan kişiyi bildirimden hariç tutun.
• Hızlı ardışık düzenlemeleri/kayıtları kısa bir zaman aralığında çökertin.
• Sadece gerektiğinde yükseltin (ör. gecikmiş hatırlatmalar).

Müşteri dostu bir onay gelen kutusu oluşturun

Ayrılmış bir Onay Gelen Kutusu sayfası, müşterinin yapması gerekenleri gösterir: “Sizin beklediğiniz” öğeler, teslim tarihleri ve doğru inceleme ekranına tek tık yol. Temiz ve erişilebilir tutun ve her inceleme e-postasında buna bağlantı verin (ör. /approvals).

Teslimat ve hatalar takip edin

E-posta garantili değildir. Teslim durumunu (gönderildi, geri döndü, hata) saklayın ve akıllıca yeniden deneyin. E-posta başarısız olursa yöneticilere gösterin ve iş akışının sessizce tıkanmaması için uygulama içi bildirimlere geri dönün.

Denetim İzleri, Etkinlik Akışları ve Hesap Verebilirlik

Müşteriler yaratıcıyı onayladığında sadece bir düğmeye basmazlar—bir kararın sorumluluğunu üstlenirler. Uygulamanız bu karar izini kolay bulunur, anlaşılır ve sonradan tartışılması zor olacak şekilde sunmalıdır.

Etkinlik akışı: kampanyanın “hikayesi”

İki seviyede etkinlik akışı uygulayın:

• Kampanya bazında: önemli olayların kronolojik kaydı (brief oluşturuldu, varlık eklendi, müşteri davet edildi, kilometre taşları tamamlandı).
• Varlık bazında: ayrıntılı inceleme geçmişi (yeni sürüm yüklendi, yorumlar eklendi, inceleme istendi, onaylandı/reddedildi).

Girişleri teknik olmayan kullanıcılar için okunaklı tutun: Kim ne yaptı, ne zaman ve nerede formatı. Örneğin: “Jordan (Ajans) Homepage Hero v3 yükledi — 12 Ara, 14:14” ve “Sam (Müşteri) Homepage Hero v3 onayladı — 13 Ara, 09:03.”

Denetim izi: kaydetmeniz gerekenler

Hesap verebilirlik için şunların denetim izini tutun:

• Onaylar ve reddetmeler (durum ve isteğe bağlı mesaj dahil)
• Ana alanlarda yapılan düzenlemeler (teslim tarihleri, brief değişiklikleri, yeniden adlandırmalar)
• Dosya yükleme ve sürümleme olayları (yeni sürüm oluşturuldu, sürüm geri yüklendi)
• Üyelik işlemleri (davet gönderildi, rol değişti, erişim iptal edildi)

Pratik bir kural: bir etkinlik teslimatı, zamanı veya müşteri onayını etkiliyorsa denetim izine dahil edin.

Düzenlenebilir vs değiştirilemez: net sınırlar koyun

Denetim olayları genellikle değiştirilemez olmalı. Bir şeyin düzeltilmesi gerekiyorsa yeni bir olay kaydedin (ör. “Ajans tarafından onay yeniden açıldı”), geçmişi yeniden yazmayın. Görüntü amaçlı alanlarda (ör. küçük yazım hatası) düzenleme izin verin ama düzenlemenin yapıldığını yine kaydedin.

Müşteri devri özeti dışa aktarımı

Basit bir özet (PDF veya CSV) dışa aktarma desteği verin: nihai onaylı sürümler, onay zaman damgaları, önemli geri bildirimler ve varlık bağlantıları. Bu, proje kapanışında veya müşteri ekip değiştirdiğinde özellikle kullanışlıdır.

İyi yapılmışsa bu bölüm kafa karışıklığını azaltır, her iki tarafı da korur ve kampanya yönetimi yazılımınızın güvenilir hissetmesini sağlar—karmaşık değil.

Raporlama, Entegrasyonlar ve Pratik Yol Haritası

Raporlama ve entegrasyonlar kampanya onay uygulamasının kapsamını hızla büyütebilir. Püf nokta, ekiplerin günlük işi yürütmesine yardımcı olan en küçük seti yayınlamak ve gerçek kullanım verisine göre genişletmektir.

“Dikkat gerektiren”i yanıtlayan raporlamayla başlayın

Basit raporlama görünümüyle (veya pano widget'larıyla) haftalık durum kontrolleri ve günlük triajı destekleyin:

• Bekleyen onaylar: müşteri veya dahili inceleyici bekleyen öğeler
• Çevrim süresi: "incelemeye hazır" ile "onaylandı" arasındaki ortalama süre (aşamaya göre)
• Geciken öğeler: teslim tarihi geçmiş onaylar ve görevler, şu anki sahipleriyle

Sonra kampanya sağlık göstergeleri ekleyin:

• Zamanında: kilometre taşları ve onaylar beklenen zaman çizelgesinde
• Riskte: yaklaşan tarihler + yavaş çevrim süresi trendleri
• Engellendi: eksik girdiler, çözülmemiş geri bildirim veya belirli bir onaycı bekleniyor

Bunlar mükemmel tahmin gerektirmez—sadece net sinyaller ve tutarlı kurallar yeterlidir.

Entegrasyonları dikkatle planlayın (ve kazanın)

Entegrasyonlar manuel takipleri azaltmalı, yeni hata modları yaratmamalı. Kullanıcıların günlük alışkanlıklarına göre önceliklendirin:

• E-posta davetler, inceleme istekleri ve karar onayları için
• Slack hızlı bildirimler ve hatırlatıcılar için (mesajları eyleme geçirilebilir tutun)
• Takvim önemli inceleme kilometre taşları için (isteğe bağlı ama faydalı)
• Depolama (bulut sürücüler) ekipler zaten kaynak dosyaları başka yerde saklıyorsa
• CRM sadece kampanya verilerinin hesaplarla/hislerle hizalanması gerekiyorsa

API ve webhook'lar: aşırı inşa etmeden geleceğe hazırlayın

Hemen herkese açık API yayınlamasanız bile genişletme stratejisi belirleyin:

• Küçük bir webhook seti (onay verildi, yorum eklendi, varlık sürümü oluşturuldu)
• Kararlı bir olay şeması ve yeniden deneme davranışı
• Daha sonra version'lanmış bir API planı (önce dahili, belgeleyerek ilerleyin)

Pratik yol haritası

Phase 1: temel panolar + bekleyen/geciken listeleri.

Phase 2: sağlık göstergeleri + çevrim süresi trendleri.

Phase 3: 1–2 yüksek etkili entegrasyon (genellikle e-posta + Slack).

Phase 4: webhook'lar ve partner hazır API.

Eğer raporlama ve entegrasyonlar için paket katmanları düşünüyorsanız, basit ve şeffaf tutun (bkz. /pricing). Hızlı bir MVP yoluna ihtiyacınız varsa, Koder.ai burada da faydalı olabilir: planlama modunda onay iş akışını yineleyebilir, barındırılan bir yapı dağıtıp geri alarak gereksinimleri rafine edebilirsiniz.

Daha derin iş akışı kalıpları için ilgili rehberlere /blog üzerinden bakabilirsiniz.