Агентства
Один фунел, двадцять клієнтів, двадцять репутацій, які залишаються окремими
Агентство з трьох людей, що веде маркетинг для двадцяти локальних бізнесів, має одну й ту саму проблему двадцять разів — і те саме рішення двадцять разів. З тією лише різницею, що список контактів, ідентичність відправника, домен і записи згоди кожного клієнта мають повністю залишатися його власними. Найцікавіша робота — саме в цьому «з тією лише різницею».
Проєкт на клієнта, а межі забезпечує база даних
Усе тут має область видимості в межах тенанта та проєкту разом — контакти, фунели, креативи, кампанії, ідентичності відправника, звіти. Це обмеження забезпечується безпекою на рівні рядків у базі даних, а не умовою, яку хтось мусить пам'ятати, додаючи до запиту. Забутий проєкт не бачить нічого, а не рядки першого проєкту.
Це означає, що список одного клієнта не може помилково потрапити в кампанію іншого клієнта, і що звіт стосується одного клієнта, бо структурно не може стосуватися двох.
Кожен клієнт надсилає листи від свого імені
Ідентичність відправника належить проєкту: їхній домен, їхні ключі DKIM, їхня скринька або акаунт у провайдера, їхній ліміт частоти. Невдала кампанія одного клієнта не може зашкодити доставлюваності іншого, бо їм нічого спільного, що можна було б зіпсувати.
Це також рано знімає незручну розмову. Клієнт володіє своїм надсиланням, своїм списком і своїм записом згоди. Коли він піде — а деякі підуть, — він піде з усім цим, і ви не створите ситуацію із заручником, яку потім довелося б пояснювати.
- 1КонтактиНа проєкт. Забезпечується базою даних, а не запитом, який треба пам'ятати.
- 2НадсиланняЇхній домен, їхній DKIM, їхня скринька або провайдер, їхній ліміт частоти.
- 3ЗгодаЇхній журнал обліку. Він подорожує разом із ними, разом із доказами, якщо вони підуть.
- 4ЗвітиНа проєкт за самою конструкцією. Випадково об'єднати двох клієнтів неможливо.
- iЩо залишається у васВизначення фунелів і ваш підхід до роботи. Це ваш продукт, і саме ця частина варта повторного використання.
Спільної репутації немаєСпільного списку немає
Повторне використання без копіювання
Побудуйте фунел один раз. Розгорніть його стільки разів, скільки у вас клієнтів.
Фунел — це граф, а граф — це JSON з опублікованою схемою. А отже, те, що ви повторно використовуєте, — це документ, а не знімок екрана, який довелося б вручну відтворювати в кожному акаунті.
Ваші фірмові фунели
Вітальний, покинутий кошик, неявка на зустріч, інтервальний, повернення клієнта. Написані один раз тим, хто найкраще в цьому розуміється, збережені у вашому власному репозиторії та створені в проєкті клієнта одним викликом API.
Перевіряються однаково всюди
Валідатор перевіряє ваш фунел у кожному проєкті, куди він потрапляє. Граф, який зациклився б без очікування або надсилав би лист без теми, відхиляється там так само, як і тут.
Симулюється перед запуском
Запустіть тестовий прогін реального контакту зі списку цього клієнта крізь фунел і прочитайте, що йому було б надіслано. Зробіть це один раз на кожне розгортання — і розмова «лист пішов не так» просто перестане відбуватися.
Покращується в одному місці
Коли ви дізнаєтеся щось нове — друге нагадування краще працює о десятій ранку, — ви змінюєте своє визначення й розгортаєте його далі. Клієнти, які вже працюють зі старою версією, завершують на старій версії; нікого на середині шляху не турбують.
Креативи теж
Креатив — це документ зі змінними для підстановки. Той самий вітальний лист, відображений з брендом, кольорами та логотипом кожного клієнта — зчитаними з його власного вебсайту під час першого запуску.
Або доручіть це агенту
Спрямуйте асистента на MCP-сервер, обмежений одним проєктом, і доручіть йому підготувати та перевірити фунел для цього клієнта. Усе, що доходить до реальної людини, досі потребує явного підтвердження і залишається в межах квоти.
Одинадцять клієнтів, одинадцять відправників, одне місце, куди дивитися.
Проблема місячного звіту
Більша частина звітного болю агентства — це не отримання чисел. Це отримання чисел, які витримують наступне запитання клієнта, і отримання їх без трьох годин знімків екрана першого числа місяця.
Тут допомагають дві речі. Звіти — це маршрути API, тож місячний пакет може зібрати скрипт і експортувати як PDF, а не людина з таблицею. І числа чесні щодо ботів: сирі та відфільтровані значення обидва доступні, з підписами, тож коли клієнт запитає, чому після переїзду впала відкриваність, ви поясните це одним реченням, а не виправдовуватиметеся чотирма.
Ті самі плитки з’являються в dash-b — ефективність кампаній, відтік у воронці, зростання списку, доставлюваність за доменами — тож клієнт, якому потрібна жива панель, може її мати: на власному акаунті, з власними обліковими даними і без жодного вашого ключа на сторінці.
- 1Для кожного проєктуОдин токен, один проєкт, той самий сценарій.
- 2ЗавантажитиЕфективність кампаній, відтік у воронці, зростання списку, доставлюваність за доменами.
- 3РендерингЇхній творчий документ як сторінка звіту, а потім у PDF.
- 4НадіслатиАбо додайте на їхню панель. Куди той клієнт справді заглядає.
- iЩо змінилосяТри години скриншотів стали запланованим завданням, бо звіти все це час були просто маршрутами.
Сирі та відфільтровані, обидва з підписами
Розмова про згоду, проведена заздалегідь
Кожне агентство знало клієнта, який приходить із таблицею на чотири тисячі адрес і невизначеною відповіддю про їхнє походження. Тут це не аргумент, який вам треба виграти; це просто поле.
Такий імпорт зараховується щонайбільше як законний інтерес, ніколи як згода, і розподіл підстав показується до того, як кампанія вийде. Якщо список не можна надсилати, це з’являється в момент імпорту, а не в момент скарги. Це перетворює незручне суб’єктивне рішення на спільне читання одного екрана — а це значно краща позиція для вас, коли клієнт наполягає.
Варто сказати клієнтові вголос: репутація, яку ризикує зіпсувати поганий список, — це їхня репутація, на їхньому власному домені, бо кожен проєкт надсилає від свого імені. Це сильніший аргумент, ніж будь-який регламент, і саме він зазвичай подіє.