Byråer
En tratt, tjugo kunder, tjugo separata rykten
En byrå med tre anställda som driver marknadsföring för tjugo lokala företag har samma problem tjugo gånger och samma lösning tjugo gånger — förutom att varje kunds lista, avsändaridentitet, domän och samtyckesregister måste förbli helt deras eget. Det intressanta arbetet ligger i det "förutom".
Ett projekt per kund, och gränsen är databasens jobb
Allt här är avgränsat till en tenant och ett projekt tillsammans — kontakter, trakter, kreativa material, kampanjer, avsändaridentiteter, rapporter. Den avgränsningen verkställs av säkerhet på radnivå i databasen, inte av en klausul som någon måste komma ihåg att lägga till i en fråga. Ett glömt projekt ser ingenting i stället för första projektets rader.
Vilket innebär att en kunds lista inte kan läcka in i en annan kunds kampanj av misstag, och det innebär att en rapport handlar om en kund eftersom den strukturellt inte kan handla om två.
Varje kund skickar som sig själv
En avsändaridentitet tillhör ett projekt: deras domän, deras DKIM-nycklar, deras postlåda eller deras leverantörskonto, deras hastighetsgräns. En kunds misslyckade kampanj kan inte skada en annan kunds leveransförmåga, eftersom de aldrig delade något som kunde skadas.
Det löser också ett obekvämt samtal i tid. Kunden äger sitt utskick, sin lista och sitt samtyckesregister. När de lämnar — och vissa kommer att göra det — lämnar de med alltihop, och du har inte byggt en gisslansituation som du skulle behöva förklara.
- 1KontakterPer projekt. Verkställd i databasen, inte av en fråga du måste komma ihåg.
- 2UtskickDeras domän, deras DKIM, deras postlåda eller leverantör, deras hastighetsgräns.
- 3SamtyckeDeras register. Det följer med dem, bevis inkluderat, om de lämnar.
- 4RapporterPer projekt genom konstruktion. Det finns inget sätt att av misstag aggregera två kunder.
- iVad du behållerTrattdefinitionerna och ditt arbetssätt. Det är din produkt, och det är den del som är värd att återanvända.
Inget delat rykteIngen delad lista
Återanvändning utan kopiera-klistra in
Bygg tratten en gång. Distribuera den så många gånger som du har kunder.
En tratt är en graf, och en graf är JSON med ett publicerat schema. Vilket betyder att det du återanvänder är ett dokument, inte en skärmbild av en skärm som du måste bygga om för hand i varje konto.
Dina standardtrakter
Välkommen, övergiven varukorg, uteblivet besök, intervall, vinn tillbaka. Skrivna en gång av den som är bäst på det, sparade i ditt eget arkiv och skapade i ett kundprojekt med ett API-anrop.
Kontrollerade på samma sätt överallt
Valideraren körs på din tratt i varje projekt den hamnar i. En graf som skulle loopa utan en väntan, eller skicka utan ett ämne, avvisas där precis som den skulle avvisas här.
Simulerad innan den körs
Kör en testkörning med en riktig kontakt från den kundens lista genom tratten och läs tillbaka vad den skulle skicka dem. Gör det en gång per distribution och samtalet "det gick ut fel" slutar hända.
Förbättrad på ett ställe
När du lär dig något — den andra påminnelsen fungerar bättre klockan tio på förmiddagen — ändrar du din definition och rullar den framåt. Kunderna som redan kör den gamla versionen avslutar på den gamla versionen; ingen på väg störs.
Kreativa material också
Ett kreativt material är ett dokument med sammanfogningsvariabler. Samma välkomstmejl, renderat med varje kunds varumärke, färger och logotyp — hämtat från deras egen webbplats vid första körningen.
Eller låt en agent göra det
Peka en assistent mot MCP-servern, avgränsad till ett projekt, och låt den utarbeta och kontrollera tratten för den kunden. Allt som når en riktig person kräver fortfarande en uttrycklig bekräftelse och stannar inom kvoten.
Elva kunder, elva avsändare, ett ställe att titta på.
Problemet med månadsrapporten
Det mesta av en byrås rapporteringsproblem handlar inte om att ta fram siffror. Det handlar om att ta fram siffror som överlever kundens uppföljningsfråga, och att ta fram dem utan tre timmars skärmdumpar den första i månaden.
Två saker hjälper här. Rapporter är API-rutter, så månadspaketet kan sättas ihop av ett skript och exporteras som PDF i stället för av en person och ett kalkylblad. Och siffrorna är ärliga om bottar: rå och filtrerad data finns båda tillgängliga, märkta, så när en kund frågar varför öppningsfrekvensen sjönk efter att de flyttade kan du förklara det på en mening i stället för att försvara det i fyra.
Samma rutor hamnar i dash-b — kampanjprestanda, tratträffar i trattens steg, listtillväxt, leveransförmåga per domän — så en kund som vill ha en live-panel kan få en, på sitt eget konto, med sina egna inloggningsuppgifter och ingen nyckel från dig på sidan.
- 1För varje projektEn token, ett projektscope, samma skript.
- 2HämtaKampanjprestanda, tratträffar i trattens steg, listtillväxt, leveransförmåga per domän.
- 3RenderaDeras kreativa dokument som rapportsida, sedan till PDF.
- 4SkickaEller lägg in i deras panel. Vilket den kunden faktiskt läser.
- iVad som har ändratsTre timmars skärmdumpar blev ett schemalagt jobb, för att rapporterna var rutter hela tiden.
Rå och filtrerad, båda märkta
Samtalet om samtycke, fört i tid
Varje byrå har mött kunden som dyker upp med ett kalkylblad med fyra tusen adresser och ett vagt svar om var de kommer ifrån. Här är det inte en diskussion du måste vinna; det är ett fält.
Importen landar som berättigat intresse i bästa fall, aldrig som samtycke, och grundlagsblandningen visas innan någon kampanj går ut. Om en lista inte kan skickas till står det vid importtillfället i stället för vid klagomålet. Det gör ett obekvämt ställningstagande till en gemensam läsning av samma skärm — vilket är en mycket bättre position för dig när kunden insisterar.
Värt att säga högt till kunden: det rykte som riskeras av en dålig lista är deras, på deras egen domän, eftersom varje projekt skickar som sig självt. Det är ett starkare argument än någon lagstiftning, och det är det som brukar slå igenom.