Byråer
Én trakt, tjue kunder, tjue omdømmer holdt adskilt
Et byrå på tre personer som driver markedsføring for tjue lokale bedrifter har det samme problemet tjue ganger og den samme løsningen tjue ganger — bortsett fra at hver kundes liste, avsenderidentitet, domene og samtykkeregister må forbli helt deres eget. Det interessante arbeidet ligger i det «bortsett fra».
Ett prosjekt per kunde, og grensen er databasens jobb
Alt her er avgrenset til en tenant og et prosjekt sammen — kontakter, trakter, kreative, kampanjer, avsenderidentiteter, rapporter. Denne avgrensningen håndheves av sikkerhet på radnivå i databasen, ikke av en klausul noen må huske å legge til en spørring. Et glemt prosjekt ser ingenting, i stedet for første prosjektets rader.
Det betyr at en kundes liste ikke kan lekke inn i en annen kundes kampanje ved en feil, og det betyr at en rapport handler om én kunde fordi den strukturelt ikke kan handle om to.
Hver kunde sender som seg selv
En avsenderidentitet tilhører et prosjekt: deres domene, deres DKIM-nøkler, deres postkasse eller leverandørkonto, deres taktfrekvens. Én kundes uheldige kampanje kan ikke skade en annen kundes leveransedyktighet, fordi de aldri delte noe som kan skades.
Det løser også en ubehagelig samtale tidlig. Kunden eier sin sending, sin liste og sitt samtykkeregister. Når de forlater deg — og noen vil gjøre det — tar de med seg alt, og du har ikke bygget en gisselsituasjon du måtte forklare.
- 1KontakterPer prosjekt. Håndhevet i databasen, ikke av en spørring du må huske.
- 2SendingDeres domene, deres DKIM, deres postkasse eller leverandør, deres taktfrekvens.
- 3SamtykkeDeres logg. Den følger med dem, bevis inkludert, hvis de forlater deg.
- 4RapporterPer prosjekt av konstruksjon. Det finnes ingen måte å ved et uhell aggregere to kunder på.
- iDet du beholderTraktdefinisjonene og måten du jobber på. Det er produktet ditt, og det er delen som er verdt å gjenbruke.
Ingen delt omdømmeIngen delt liste
Gjenbruk uten kopier-lim inn
Bygg trakten én gang. Rull den ut så mange ganger du har kunder.
En trakt er en graf, og en graf er JSON med et publisert skjema. Det betyr at det du gjenbruker er et dokument, ikke et skjermbilde av et skjermbilde du må bygge opp igjen for hånd i hver konto.
Dine egne trakter
Velkommen, forlatt handlekurv, uteblitt møte, intervall, win-back. Skrevet én gang av den som er best på det, oppbevart i ditt eget repo, og opprettet i et kundeprosjekt med ett API-kall.
Kontrollert på samme måte overalt
Validatoren kjører på trakten din i hvert prosjekt den havner i. En graf som ville loope uten et ventesvaret, eller sende uten et emnefelt, avvises der akkurat som den ville blitt her.
Simulert før den kjører
Kjør en tørrtest med en ekte kontakt fra den kundens liste gjennom trakten og les tilbake hva den ville sendt dem. Gjør det én gang per utrulling, og samtalen «det gikk feil ut» slutter å skje.
Forbedret på ett sted
Når du lærer noe — den andre påminnelsen fungerer bedre klokka ti om morgenen — endrer du definisjonen din og ruller den fremover. Kundene som allerede kjører den gamle versjonen fullfører på den gamle versjonen; ingen som er underveis forstyrres.
Kreative også
En kreativ er et dokument med flettevariabler. Den samme velkomst-e-posten, rendret med hver kundes merkevare, farger og logo — hentet fra deres egen nettside ved første kjøring.
Eller la en agent gjøre det
Pek en assistent mot MCP-serveren, avgrenset til ett prosjekt, og la den utarbeide og kontrollere trakten for den kunden. Alt som når en ekte person krever fortsatt en eksplisitt bekreftelse og holder seg innenfor kvoten.
Elleve kunder, elleve avsendere, ett sted å se.
Problemet med månedsrapporten
Det meste av et byrås rapporteringsplager handler ikke om å produsere tall. Det handler om å produsere tall som overlever at kunden stiller et oppfølgingsspørsmål, og å produsere dem uten tre timer med skjermbilder den første i måneden.
To ting hjelper her. Rapporter er API-ruter, så målepakken kan settes sammen av et skript og eksporteres som en PDF i stedet for av en person og et regneark. Og tallene er ærlige på botter: rå og filtrerte er begge tilgjengelige, merket, så når en kunde spør hvorfor åpningsraten falt etter at de flyttet, kan du forklare det i én setning i stedet for å forsvare det i fire.
De samme flisene havner i dash-b — kampanjeresultater, trakt-frafall, listevekst, leverbarhet per domene — så en kunde som vil ha et levende bord kan få ett, på sin egen konto, med sine egne påloggingsdata og ingen nøkkel fra deg på siden.
- 1For hvert prosjektÉn token, ett prosjektomfang, det samme skriptet.
- 2HentKampanjeresultater, trakt-frafall, listevekst, leverbarhet per domene.
- 3RendreDeres kreative dokument som rapportside, og deretter til PDF.
- 4SendEller legg det inn i brettet deres. Hva enn den kunden faktisk leser.
- iHva som har endret segTre timer med skjermbilder ble en planlagt jobb, for rapportene var ruter hele tiden.
Rå og filtrert, begge merket
Samtalen om samtykke, tatt tidlig
Hvert byrå har møtt kunden som kommer med et regneark med fire tusen adresser og et vagt svar på hvor de kom fra. Her er ikke det et argument du må vinne; det er et felt.
Importen havner som berettiget interesse på det beste, aldri som samtykke, og grunnlagsmiksen vises før noen kampanje går ut. Hvis en liste ikke kan sendes til, sier den det ved importen i stedet ved en klage. Det gjør en ubehagelig skjønnsvurdering til en felles lesing av samme skjerm — noe som er en mye bedre posisjon for deg når kunden insisterer.
Verdt å si høyt til kunden: omdømmet som risikeres av en dårlig liste er deres, på deres eget domene, fordi hvert prosjekt sender som seg selv. Det er et sterkere argument enn noen forskrift, og det er det som pleier å bite.