Agences
Un tunnel, vingt clients, vingt réputations maintenues séparées
Une agence de trois personnes qui gère le marketing de vingt commerces locaux a le même problème vingt fois, et la même solution vingt fois — sauf que la liste, l'identité d'envoi, le domaine et le registre de consentement de chaque client doivent rester entièrement les siens. Le travail intéressant se trouve dans ce « sauf ».
Un projet par client, et la frontière est l'affaire de la base de données
Tout ici est limité à un tenant et à un projet ensemble — contacts, tunnels, créations, campagnes, identités d'envoi, rapports. Ce cloisonnement est appliqué par la sécurité au niveau des lignes dans la base de données, et non par une clause que quelqu'un doit penser à ajouter à une requête. Un projet oublié ne voit rien, plutôt que les lignes du premier projet.
Cela signifie que la liste d'un client ne peut pas fuiter par erreur dans la campagne d'un autre client, et qu'un rapport porte sur un seul client parce qu'il ne peut structurellement pas en porter sur deux.
Chaque client envoie en son nom propre
Une identité d'envoi appartient à un projet : son domaine, ses clés DKIM, sa boîte mail ou son compte fournisseur, son plafond de débit. La campagne malheureuse d'un client ne peut pas nuire à la délivrabilité d'un autre client, parce qu'ils n'ont jamais rien partagé qui puisse être endommagé.
Cela règle aussi, et tôt, une conversation embarrassante. Le client est propriétaire de ses envois, de sa liste et de son registre de consentement. Quand il part — et certains partiront — il part avec tout cela, et vous n'avez pas construit une situation d'otage que vous devriez justifier.
- 1ContactsPar projet. Appliqué dans la base de données, pas par une requête que vous devez vous rappeler.
- 2EnvoiLeur domaine, leur DKIM, leur boîte mail ou fournisseur, leur plafond de débit.
- 3ConsentementLeur registre. Il voyage avec eux, preuves comprises, s'ils partent.
- 4RapportsPar projet, par construction. Il n'existe aucun moyen d'agréger accidentellement deux clients.
- iCe que vous conservezLes définitions de tunnels et votre façon de travailler. C'est votre produit, et c'est la partie qui vaut la peine d'être réutilisée.
Aucune réputation partagéeAucune liste partagée
Réutiliser sans copier-coller
Construisez le tunnel une fois. Déployez-le autant de fois que vous avez de clients.
Un tunnel est un graphe, et un graphe est un JSON avec un schéma publié. Cela signifie que ce que vous réutilisez est un document, et non une capture d'écran d'un écran que vous devez reconstruire à la main dans chaque compte.
Vos tunnels maison
Bienvenue, panier abandonné, absence au rendez-vous, intervalle, reconquête. Écrits une seule fois par la personne la plus compétente, conservés dans votre propre dépôt, et créés dans un projet client en un seul appel API.
Vérifiés de la même manière partout
Le validateur s'exécute sur votre tunnel dans chaque projet où il arrive. Un graphe qui bouclerait sans attente, ou qui enverrait sans objet, y est refusé exactement comme il le serait ici.
Simulé avant d'être exécuté
Faites un essai à blanc d'un contact réel de la liste de ce client à travers le tunnel et lisez ce qu'il lui enverrait. Faites-le une fois par déploiement, et la conversation « c'est parti de travers » cesse d'avoir lieu.
Amélioré à un seul endroit
Quand vous apprenez quelque chose — le deuxième rappel fonctionne mieux à dix heures du matin — vous modifiez votre définition et vous la déployez. Les clients qui utilisent déjà l'ancienne version terminent sur l'ancienne version ; personne en cours d'exécution n'est perturbé.
Les créations aussi
Une création est un document avec des variables de fusion. Le même e-mail de bienvenue, rendu avec la marque, les couleurs et le logo de chaque client — récupérés depuis son propre site web lors de la première exécution.
Ou laissez un agent le faire
Pointez un assistant vers le serveur MCP, limité à un seul projet, et faites-lui rédiger et vérifier le tunnel pour ce client. Tout ce qui atteint une personne réelle nécessite toujours une confirmation explicite et reste dans le quota.
Onze clients, onze expéditeurs, un seul endroit où regarder.
Le problème du rapport mensuel
L'essentiel des difficultés de reporting d'une agence ne consiste pas à produire des chiffres. Il s'agit de produire des chiffres qui survivent à une question de suivi du client, et de les produire sans trois heures de captures d'écran le premier du mois.
Deux choses aident ici. Les rapports sont des routes API, de sorte que le dossier mensuel peut être assemblé par un script et exporté en PDF plutôt que par une personne et un tableur. Et les chiffres sont honnêtes concernant les robots : brut et filtré sont tous deux disponibles, étiquetés, de sorte que lorsqu'un client demande pourquoi le taux d'ouverture a chuté après son déménagement, vous pouvez l'expliquer en une phrase plutôt que de le défendre en quatre.
Les mêmes tuiles arrivent dans dash-b — performance des campagnes, abandons du tunnel, croissance de la liste, délivrabilité par domaine — de sorte qu'un client qui veut un tableau de bord en direct peut en avoir un, sur son propre compte, avec ses propres identifiants et sans aucune clé de la vôtre dans la page.
- 1Pour chaque projetUn jeton, un périmètre de projet, le même script.
- 2TirerPerformance des campagnes, abandons du tunnel, croissance de la liste, délivrabilité par domaine.
- 3RenduLeur document de création en page de rapport, puis en PDF.
- 4EnvoyerOu déposez-le dans leur tableau de bord. Selon ce que ce client lit réellement.
- iCe qui a changéTrois heures de captures d'écran sont devenues une tâche planifiée, parce que les rapports étaient des routes depuis le début.
Brut et filtré, tous deux étiquetés
La conversation sur le consentement, menée tôt
Chaque agence a déjà rencontré le client qui arrive avec un tableur de quatre mille adresses et une réponse vague sur leur provenance. Ici, ce n'est pas un argument que vous devez gagner ; c'est un champ.
L'importation est enregistrée au mieux comme intérêt légitime, jamais comme consentement, et la répartition des bases est affichée avant l'envoi de toute campagne. Si une liste ne peut pas recevoir d'envois, cela est indiqué au moment de l'importation plutôt qu'au moment d'une plainte. Cela transforme un arbitrage inconfortable en une lecture partagée du même écran — ce qui vous place dans une bien meilleure position lorsque le client insiste.
Mérite d'être dit à voix haute au client : la réputation mise en risque par une mauvaise liste est la sienne, sur son propre domaine, car chaque projet envoie en son propre nom. C'est un argument plus fort que n'importe quelle réglementation, et c'est celui qui porte généralement.