Ajanslar

Tek huni, yirmi müşteri, yirmi birbirinden ayrı tutulan itibar

Yirmi yerel işletme için pazarlama yürüten üç kişilik bir ajansın aynı sorunu yirmi kez ve aynı çözümü yirmi kez vardır — tek fark, her müşterinin listesinin, gönderim kimliğinin, alan adının ve onay kaydının tamamen kendine ait kalması zorunluluğudur. Asıl ilginç iş o "tek fark" içindedir.

Müşteri başına bir proje ve sınırın sorumlusu veritabanıdır

Buradaki her şey bir kiracı ve bir projeyle birlikte kapsamlanır — kişiler, huniler, yaratıcılar, kampanyalar, gönderim kimlikleri, raporlar. Bu kapsamlandırma, bir sorguya eklenmesi gereken bir madde olarak hatırlanması gereken bir şey değil, veritabanında satır düzeyi güvenlikle uygulanır. Projesini unutan biri, ilk projenin satırlarını değil hiçbir şey görür.

Bu, bir müşterinin listesinin yanlışlıkla başka bir müşterinin kampanyasına sızamayacağı anlamına gelir; bir raporun tek bir müşteriyle ilgili olması da yapısal olarak iki müşteriyle ilgili olamayacağı içindir.

Her müşteri kendi adına gönderir

Bir gönderim kimliği bir projeye aittir: kendi alan adları, kendi DKIM anahtarları, kendi posta kutuları veya sağlayıcı hesapları, kendi hız sınırları. Bir müşterinin başarısız kampanyası başka bir müşterinin teslim edilebilirliğine zarar veremez, çünkü zarar verecek paylaşılan hiçbir şey hiç olmadı.

Ayrıca zor bir konuşmayı baştan çözer. Gönderim, liste ve onay kaydı müşteriye aittir. Ayrıldıklarında — bazıları ayrılacaktır — hepsini yanlarında götürürler ve açıklamanız gereken bir rehin durumunu yaratmamış olursunuz.

Yirmi proje, tek ajansKapsamlandırma

1KişilerProje başına. Veritabanında uygulanır, hatırlamanız gereken bir sorguyla değil.
2GönderimKendi alan adları, kendi DKIM'leri, kendi posta kutuları veya sağlayıcıları, kendi hız sınırları.
3OnayKendi kayıtları. Ayrılırlarsa kanıtlarıyla birlikte yanlarında gider.
4RaporlarYapı gereği proje başına. İki müşteriyi yanlışlıkla birleştirmenin hiçbir yolu yoktur.
iSizin sakladığınızHuni tanımları ve çalışma biçiminiz. Ürününüz odur ve yeniden kullanılmaya değer kısım da budur.

Paylaşılan itibar yokPaylaşılan liste yok

Kopyala-yapıştır olmadan yeniden kullanım

Huniyi bir kez oluşturun. Müşteri sayınız kadar dağıtın.

Bir huni bir grafiktir ve grafik, yayımlanmış şeması olan bir JSON'dur. Yani yeniden kullandığınız şey bir belgedir; her hesapta elle yeniden inşa etmeniz gereken bir ekran görüntüsü değil.

Kurumsal hunileriniz

Karşılama, terk edilen sepet, gelmeme, aralıklı, geri kazanım. Bu işte en iyisi olan kişi tarafından bir kez yazılır, kendi deponuzda tutulur ve tek bir API çağrısıyla bir müşteri projesinde oluşturulur.

Her yerde aynı şekilde denetlenir

Doğrulayıcı, huninizin geldiği her projede çalışır. Bekleme olmadan döngüye girecek veya konu olmadan gönderecek bir grafik, burada reddedileceği gibi orada da reddedilir.

Çalışmadan önce simüle edilir

O müşterinin listesinden gerçek bir kişiyi huniden kuru çalıştırmayla geçirin ve ona ne gönderileceğini okuyun. Her dağıtımda bir kez yapın; "yanlış gitti" konuşması bir daha yaşanmaz.

