Ajansların kampanyaları, varlıkları ve müşteri onaylarını roller, iş akışları ve denetlenebilir geçmişle yönetebileceği bir web uygulamasını planlamayı ve inşa etmeyi öğrenin.
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.
Çoğu ajans onay iş akışı dört grup içerir ve her birinin farklı ihtiyaçları vardır:
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.
Ürünün işe yarayıp yaramadığını değerlendirebilmek için ölçülebilir sonuçlar tanımlayın:
v1 için kampanyaları ve onayları birlikte tutacak en küçük sete odaklanın:
İyi olanakları sonradan ekleyin: gelişmiş raporlama, derin entegrasyonlar, otomasyon kuralları ve özel onay yolları.
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.
Çoğu kampanya onay uygulaması küçük bir yapıtaşı setiyle tanımlanabilir:
İlişkileri belgeleyin: bir kampanya projeleri içerir; projeler görevleri içerir; görevler varlık üretir; varlıklar onaylardan geçer.
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.
Üründeki geri bildirim formatını karar verin:
Anahtar, geri bildirimi bir varlık sürümüne bağlamaktır, böylece hangi dosyanın incelendiği konusunda tartışma olmaz.
Yaygın yavaşlamalar: inceleyicilerin beklemesi, belirsiz sonraki adımlar ve tekrarlayan kurulum. En çok yardımcı olan otomasyonlar:
Gerçek onaylar her zaman temiz olmaz. Planlayın:
Bu kuralları düz bir dille açıklayabiliyorsanız, ekranlara ve veri modellerine dönüştürmeye hazırsınız.
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.
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.
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.
Hızlı filtreler yaygın ajans sorularını yanıtlamalı:
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.
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.
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ı.
Çoğu ajans ihtiyaçların çoğunu beş rol ile karşılayabilir:
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üş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.
Teslimat başına iki onay modu destekleyin:
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.
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.
Herkesin tanıyacağı küçük bir durum setiyle başlayın:
Her kenar durumu için yeni bir durum eklemekten kaçının. Daha fazla nüans gerekirse etiketler (ör. “hukuk incelemesi”) kullanı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.
Sadece serbest biçimli yorumlar karmaşadır. Yapı ekleyin:
Zaman kodları (video) veya sayfa/alan pinleri (PDF/görseller) desteklenirse geri bildirim çok daha uygulanabilir olur.
Birisi onayladığında kaydedin:
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.
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.
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.
Çoğu iş akışını kapsayan küçük bir set hedefleyin:
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 incelemeyi hızlandırır ve müşteriye daha dost canlısı olur. Üretin:
Bu, paydaşların tam çözünürlük dosyalarını indirmeden teslimat panosunu taramasını sağlar.
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.
Onaylar genellikle izlenebilirlik gerektirir. "Silme"nin ne anlama geldiğini belirleyin:
Bunu kampanya bitiminden sonra 12–24 ay saklama gibi saklama politikalarıyla eşleştirin ki depolama maliyetleri kontrolden çıkmasın.
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.
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.
Ö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ı.
Ç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.
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.
Başından üç ortam planlayın:
Veri tarafına daha derin girmek isterseniz, /blog/data-model-and-database-design ile devam edin.
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.
Ajansların gerçek çalışmasına uyan küçük bir tablo setiyle başlayın:
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.
Sadece durumlar ne olduğunu açıklamaz. Aşağıdaki gibi tablolar ekleyin:
Bu, denetim izlerini ve hesap verebilirliği çekirdek tabloları şişirmeden kolaylaştırır.
Çoğu ekran müşteri, durum ve teslim tarihi ile filtreler. Aşağıdaki indeksleri ekleyin:
Ayrıca “şimdi inceleme gereken” için bileşik bir indeks düşünün: (organization_id, status, updated_at).
Ş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.
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.
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 hızlı, role duyarlı ve affedici olmalı:
İyi bir desen, yeni kullanıcıların parola hatırlamak zorunda kalmaması için magik link ile parola ayarlamaktır.
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ı.
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.
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 kampanya uygulamalarını ya yardımcı ya da yorucu yapar. Amaç: işi ilerletmek, her yorumu gelen kutusu yangınına çevirmemek.
Başlangıç için küçük, yüksek sinyal tetikleyicilerle başlayın ve bunları e-posta ile uygulama içinde tutarlı yapın:
Her bildirime “ne” ve bir sonraki eylemi (doğrudan doğru görünüme bağlanan) dahil edin.
Farklı roller farklı detay seviyeleri ister. Kullanıcı düzeyinde kontrol verin:
Akıllı varsayılanlar kullanın: müşteriler genellikle iç ekipten daha az e-posta ister.
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:
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).
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.
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.
İki seviyede etkinlik akışı uygulayın:
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.”
Hesap verebilirlik için şunların denetim izini tutun:
Pratik bir kural: bir etkinlik teslimatı, zamanı veya müşteri onayını etkiliyorsa denetim izine dahil edin.
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.
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 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.
Basit raporlama görünümüyle (veya pano widget'larıyla) haftalık durum kontrolleri ve günlük triajı destekleyin:
Sonra kampanya sağlık göstergeleri ekleyin:
Bunlar mükemmel tahmin gerektirmez—sadece net sinyaller ve tutarlı kurallar yeterlidir.
Entegrasyonlar manuel takipleri azaltmalı, yeni hata modları yaratmamalı. Kullanıcıların günlük alışkanlıklarına göre önceliklendirin:
Hemen herkese açık API yayınlamasanız bile genişletme stratejisi belirleyin:
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.
Öncelikle temel sorunu tanımlayın: onaylar ve geri bildirimler e-posta/sohbet/dosyalarda dağınık. V1'iniz briefleri, varlıkları, geri bildirimleri ve onayı merkezileştirmeli ki her paydaş hızla cevaplayabilsin:
Onay dönüş süresi ve revizyon döngüleri gibi ölçülebilir sonuçlarla kapsamı sınırlayın.
Dört ortak grup etrafında tasarlayın:
Sadece iç kullanıcılara odaklanırsanız müşteri benimsemesi (ve onay hızı) genellikle düşer.
Gerçek iş akışı sürtüşmesine bağlı küçük bir metrik seti seçin:
Bunları erken ölçümlendirin ki v1 yayınlandıktan sonra iyileşmeleri doğrulayabilesiniz.
Pratik bir v1 şunları içermeli:
Gelişmiş raporlama, derin entegrasyonlar, otomasyon kuralları ve özel onay yollarını daha sonra erteleyin.
İş akışını birkaç temel nesneyle modelleyin:
Bir onay yaşam döngüsü (ör. Taslak → İç inceleme → Müşteri incelemesi → Onaylandı) tanımlayın; her durumun operasyonel bir anlamı olsun (kimi gerektirir, hangi koşullar sağlanmalı, sonra ne olur).
Geri bildirimi her zaman bir varlık sürümüne bağlayın ki “hangi dosya?” tartışmaları olmasın. İyi seçenekler şunlar:
Yapı, geri işi azaltır çünkü geri bildirim eyleme geçirilebilir ve hesap verebilir olur.
Gezinmeyi basit bir hiyerarşi etrafında tutun: Müşteri → Kampanya → Teslimatlar (varlıklar). Günlük kullanılan ekranlar:
Süzgeçler: müşteri, teslim tarihi, durum, atanan kişi gibi gerçek soruları yanıtlamalı.
Çoğu ajans için gereken rolleri basit tutun:
Sonra izinleri nesne başına tanımlayın (kampanya, varlık, yorum, onay): görüntüle, yorum yap, yükle, onayla, düzenle, sil gibi. "En az ayrıcalık" varsayılanı uygulayın ve kontrolleri yalnızca UI gizlemeyle bırakmayın.
Her yüklemeyi yeni, değiştirilemez bir sürüm (v1, v2, v3…) olarak ele alın. Dosyaları yerinde ezmeyin.
Onay meta verilerini kaydedin:
Genellikle onaylı sürümü kilitleyin ama yeni bir sürüm oluşturmaya izin verin (bu durumda durum yeniden In Review olur).
v1 için yeterli bir mimari şunlardır:
v1'de modüler bir monolit + işçi süreci, birçok servise bölünmüş mimariden daha kolaydır.
