01 — Démarrage Rapide

1. Objectif métier

Mettre l’organisation en service en une seule session opérationnelle, avec un résultat vérifiable:

le canal client est actif,
un premier message sortant est envoyé,
une première conversation est traitée côté équipe,
les responsables savent quoi surveiller pendant les 7 premiers jours.

Résultat attendu en fin de module:

équipe autonome sur les actions de base,
risque de lancement réduit,
base propre pour passer aux modules avancés.

2. Qui utilise ce module (admin/operator)

admin: pilote le lancement, valide les choix de setup, décide du mode d’automatisation initial.
operator: exécute le test conversationnel réel et confirme la fluidité terrain.

Répartition recommandée:

1 admin “owner lancement”,
1 opérateur “pilote exploitation”.

3. Prérequis

Préparer ces éléments avant de commencer:

nom officiel de l’organisation,
type d’activité (services, restaurant, ecommerce),
fuseau horaire métier,
numéro WhatsApp Business prêt,
personne responsable de validation finale.

Préparer aussi un mini jeu de test:

1 numéro interne réel (pour tests de messages),
2 exemples de demandes clients (ex: “je veux réserver”, “où est ma commande ?”),
1 message d’accueil validé par l’équipe.

Contraintes de lancement:

éviter de changer plusieurs paramètres majeurs au même moment,
ne pas lancer sans test entrant + sortant,
garder une trace écrite des décisions prises.

4. Procédure pas-à-pas (orientée actions produit)

Ouvrir la checklist de mise en route.

Confirmer les blocs restants: organisation, canal, équipe, test.
Nommer explicitement le responsable de chaque bloc.

Valider les informations d’organisation.

Vérifier nom, type d’activité, fuseau.
Vérifier que les paramètres de base sont cohérents avec le terrain.

Choisir le mode d’automatisation de départ.

Recommandation par défaut: workflow.
Si équipe très prudente: welcome_only temporaire.
Éviter ai_full au démarrage.

Finaliser la connexion du canal principal.

Vérifier que le canal est indiqué comme prêt.
Vérifier que les événements entrants remontent bien.

Préparer le socle opérationnel minimum.

Message d’accueil rédigé et validé.
Rôles équipe en place (admin / opérateur).
Règle simple de clôture conversation définie.

Créer un contact de test.

Utiliser un numéro réel de l’équipe.
Ajouter un nom clair (ex: “Test Lancement”).

Exécuter un test d’envoi sortant.

Envoyer un message texte court.
Vérifier réception côté téléphone test.
Vérifier visibilité dans la conversation côté plateforme.

Exécuter un test entrant.

Répondre depuis le téléphone test.
Vérifier que le message entrant apparaît côté inbox.

Exécuter un mini-cycle opérateur complet.

Prendre la conversation.
Répondre avec contexte.
Ajouter une note interne courte.
Clôturer avec un motif simple.

Valider la fin de lancement.

Tous les tests critiques passés.
Décision “go-live” explicite.
Plan de suivi J+1 à J+7 partagé.

5. Scénarios concrets (minimum 2)

Scénario A (Services, lancement standard):
- mode workflow,
- test prise de rendez-vous,
- passage opérateur,
- clôture avec note “test validé”.
Scénario B (Restaurant, charge de pointe):
- démarrage en welcome_only la première soirée,
- reprise humaine renforcée,
- retour workflow après stabilisation.
Scénario C (E-commerce, démarrage orienté support):
- import d’un petit lot de contacts,
- test message de suivi commande,
- traitement complet d’une conversation client.

6. Erreurs fréquentes et résolution

Problème: le canal semble connecté mais les messages entrants n’arrivent pas.
Résolution: revalider l’onboarding complet du canal puis refaire test entrant/sortant.
Problème: opérateur ne voit pas la conversation de test.
Résolution: vérifier l’affectation, les filtres de vue, et le statut de conversation ouverte.
Problème: démarrage fait sans standard d’équipe.
Résolution: définir immédiatement les règles minimales (prise en charge, note interne, clôture).
Problème: confusion sur le mode d’automatisation choisi.
Résolution: figer un mode unique pour 7 jours, mesurer, puis ajuster.

7. Bonnes pratiques et limites

Lancer petit, mesurer vite, élargir progressivement.
Utiliser des cas tests proches du réel, pas des tests artificiels.
Prévoir un canal interne d’escalade (qui décider en cas d’anomalie).
Formaliser une revue de lancement à J+1 et J+7.

Limites à connaître:

un setup visuellement “complet” n’est pas suffisant sans test réel,
un changement massif le jour J augmente fortement le risque d’erreur,
un mode trop avancé trop tôt dégrade la qualité perçue.

8. Référence rapide (champs/statuts/modes)

Modes d’automatisation:
- off = 100% humain,
- welcome_only = accueil auto + reprise humaine,
- workflow = recommandé au lancement,
- ai_assistant = IA supervisée,
- ai_full = autonomie élevée, à activer tardivement.
Statuts conversation utiles au démarrage:
- open,
- closed.
Indicateurs à vérifier chaque jour la première semaine:
- conversations traitées,
- messages échoués,
- délai de première réponse,
- volume de reprises manuelles.