Dans une boîte partagée Front, le propriétaire est le destinataire assigné, et il n'y en a jamais qu'un seul. Tous les autres qui commentent, sont mentionnés avec @ ou s'abonnent sont des aidants. Le piège, c'est que la propriété change sans que personne ne clique sur Assign : répondre à une conversation non assignée vous en fait le propriétaire, se mettre en Out of office renvoie vos conversations dans la file quand les clients répondent, et un réglage d'inactivité peut désassigner des fils silencieux. Fixez ces trois réglages sciemment, préférez le load balancing au round robin si votre équipe est parfois entièrement hors ligne, et la question « qui a ça ? » disparaît. Si vous voulez que chaque nouvelle conversation arrive avec une prochaine étape déjà rédigée, eesel travaille comme coéquipier IA dans Front et peut recevoir des conversations assignées comme n'importe qui d'autre.
Que veut dire « propriété » dans une boîte partagée Front ?
Dans Front, la propriété, c'est l'assignation. Le centre d'aide de Front le dit sans détour : assigner des conversations donne « every message a clear owner », et « a conversation can only be assigned to one user at a time. » Une fois assignée, elle apparaît dans la section Assigned to me de cette personne.
Je construis des agents IA qui travaillent dans des helpdesks comme Front, donc je passe beaucoup de temps à lire comment chaque outil de boîte partagée décide qui est responsable d'une conversation. La réponse de Front est plus claire que la plupart : un destinataire, plus autant d'aidants que vous voulez. Les aidants sont des personnes qui :
- Commentent sur le fil (seule votre équipe voit les commentaires).
- Sont mentionnées avec @, ce qui fait apparaître la conversation dans leur vue.
- S'abonnent, ce qui fait passer la conversation dans leur section Subscribed à chaque nouvelle activité.
Cette distinction compte parce que les règles d'abonnement de Front disent que le destinataire ne peut pas se désabonner : « you must unassign or reassign the conversation first. » Les aidants peuvent partir à tout moment. Le propriétaire ne peut pas s'en aller en silence.
Ça, c'est la théorie. En pratique, si les équipes cherchent ce sujet, c'est qu'une conversation qu'ils croyaient assignée ne l'était en fait pas. Voici d'où ça vient.
Qu'est-ce qui change le propriétaire sans que personne ne clique sur Assign ?
Cinq choses déplacent ou retirent le propriétaire dans une boîte partagée Front, et une seule est une personne qui réassigne délibérément.
1. Le premier à répondre devient le propriétaire
Les canaux Front ont un réglage appelé Assign conversations on first reply. Une fois activé, « any time a teammate starts a new conversation or replies to an unassigned conversation from a shared channel, the conversation will automatically be assigned to that teammate. » Il est activé par défaut.
C'est un bon réglage par défaut pour les petites équipes. C'est aussi pourquoi, sur une boîte inter-équipes, un commercial qui répond rapidement « let me check with support » finit par être propriétaire d'un litige de facturation pendant trois semaines. Deux détails tirés de la documentation Front : ça ne se déclenche que sur les conversations non assignées, et ça ne marche que si vous envoyez depuis Front, pas depuis l'extérieur.
2. Out of office renvoie les conversations dans la file
Quand un coéquipier passe en Out of office, « any replies they receive to conversations that originated in a shared inbox will automatically get unassigned. » Les conversations qui ne reçoivent pas de nouvelle réponse restent assignées à cette personne. Les assignations automatiques se mettent en pause, mais un coéquipier peut encore assigner manuellement.
Busy est différent. Selon le guide de statut des coéquipiers de Front, Busy met en pause les nouvelles assignations par règle, mais les conversations restent assignées en cas de nouvelle activité. Donc la règle pratique pour toute passation d'équipe support : Busy pour une pause déjeuner, Out of office quand vous terminez la journée. Gris, c'est-à-dire aucun appareil connecté, ne met rien en pause, donc un coéquipier qui ferme son ordinateur sans changer de statut peut encore recevoir des assignations par règle.
3. Le minuteur d'inactivité désassigne les conversations silencieuses
Les boîtes partagées ont un réglage de boîte appelé Unassign conversation if inactive for. Vous fixez une période, et quand une conversation restée silencieuse plus longtemps que cette période reçoit un nouveau message, Front la désassigne. Vous pouvez aussi choisir Never. Si les réglages de relance de votre entreprise comptent aussi les messages sortants, ceux-ci la déclenchent aussi ; sinon, seuls les entrants le font, selon les notes de Front sur relances.
Ce point en surprend beaucoup, et ça peut perturber votre suivi SLA, parce qu'il ne se passe rien au moment où le minuteur arrive à zéro. Le propriétaire ne disparaît que quand le client finit par répondre.
4. Quelqu'un d'autre l'archive
Archiver ressemble à une action partagée, mais Front suit les vues séparément. Du guide des statuts de conversation : « If a teammate who is not the assignee changes a conversation's status from a shared inbox, then the conversation will stay open in the assignee's Assigned to me section. » Le propriétaire la garde dans sa liste même après qu'un collègue a rangé la vue partagée. C'est un filet de sécurité, pas un bug, mais ça explique pourquoi les propriétaires voient des choses que le reste de l'équipe croit réglées.
5. Une règle ou un admin la réassigne
Le cas délibéré. Comme l'assignation de groupe dans d'autres helpdesks, les règles peuvent assigner, désassigner et réassigner, et les règles de load balancing peuvent réassigner une conversation qui a été lâchée parce que son propriétaire est passé Out of office ou Busy, pourvu que la règle ait un déclencheur Assignee is removed (documentation load balancing de Front).
Le seul interrupteur qui remplace presque tout ça est le réglage de boîte partagée Keep assignments when teammate is out of office or busy. Activez-le et les nouvelles conversations peuvent encore être assignées à des coéquipiers indisponibles, les existantes restent en place en cas de nouvelle activité, et le réglage de désassignation par inactivité est désactivé.
Qu'arrive-t-il à la propriété dans chaque situation ?
Voici la même logique sous forme de référence rapide. Choisissez la situation que vous essayez d'expliquer à votre équipe.
Comment les aidants aident-ils sans prendre la propriété ?
Les équipes Front les plus nettes séparent « c'est à moi » de « j'aide juste là », et Front vous donne les outils pour la seconde partie. L'astuce, c'est que les aidants devraient commenter, pas répondre.
La détection de collision en temps réel de Front aide ici : si un coéquipier rédige une réponse dans une boîte partagée, vous voyez un indicateur qu'il répond, et le contenu du brouillon est partagé en direct pendant qu'il tape. Ça évite la réponse en double. Ça ne décide pas qui est propriétaire du fil, d'où l'importance des réglages ci-dessus.
Les évaluateurs sur G2 décrivent le bénéfice presque dans les mêmes termes :
"We can assign conversations, jump in when someone needs help, and avoid that awkward moment when two people reply to the same email. It sounds simple, but it saves a surprising amount of time."
Encore un détail d'abonnement qui vaut d'être connu : la préférence personnelle Unsubscribe on unassign ne s'applique que quand vous vous désassignez manuellement vous-même. Quand une règle vous désassigne, vous restez abonné jusqu'à ce que vous vous désabonniez vous-même. C'est pourquoi les personnes qui étaient en Out of office reviennent à une section Subscribed pleine de fils qu'elles ne possèdent plus.
Round robin ou load balancing : lequel garde la propriété claire ?
Si une règle assigne vos conversations, la méthode décide de ce qui se passe quand personne n'est là. La comparaison des deux par Front est directe sur la différence.
| Round Robin | Load Balancing | |
|---|---|---|
| Qui reçoit la prochaine conversation | Le prochain coéquipier en ligne dans l'ordre | Le coéquipier ayant le moins de conversations partagées ouvertes et assignées |
| Tout le monde hors ligne | Non assignée, et pas de file | En file jusqu'à ce que quelqu'un ait de la place |
| Un coéquipier revient en ligne | Pas de rattrapage des conversations manquées | Reçoit d'abord la conversation la plus ancienne sans réponse |
| Plafond par personne | Aucun | Limite par workspace, maximum et défaut 100 |
| Les conversations en snooze comptent dans le plafond | n/a | Non |
| Plan | Rules (Starter permet jusqu'à 10) | Professional et au-dessus |
Sources : round robin contre load balancing, règles de load balancing, tarifs de Front.
Deux détails du load balancing surprennent souvent. D'abord, les limites sont par workspace, donc dans l'exemple propre de Front, Hector est à 4 dans un workspace et à 5 dans un autre, soit jusqu'à 9 conversations à la fois. Ensuite, le moteur de règles de Front « does not re-assess rule conditions when a conversation reaches the front of a load balancing assignment queue. » Une conversation qui a depuis changé de tag reste assignée par la règle qu'elle correspondait au départ.
Mon avis : le round robin convient à une équipe toujours présente pendant les heures de boîte. Si votre équipe est parfois entièrement hors ligne (nuits, week-ends, petite équipe répartie sur plusieurs fuseaux horaires), le load balancing est le choix le plus sûr, parce que le round robin laisse tout simplement ces conversations non assignées. Le load balancing demande Professional à 65 $ par siège et par mois en facturation annuelle, et la fonction de shifts qui bascule les statuts automatiquement est sur Enterprise (105 $ par siège et par mois).
Le même compromis se retrouve dans les configurations round robin de Zendesk, round robin de Freshdesk et round robin de Gorgias.
Quel modèle de propriété votre équipe devrait-elle choisir ?
Trois modèles fonctionnent dans Front. Celui qui convient dépend de la taille de l'équipe et de la fréquence à laquelle tout le monde est hors ligne en même temps.
| Modèle | Comment le propriétaire est fixé | Réglages à vérifier | Convient à |
|---|---|---|---|
| Revendiqué par réponse | Qui répond le premier | Auto-assignation en première réponse activée, les aidants commentent plutôt que de répondre | 2 à 5 personnes, mêmes horaires |
| Assigné par règle | Règle de load balancing sur l'entrant | Limites d'assignation, déclencheur Assignee is removed, discipline Out of office | Volume régulier, horaires décalés ou fuseaux |
| Responsable de tri | Une personne assigne chaque matin ou chaque heure | Auto-assignation en première réponse désactivée, désassignation par inactivité fixée | Équipes mixtes (support plus ventes ou ops) |
Quel que soit votre choix, notez trois décisions par écrit et partagez-les avec l'équipe, car ce sont elles qui causent le « je pensais que tu l'avais » :
- Répondre revendique-t-il la conversation ? Si non, désactivez Assign conversations on first reply sur chaque canal partagé.
- Que fait Out of office ? Soit vous le laissez désassigner (par défaut), soit vous activez Keep assignments when teammate is out of office or busy. Choisissez-en un, et dites à l'équipe quel statut utiliser en fin de service.
- Combien de temps un fil assigné peut-il rester silencieux ? Fixez Unassign conversation if inactive for à un vrai nombre ou à Never, pas à ce que quelqu'un a choisi par hasard à la configuration.
Les règles peuvent rendre tout ça propre, mais plus de règles n'est pas toujours mieux. Un évaluateur G2 a bien résumé le compromis :
"If you create too many rules, you end up having to check why each message ended up in a different place. We had to simplify the setup so that everyone understood how to work with it."
Si le modèle de Front ne convient pas à votre équipe, ma liste d'alternatives à Front et mon tour d'horizon des tickets pour petites équipes sont la prochaine étape.
Si vous hésitez encore entre le modèle de boîte partagée de Front et une file de tickets, mon guide boîte partagée vs tickets et mon comparatif Front contre Hiver couvrent les différences structurelles. Front a aussi des statuts de ticket optionnels (Open, Waiting, Resolved) pour les boîtes partagées, qui aident à suivre la progression mais ne changent pas qui est propriétaire d'une conversation.
Où un coéquipier IA s'intègre-t-il dans la propriété Front ?
Un coéquipier IA dans Front fonctionne mieux comme un destinataire ou aidant de plus, suivant les mêmes règles que tout le monde, plutôt que comme un système séparé que l'équipe doit surveiller. C'est ainsi qu'est construite l'intégration Front d'eesel : elle peut recevoir des conversations assignées, laisser une réponse rédigée en commentaire interne pour qu'une personne l'envoie, taguer, assigner à un coéquipier précis, ou archiver. Elle peut aussi se déclencher quand un coéquipier tape @eesel dans un commentaire, ce qui correspond au modèle « les aidants commentent, les propriétaires répondent » ci-dessus.
La suite native Front AI de Front, avec Autopilot et Copilot, est l'autre voie si vous préférez rester chez un seul fournisseur.
Une limite honnête tirée de la documentation Front d'eesel : eesel assigne à un coéquipier nommé précis, pas à une équipe ou un groupe. Le routage vers un groupe reste géré par vos règles Front, donc votre configuration de load balancing continue de faire son travail.
Le schéma que je vois le plus souvent bien fonctionner est celui que Xap utilise sur Freshdesk : les tickets d'étudiants mal orientés reçoivent une réponse de renvoi complète rédigée en note interne, et une personne l'envoie. eesel ne répond jamais lui-même à un étudiant. Adverscale est la version à mention : un agent écrit @eesel dans une note, le coéquipier IA répond aux questions courantes, et tout ce qui sort du cadre reçoit une note expliquant pourquoi ça s'est arrêté (escalade IA faite de façon ennuyeuse et fiable), plus une assignation au bon groupe. Sur 2 400 tickets par mois, ça a laissé 2 700 notes internes pour l'équipe. Les deux sont sur d'autres helpdesks, mais l'idée de propriété se transpose directement à Front : l'IA fait la première passe, et le propriétaire reste une personne.
Si votre équipe configure les choses depuis un terminal, la CLI eesel permet à un agent de code comme Claude Code de connecter Front avec npx @eesel/cli integrations connect front, de vérifier ce qui a été synchronisé, et de tester un brouillon de commentaire interne sur une conversation test avant que toute automatisation ne passe en production. Approuver la connexion Front elle-même nécessite toujours une personne ayant le droit d'autoriser des apps dans Front.
Essayez eesel dans votre boîte partagée Front
Si votre équipe Front n'arrête pas de demander « qui a ça ? », la solution commence par les trois réglages ci-dessus. eesel ajoute la couche suivante : chaque nouvelle conversation est lue, rédigée et, si vous le voulez, assignée au bon coéquipier avant que quiconque n'ait à la réclamer, le brouillon attendant en commentaire interne pour que votre propriétaire décide toujours ce qui part. Il apprend de vos conversations Front passées et de votre centre d'aide, et vous pouvez commencer avec des brouillons seulement. Essayez eesel dans votre boîte Front, ou comparez les options dans mon tour d'horizon de la meilleure IA pour Front.