Classification des tickets : orienter vers la bonne équipe
Classez les tickets en Facturation, Technique, Ventes ou Fraude. Vérifiez les paiements contestés et les demandes multiples avant l’affectation.
L’aperçu gratuit est limité. Connectez-vous pour utiliser vos crédits et conserver un historique.
Votre prochaine décision commence ici.
Ajoutez un contexte ci-dessus ou commencez avec un exemple.
Une boîte partagée exige des règles communes
Une réclamation de facturation peut mentionner un problème de paiement, et une transaction non autorisée peut ressembler à un double prélèvement. Définissez les responsabilités avant de consulter un score. Cet outil propose une première file de traitement, à vérifier selon votre politique d’assistance. Il ne rembourse pas, ne confirme pas une fraude et ne modifie aucun compte. Conservez le ticket original pour que l’équipe destinataire retrouve les détails absents d’un résumé.
Examiner des cas concrets
Exemples de saisie et pistes de vérification, sans résultats de modèle enregistrés. Lancez votre propre contexte pour examiner une décision.
Un achat reconnu, facturé deux fois
J’ai renouvelé mon abonnement hier. Les deux prélèvements concernent ce renouvellement, mais je n’ai acheté qu’un abonnement.
Facturation est la catégorie attendue si votre politique lui attribue les litiges portant sur des achats reconnus. Le fait décisif est que la personne reconnaît l’achat. Une demande de remboursement ne prouve pas une fraude ; l’historique des paiements reste à vérifier avant toute décision financière.
Un paiement que la personne ne reconnaît pas
Deux paiements à votre nom figurent sur ma carte. Je n’ai jamais créé de compte ni autorisé ces paiements.
Le refus d’autorisation justifie d’envisager la file de vérification Fraude. Ce libellé désigne une enquête, pas une fraude établie. Si votre équipe Facturation traite toutes les enquêtes de paiement, appliquez cette règle de responsabilité plutôt que de considérer une autre catégorie comme une erreur automatique du modèle.
Un problème technique et un remboursement
L’export échoue sans arrêt et j’ai raté mon échéance. Pouvez-vous le réparer et rembourser ce mois-ci ?
La demande comporte une investigation technique et une réponse commerciale. Désignez un responsable principal ou créez deux tâches liées. Ajoutez la formule du compte uniquement si elle change l’affectation ; une formule entreprise ne suffit pas à établir une demande commerciale.
Définir les frontières avant de classer
Ces règles proposent un cadre de vérification. Ajoutez les règles de votre équipe à la question ou au contexte lors de la décision.
| Choix | Quand l’utiliser | Limite à vérifier |
|---|---|---|
| Facturation | Achat reconnu avec une question de facture, de montant, de renouvellement ou de remboursement. | Un paiement non autorisé exige une enquête, pas seulement une correction de facture. |
| Technique | Dysfonctionnement, problème d’accès ou demande de dépannage. | Une demande de remboursement associée peut nécessiter un second responsable. |
| Ventes | Discussion avant achat sur le prix, les achats ou l’extension du service. | Un client payant peut simplement avoir besoin d’assistance technique. |
| Fraude | Signalement d’une transaction inconnue ou d’un possible abus de compte. | Une catégorie ne prouve pas une faute et ne doit pas bloquer automatiquement un compte. |
Les situations à examiner de près
Plusieurs responsables pour un seul ticket
Une réponse à choix unique ne peut pas affecter deux équipes. Définissez le motif qui établit la responsabilité principale et conservez les demandes secondaires dans la transmission. Un libellé plausible ne doit pas masquer du travail restant.
Un résumé qui omet le fait décisif
Conservez les déclarations d’autorisation, les fonctions touchées et la solution demandée. Ne garder que le début et la fin d’un long échange peut supprimer une clarification importante. Limitez l’historique aux faits utiles à cette affectation.
Calibrer le coût du transfert, pas les sanctions de compte
Évaluez des tickets annotés de vos propres files et examinez les erreurs par équipe. Un transfert facilement réversible n’a pas le même coût qu’un retard dans une enquête sur un paiement inconnu. Commencez par une vérification humaine et suivez les réaffectations ainsi que les cas urgents manqués.
Déduisez les seuils d’automatisation de ces observations. La confiance et la probabilité de Fraude sont deux champs différents ; aucun n’autorise à lui seul une restriction de compte. Les enquêtes et les sanctions doivent garder leurs propres contrôles.
Un exemple d’API Jev pour votre prochaine intégration
Appelez l’API REST iajev avec cURL. Recevez un choix, des probabilités et un niveau de confiance en JSON.
curl https://iajev.com/api/v1/decisions/run \
-H 'Authorization: Bearer YOUR_API_KEY' \
-H 'Idempotency-Key: YOUR_UNIQUE_REQUEST_ID' \
-H 'Content-Type: application/json' \
--data '{
"state": {
"message": "Mon abonnement a été facturé deux fois le mois dernier et je n’ai toujours pas reçu de remboursement.",
"plan": "pro",
"country": "FR"
},
"decision": {
"type": "choice",
"question": "Quelle équipe doit traiter cette demande ?",
"choices": [
"Facturation",
"Technique",
"Ventes",
"Fraude"
]
}
}'Questions sur cet outil
Faut-il inclure les anciens tickets du même client ?
Ajoutez seulement les faits qui expliquent le problème actuel : un double prélèvement non résolu ou une étape de dépannage déjà tentée. Un ancien litige sans rapport peut détourner l’attention d’un problème technique récent. Préférez un historique bref et pertinent à une archive complète.
Et si mon support compte plus de quatre files ?
Personnalisez les choix selon vos responsabilités. La requête iajev actuelle accepte de deux à huit choix. Au-delà, envisagez un premier tri par département puis un second au sein de celui-ci, avec une voie manuelle pour les demandes ambiguës.
Utiliser iajev
Ajouter le contexte
Conservez les faits nécessaires à cette décision.
Vérifier les choix
Adaptez la question et les options à votre processus.
Lancer et vérifier
Examinez la distribution avant d’agir.
La confiance indique-t-elle la probabilité d’une bonne décision ?
Non. La confiance est une estimation distincte du modèle ; les probabilités décrivent la distribution entre vos choix. Aucun de ces indicateurs ne garantit une exactitude mesurée.
Puis-je comparer deux saisies ?
Modifiez le contexte et relancez la même question pour comparer les probabilités. Changer la question ou les choix démarre une nouvelle comparaison.