92946d3203
- Created a new tech and AI monitoring report template for weekly updates. - Added an employment and developer trends report template to analyze market conditions. - Updated CLAUDE.md to include new directories for sources and templates. - Introduced a detailed structure for capturing key signals, OKR alignment, and actionable insights.
191 lines
4.8 KiB
Markdown
191 lines
4.8 KiB
Markdown
---
|
|
statut: idée
|
|
role: seenaps
|
|
objectif: Industrialiser le support client Gesteos avec l'IA
|
|
echeance:
|
|
okr:
|
|
---
|
|
|
|
# IA pour le support client Gesteos
|
|
|
|
## Résultat attendu
|
|
|
|
Mettre en place un dispositif d'assistance IA pour réduire la charge support, homogénéiser les réponses et capitaliser automatiquement la connaissance issue des tickets Gesteos.
|
|
|
|
## Pourquoi ce projet
|
|
|
|
Le support Gesteos est aujourd'hui fortement dépendant des personnes, coûteux en temps humain et peu capitalisé. L'IA peut transformer chaque ticket traité en connaissance réutilisable, tout en accélérant la montée en compétence du support N1.
|
|
|
|
## Problème actuel
|
|
|
|
Aujourd'hui, le support est :
|
|
|
|
- fortement consommateur de temps humain, notamment en N1 et N2 ;
|
|
- peu capitalisé, avec des réponses souvent répétées ;
|
|
- dépendant des individus, notamment Boris et Sylvie ;
|
|
- hétérogène en qualité et en délai.
|
|
|
|
Conséquences directes :
|
|
|
|
- coût support élevé ;
|
|
- montée en compétence lente pour Tony et les futurs recrutements ;
|
|
- pression sur le BUILD, notamment Fred ;
|
|
- expérience client variable.
|
|
|
|
## Principe du cas d'usage
|
|
|
|
Utiliser Claude AI comme moteur de capitalisation et d'assistance au support.
|
|
|
|
L'IA serait alimentée par :
|
|
|
|
- les tickets historiques Odoo ;
|
|
- les réponses support existantes ;
|
|
- la documentation produit : release notes, guides, aide en ligne ;
|
|
- les bonnes pratiques internes.
|
|
|
|
Objectif : transformer chaque ticket traité en connaissance réutilisable.
|
|
|
|
## Fonctionnement cible
|
|
|
|
### 1. Analyse automatique du ticket
|
|
|
|
Quand un ticket arrive, l'IA identifie :
|
|
|
|
- le type de problème : facturation, liaison InSitu, etc. ;
|
|
- la fréquence : problème connu ou nouveau ;
|
|
- le niveau : N1 ou N2.
|
|
|
|
Résultats attendus :
|
|
|
|
- pré-qualification automatique ;
|
|
- gain de temps immédiat.
|
|
|
|
### 2. Proposition de réponse
|
|
|
|
L'IA génère :
|
|
|
|
- un diagnostic ;
|
|
- une checklist de vérification ;
|
|
- une réponse client prête à envoyer.
|
|
|
|
Exemple de réponse type :
|
|
|
|
> Avez-vous vérifié X / Y / Z ?
|
|
|
|
Le support :
|
|
|
|
- valide ou ajuste la proposition ;
|
|
- envoie la réponse au client.
|
|
|
|
Gains attendus :
|
|
|
|
- moins de rédaction manuelle ;
|
|
- réponses plus homogènes.
|
|
|
|
### 3. Capitalisation automatique
|
|
|
|
Chaque ticket traité enrichit une fiche support structurée :
|
|
|
|
- symptôme ;
|
|
- cause ;
|
|
- résolution ;
|
|
- réponse type.
|
|
|
|
Effets cumulés :
|
|
|
|
- amélioration continue ;
|
|
- base de connaissance vivante.
|
|
|
|
### 4. Assistance proactive
|
|
|
|
À terme, le système peut permettre :
|
|
|
|
- des suggestions en temps réel au support ;
|
|
- la détection de patterns récurrents ;
|
|
- des alertes sur les bugs fréquents à remonter au BUILD.
|
|
|
|
Impact clé : Boris passe progressivement de l'exécution du support au pilotage du système.
|
|
|
|
### 5. Self-service client
|
|
|
|
En phase avancée, le client pourrait :
|
|
|
|
- poser une question directement ;
|
|
- recevoir une réponse IA basée sur la base support.
|
|
|
|
Objectif : éviter la création de tickets lorsque le cas est connu et maîtrisé.
|
|
|
|
## Cas concret : liaison InSitu
|
|
|
|
Situation actuelle :
|
|
|
|
- 10 tickets similaires ;
|
|
- 10 réponses manuelles.
|
|
|
|
Situation cible avec IA :
|
|
|
|
- Claude identifie le pattern ;
|
|
- propose une réponse standard ;
|
|
- guide le client avec une checklist ;
|
|
- résout 60 % des cas sans intervention humaine.
|
|
|
|
## Impacts attendus
|
|
|
|
### Court terme : 1 à 2 mois
|
|
|
|
- Réduction de 30 % du temps de réponse support.
|
|
- Homogénéisation des réponses.
|
|
- Montée en compétence accélérée des juniors.
|
|
|
|
### Moyen terme : 3 à 6 mois
|
|
|
|
- 50 à 60 % des tickets assistés ou résolus par IA.
|
|
- Réduction de la charge N2 pour Boris.
|
|
- Moins de sollicitations pour Fred.
|
|
|
|
### Long terme : 6 à 12 mois
|
|
|
|
- Self-service client partiel.
|
|
- Support plus scalable.
|
|
- Capacité libérée pour :
|
|
- le commerce ;
|
|
- l'onboarding ;
|
|
- la delivery.
|
|
|
|
## Impacts organisationnels
|
|
|
|
### Delivery
|
|
|
|
- Boris devient pilote du système plutôt qu'exécutant principal.
|
|
- Le N1 est augmenté par l'IA : Tony et futurs recrutements.
|
|
|
|
### Build
|
|
|
|
- Moins de bruit support.
|
|
- Meilleure remontée des vrais bugs.
|
|
|
|
### Growth
|
|
|
|
- Temps libéré pour Sylvie.
|
|
- Meilleure expérience client, donc meilleure conversion potentielle.
|
|
|
|
## Points à challenger
|
|
|
|
- Qualité et accessibilité des données Odoo : les tickets historiques sont-ils exploitables sans nettoyage massif ?
|
|
- Responsabilité de validation : qui arbitre entre réponse IA, réponse support et correction produit ?
|
|
- Risque de masquer des bugs récurrents si l'IA absorbe trop bien les symptômes.
|
|
- ROI réel : les gains annoncés doivent être mesurés sur un périmètre pilote avant généralisation.
|
|
|
|
## Prochaine action
|
|
|
|
- Définir un pilote limité sur un cas fréquent, par exemple la liaison InSitu, avec un objectif mesurable de réduction du temps de traitement.
|
|
|
|
## Notes et avancement
|
|
|
|
### 2026-05-09
|
|
|
|
- Formalisation du cas d'usage IA pour le support client Gesteos.
|
|
|
|
## Source
|
|
|
|
Note issue d'un échange avec Stéphane Trémier, CEO 6TM.
|