Tek yerde geliştirilir

Bir şey öğrendiğinizde — ikinci hatırlatma sabah onda daha iyi çalışıyor gibi — tanımınızı değiştirir ve ileri sararsınız. Eski sürümü çalıştıran müşteriler eski sürümle bitirir; yolda olan kimse etkilenmez.

Yaratıcılar da öyle

Bir yaratıcı, birleştirme değişkenleri içeren bir belgedir. Aynı karşılama e-postası, her müşterinin markası, renkleri ve logosuyla — ilk çalıştırmada kendi web sitelerinden alınarak — işlenir.

Ya da bir ajan yapsın

Bir asistanı tek bir projeye kapsamlanmış MCP sunucusuna yönlendirin ve o müşteri için huniyi taslaklaştırıp denetlesin. Gerçek bir kişiye ulaşan her şey yine açık bir onay gerektirir ve kota içinde kalır.

On bir müşteri, on bir gönderici, tek bir bakılacak yer.

Aylık rapor sorunu

Bir ajansın raporlama derdinin çoğu sayı üretmek değildir. Asıl mesele, müşterinin bir soru sorduğunda ayakta kalan sayılar üretmek ve bunu ayın birinde üç saatlik ekran görüntüsü alma derdi olmadan üretmektir.

Burada iki şey yardımcı olur. Raporlar API rotalarıdır, dolayısıyla aylık paketi bir kişi ve bir tablo yerine bir betik toplayıp PDF olarak dışa aktarabilir. Ve sayılar botlar konusunda dürüsttür: ham ve filtrelenmiş değerlerin ikisi de etiketlenmiş olarak mevcuttur; böylece müşteri taşınma sonrası açılma oranının neden düştüğünü sorduğunda, dört cümleyle savunmak yerine tek cümleyle açıklayabilirsiniz.

Aynı kutucuklar dash-b içinde de yer alır — kampanya performansı, huni kayıpları, liste büyümesi, alan adına göre iletilebilirlik — böylece canlı bir pano isteyen müşteriye kendi hesabında, kendi kimlik bilgileriyle ve sayfanızda sizin anahtarınız olmadan bir pano sunabilirsiniz.

Ayın ilk günüBetikleştirilmiş

1Her proje içinTek token, tek proje kapsamı, aynı betik.
2ÇekKampanya performansı, huni kayıpları, liste büyümesi, alan adına göre iletilebilirlik.
3OluşturunMüşterinin yaratıcı belgesi bir rapor sayfası olarak, ardından PDF'e.
4GönderYa da doğrudan müşterinin panosuna bırakın. Hangisini gerçekten okuyorsa onu.
iNeler değiştiEkran görüntüleriyle geçen üç saat, zamanlanmış bir işe dönüştü; çünkü raporlar baştan beri rota idi.

Ham ve filtrelenmiş, ikisi de etiketli

Onay konuşması, erkenden yapılmış haliyle

Her ajans, dört bin adreslik bir tablo ve adreslerin nereden geldiğine dair belirsiz bir cevapla gelen müşteriyle tanışmıştır. Burada bu, kazanmanız gereken bir tartışma değil; bir alandır.

İçe aktarma en iyi ihtimalle meşru menfaat olarak kaydedilir, asla rıza olarak değil; ve temel karışımı hiçbir kampanya gönderilmeden önce gösterilir. Bir listeye gönderilemiyorsa, bu şikâyet anında değil, içe aktarma anında belirtilir. Bu, rahatsız edici bir muhakeme kararını aynı ekranın ortak okumasına dönüştürür — müşteri ısrar ettiğinde bulunabileceğiniz çok daha iyi bir konumdur bu.

Müşteriye yüksek sesle söylemeye değer: Kötü bir listeyle riske atılan itibar, her proje kendi adına gönderdiği için müşterinin kendi alan adında ve kendisine aittir. Bu, herhangi bir düzenlemeden daha güçlü bir argümandır ve genellikle işe yarayan da budur.