Huit agents spécialistes offrent à la croissance par webinaires et à la prestation client une surface opérationnelle coordonnée.

Scaling Webinars disposait d’outils sophistiqués et faisait face à un problème opérationnel tout aussi sophistiqué. Acquisition, attribution, contenu, prestation des webinaires, intégration et ventes exigeaient chacun des consignes différentes, mais le travail devait continuer à avancer comme un seul système. RECAST a construit la couche de coordination entre ces départements.

Éléments probants à la publication : huit agents nommés, 35 connexions et 29 sessions actives ; passerelle, proxy de facturation, vue opérationnelle 3D et tunnel sécurisé vérifiés en fonctionnement le 30 mai 2026.

L’entreprise

Bryant Ward dirige Scaling Webinars, une entreprise axée sur la croissance par webinaires et la prestation client. Sa surface opérationnelle couvre publicité, inscriptions, séquences de présence, relance post-webinaire, intégration client, coaching commercial, tableaux de score, reporting hebdomadaire et production créative.

GoHighLevel détenait les contacts et opportunités. Hyros détenait l’attribution. Google Workspace détenait documents et calendriers. Slack et Discord portaient les instructions et les échanges de l’équipe. Chaque système était utile, mais Bryant restait l’endroit où leurs contextes se rejoignaient.

La contrainte

Un assistant généraliste ne pouvait pas traiter en toute sécurité tous les modes opérationnels. Stratégie publicitaire, scripts VSL, intégration client, revue commerciale et relance de webinaire ont des entrées, des normes et des règles de validation différentes. Les séparer en bots déconnectés aurait créé le problème inverse : des parcours spécialistes sans mémoire commune.

L’entreprise avait besoin d’une séparation par département sans rendre à Bryant toute la coordination.

Pourquoi les outils existants ne suffisaient pas

La pile d’automatisation pouvait déplacer des dossiers et déclencher des actions, mais pas porter le jugement opérationnel. Un contact dans GoHighLevel n’intégrait pas automatiquement la connaissance client, le contexte d’attribution, les normes créatives et la politique de validation utiles à la tâche.

La couche manquante devait acheminer chaque demande vers le bon spécialiste, rendre le contexte commun accessible, exposer le travail dans une surface de pilotage visible et s’arrêter à la bonne frontière. Modifications de dépenses, envois réels, publications, décisions de recrutement ou de licenciement et changements dans le CRM de production restaient soumis à validation par conception.

Cartographie de la transformation

Avant

Ads | Hyros | GHL | Workspace | Slack | Discord -> Bryant réconcilie le contexte -> le département agit

Après

Contexte opérationnel partagé -> agent spécialiste -> parcours outil approuvé -> résultat visible -> validation Bryant/équipe si engageant -> trace système

Les huit parcours sont séparés par responsabilité, pas isolés par leur mémoire.

Un processus de bout en bout

1. Entrée : une nouvelle exigence client ou campagne entre dans la surface de pilotage avec son contexte métier.
2. Routage : l’agent Jeff dirige le travail vers le spécialiste approprié — publicité, contenu, webinaires, ventes, intégration, script publicitaire/VSL ou production créative.
3. Récupération du contexte : le spécialiste utilise la connaissance gbrain commune et les bonnes données client au lieu de demander à Bryant de réexpliquer le compte.
4. Production : l’agent prépare la ressource, l’analyse, la séquence, le tableau de score ou l’étape opérationnelle demandée au moyen de ses outils autorisés.
5. Validation humaine : dépenses, changements dans le CRM de production, envois réels, publication et décisions relatives aux personnes attendent une validation explicite.
6. Résultat visible : le résultat apparaît dans les canaux Discord/Slack de l’équipe ou dans le Command Center hébergé, plutôt que de disparaître dans une session privée du modèle.
7. Trace : les pages clients, panneaux GHL et sessions actives du système préservent l’état du travail pour le département suivant.

Ce qui a changé

• Construit : huit agents métiers, Command Center hébergé, vue opérationnelle 3D, mémoire commune et compétences de processus spécialisées.
• Connecté : Discord, Slack, GoHighLevel, Hyros, Google Workspace, Zapier, Apify et routes Composio gouvernées.
• Testé : santé de la passerelle, routage du modèle, états Discord et Slack, services locaux, tunnel sécurisé et proxy WebSocket côté serveur inspectés en direct.
• En production et vérifié : le 30 mai 2026, la passerelle OpenClaw, le proxy de facturation, le service Claw3D et le tunnel Cloudflare fonctionnaient. L’environnement comptait 35 connexions et 29 sessions actives.
• Utilisé activement : les preuves conservées montrent des sessions actives et un environnement opérationnel en service. Elles ne transforment pas l’activité en économie de temps ou en chiffre d’affaires inventé.
• Dépendance prestataire ou client restante : les actions engageantes restent volontairement soumises à validation ; il s’agit d’une frontière de contrôle, pas d’une automatisation inachevée.
• Résultat financier communiqué par le client : aucun résultat conservé pour ce cas.

Preuves

• Périmètre système : huit agents spécialistes nommés.
• Routage opérationnel : 35 connexions au point de vérification.
• Signal d’usage : 29 sessions actives au point de vérification.
• Preuve d’exécution : passerelle, proxy de facturation, tunnel sécurisé, Discord, Slack et Claw3D déclarés sains ou actifs le 30 mai 2026.
• Preuve de contrôle : des validations couvrent explicitement dépenses, envois réels, publications, décisions relatives aux personnes et modifications du CRM de production.

La technologie — en dernier

Le système fonctionne sur le Mac mini de Bryant avec OpenClaw, Discord, Slack, GoHighLevel, Hyros, Zapier, Google Workspace, Apify, gbrain/memory-core, Composio, un Command Center hébergé, Cloudflare Tunnel et Claw3D. L’environnement actif expose clients, agents, cerveau, compétences et paramètres, tandis qu’un proxy WebSocket côté serveur relie le bureau visuel à la passerelle OpenClaw. L’interface rend la couche opérationnelle lisible pour l’équipe ; elle n’est pas la source de l’automatisation elle-même.

Témoignage client

Aucun témoignage textuel étayé par la source n’est publié pour ce cas. La preuve publique porte sur le périmètre de déploiement vérifié et les éléments d’exécution ; RECAST n’écrit pas un témoignage à la place du client.

Transformation suivante

Découvrez comment la couche opérationnelle multimarque de Ramon partage les connaissances réutilisables sans effacer les frontières entre marques. Le même principe d’orchestration s’applique ici aux boutiques plutôt qu’aux départements d’une activité de webinaires.

Obtenez votre feuille de route IA

Si vos outils sont performants mais que chaque département attend encore qu’une personne relie le travail, la contrainte est l’orchestration. Réservez un audit IA gratuit pour identifier le premier parcours opérationnel à prouver.

Sources

• OPENCLAW-DEEP-CLIENT-CASE-STUDIES.pdf, page 12.
• RECAST_CASE_STUDIES_2026_UPDATED.pdf, page 3, document RA-CASES-001, version 2.0.
• RECAST_WEBSITE_MASTER_BLUEPRINT.md, sections 10.4, 11 et 58.