Le travail au quotidien

Suivi client : conserver la promesse et sa raison

Un rappel utile indique qui attend quoi, pourquoi, de qui et pour quand. AlefOS garde ces éléments avec la relation.

Exemple de parcours

Un parcours concret, du signal à la suite du travail

  1. Un client demande un devis et promet un document.

  2. Le document manque encore ; la mission conserve la raison et le responsable.

  3. Un collègue examine les relances précédentes avant de préparer la suivante.

  4. L’action autorisée est vérifiée et son résultat conservé.

Illustration fictive. Les fonctions, sources et accès disponibles dépendent de votre environnement ; les conditions sont précisées ci-dessous.

Sur cette page
  1. Le problème est l’histoire manquante
  2. Décrire le suivi de manière exploitable
  3. Les signaux existent dans le travail quotidien
  4. Relire avant de préparer la réponse
  5. Exemple complet : une autorisation avant intervention
  6. Responsabilité et continuité
  7. Préparation et exécution contrôlées
  8. Devis, document ou rappel : retrouver la dépendance
  9. Outils et prérequis

Le problème est l’histoire manquante

Ce parcours concerne les professionnels et équipes dont la relation client dépend d’appels, messages, réunions, documents et relances répétées : vente, service, immobilier, conseil, interventions ou gestion de dossiers.

Un devis promis au téléphone, une pièce demandée sur WhatsApp ou une décision prise en groupe peut rester dans son canal d’origine. Quelques jours plus tard, le rappel existe encore, mais la personne doit reconstruire la raison d’agir.

Décrire le suivi de manière exploitable

« Envoyer la proposition » devient « envoyer la version révisée demandée mardi, avec le périmètre d’installation réduit et la précision tarifaire attendue ». « Appeler vendredi » doit expliquer ce que le client devait examiner avant cet appel.

La mission conserve le contact, le contexte, l’offre ou le document concerné, la personne responsable, la date et l’éventuelle validation. Elle ne se résume pas à un libellé de tâche.

Les signaux existent dans le travail quotidien

Un appel apporte une demande de rappel. Un message confirme une date ou soulève une objection. Une réunion attribue une responsabilité. Un rendez-vous crée une préparation ; un groupe partage une instruction ; une intervention révèle un besoin de seconde visite.

Les sources doivent être connectées ou saisies dans un parcours autorisé. Chaque signal ne devient pas automatiquement une mission, et l’OS ne doit pas inventer le contenu d’un canal inaccessible.

Relire avant de préparer la réponse

Retrouvez les derniers échanges utiles, ce qui a été promis, les objections encore valides, les documents reçus et ceux qui manquent. Interrogez l’assistant sur la situation avant de préparer un message, un appel ou un prochain rendez-vous.

Le brouillon utilise le contexte autorisé et les informations professionnelles confirmées. Le destinataire, les engagements et les pièces à partager restent à vérifier dans le parcours d’envoi.

Exemple complet : une autorisation avant intervention

Le client demande une intervention dans un hôtel. L’échange précise qu’une autorisation d’accès signée manque. La mission relie cette pièce au contact, à la date envisagée et à la personne chargée de la relance.

Un brouillon rappelle la pièce attendue et la raison de la demande. Après validation et résultat d’envoi, le suivi reste ouvert tant que la dépendance n’est pas résolue. La réception de la pièce ne vaut pas validation de sa portée juridique.

Responsabilité et continuité

Le collaborateur voit ses engagements ; le responsable retrouve les retards et arbitrages de son périmètre ; l’entreprise garde la mémoire de ce qui a été promis. Une réaffectation doit transmettre la raison du suivi, pas seulement son intitulé.

Les groupes peuvent porter les procédures communes et les points de coordination autorisés. Les clients ne doivent pas avoir à répéter toute leur histoire parce que le dossier change de personne.

Préparation et exécution contrôlées

Le parcours distingue action préparée, validation requise, exécution et résultat. Un échec fournisseur ne doit pas être affiché comme un message livré. Une mission clôturée ne prouve pas à elle seule que le client a reçu une pièce.

L’OS soutient la relation, sans remplacer le professionnel ni garantir une réponse ou un résultat commercial. Les limites de source, de rôle et de disponibilité restent réelles.

Devis, document ou rappel : retrouver la dépendance

Un devis attend un prix validé : ne le promettez pas avant accord. Une demande de pièce attend la personne qui la détient : vérifiez la dernière relance. Un rappel attend une réponse fournisseur : gardez cette dépendance avec la mission. Dans chaque cas, relisez l’action proposée et conservez le résultat réel.

Référence de fonctionnement

Modules, outils et conditions d’accès

Cette référence décrit les opérations MCP et leurs effets. La liste effectivement exposée à votre assistant dépend du serveur déployé, des modules et des autorisations. Une lecture, un brouillon et une exécution sont des opérations distinctes.

Contacts et contexte relationnel

Rechercher les coordonnées, lire le contexte associé et consulter les produits confirmés. L’ajout ou l’enrichissement est une écriture ; le mode aperçu dépend de la politique de l’outil.

OutilFonction et effet
contacts.searchRechercher les contacts par coordonnées, avec pagination par curseur et filtre de source.
contacts.getLire le profil d’un contact et son contexte relationnel disponible.
contacts.search_productsRetrouver les produits confirmés dans la mémoire produit du contact.
contacts.draft_addAjouter ou enrichir un contact ; le comportement d’aperçu dépend du mode sélectionné.

Consulter la documentation du module →

Missions et responsabilités

Lire la source et l’état d’exécution avant d’agir. Confirmer exécute une mission en attente ; rejeter et archiver ont des effets distincts. L’affectation dépend des rôles de l’entreprise.

OutilFonction et effet
missions.listLister les missions de l’utilisateur courant, éventuellement regroupées par contact.
missions.getLire la source, les objets liés et l’état d’exécution d’une mission.
missions.confirmConfirmer et exécuter une mission en attente.
missions.rejectRejeter une mission en attente sans l’exécuter.
missions.archiveArchiver une mission sans exécuter ni supprimer son action.
missions.assignAffecter depuis la file d’entreprise ou réaffecter avec le rôle requis ; les changements sont tracés.

Consulter la documentation du module →

Messages IBOX

Message enregistré, notification externe et lecture sont des états distincts. Un lien temporaire /m/:token donne accès à son message ; ce lien doit rester confidentiel.

OutilFonction et effet
ibox.listLister les messages IBOX visibles par l’utilisateur courant.
ibox.getLire un message IBOX accessible.
ibox.mark_readMarquer un message comme lu. Cette opération n’envoie pas de réponse.
messages.draft_sendPréparer l’aperçu d’un message sortant avec un action_id pour confirmation.
actions.confirmExécuter après confirmation le travail préparé identifié par action_id.

Consulter la documentation du module →

Les scénarios de cette page illustrent des parcours, pas des données clients réelles ni une garantie de résultat. Les connexions et capacités doivent être activées et vérifiées pour votre environnement. Les outils métier officiels conservent leurs responsabilités.

Poursuivre la lecture

Ce parcours utilise les capacités de votre OS IA, configuré sous votre marque. Son périmètre suit votre équipe, les outils pris en charge et les règles d’accès. Comprendre votre OS IA ↗

Choisissez la prochaine étape.