Offrir un "support privé" dans le cadre d'une communauté de support public

[RGJ (Richard - Communiteq)]

Je réfléchis à cela depuis un moment et j’ai décidé de partager mes idées avec vous tous et de vous demander votre avis.

Au cours des derniers mois, j’ai parlé à pas mal de personnes qui essaient de mettre en place un support client direct – où une équipe de support résout des problèmes confidentiels spécifiques aux clients – en complément de leur forum de support communautaire public existant.

La plupart de ces solutions impliquent les plugins « assign », « solved » et « ticket », et il existe ensuite plusieurs approches (mais il semble qu’il n’y ait pas de solution miracle, et c’est pourquoi j’ouvre ce sujet).

Solution n°1 : Créer des catégories / groupes séparés pour chaque client

Cela ne fonctionne que si vous avez un nombre relativement faible de clients, pas des centaines.

Solution n°2 : Celle décrite par schungx « Comment utiliser Discourse comme système privé de support/ticket »

Le principal inconvénient ici est : « (…) que vous créez une plateforme de billetterie dédiée, ou qu’au minimum il n’y aura aucun chevauchement entre les utilisateurs de votre interface Web Discourse et ceux qui demandent des tickets de support. »

Mais ce sujet aborde l’un des principaux problèmes : « Vous avez examiné le système de sécurité/permissions et vous ne trouvez pas ce que vous voulez : en gros, les permissions pures Créer et Créer/Répondre n’existent pas. » J’y reviendrai plus bas.

Solution n°3 : Boîtes de réception de groupe.

L’idée originale de Sam « Discourse comme portail de support par e-mail privé » qui est devenue les boîtes de réception de groupe. Vous configurez une boîte de réception de groupe, l’assignez à votre équipe de support, et tout le monde peut envoyer des messages à la boîte de réception par e-mail.

C’est maintenant la solution privilégiée et elle fonctionne.

Cependant, je ne l’aime pas beaucoup.

À mon avis (!), cette approche présente un certain nombre d’inconvénients, dont les trois principaux sont :

• Les messages envoyés au groupe de support sont difficiles à trouver (en fait, à mon avis, tous les messages sont difficiles à trouver si vous n’avez pas de notification sur laquelle cliquer) et bien que le personnel de support ait une bonne vue d’ensemble, un utilisateur n’en a pas. Alors que les utilisateurs du personnel qui travaillent sur les tickets voient une boîte de réception de groupe séparée, les utilisateurs qui ont créé les tickets ne peuvent les trouver qu’au milieu de leurs PM « réguliers ».
• Manque de prise en charge des tags dans les PM : seul le personnel peut taguer les PM et les utilisateurs ne peuvent pas voir ou filtrer par tags.
• Il n’y a pas d’« endroit » où l’on peut aller et envoyer un message. La possibilité de contacter l’équipe de support doit être explicitement annoncée quelque part (et je trouve difficile de trouver un endroit logique pour cela, la plupart du temps, cela finit dans une sorte de bannière).

Dans l’ensemble, pour moi, cela donne l’impression d’être un peu « greffé » et un compromis entre les sujets de catégorie et les PM.

#4 Sujets privés

Cette idée a été proposée à plusieurs reprises (également ici ici et ici), et j’ai déjà mentionné les permissions « créer » et « créer/répondre » ci-dessus.

Et s’il existait une sorte de catégorie « boîte de dépôt » où les gens pourraient démarrer un sujet et interagir avec le personnel de support (en gros : un groupe), où seuls eux et les membres de ce groupe pourraient voir le sujet ?

Ce serait la solution miracle pour ce cas d’utilisation. Nous aurions une catégorie « support » clairement définie où chaque utilisateur pourrait voir ses tickets de support (et uniquement les siens). Tout serait au même endroit et vous pourriez utiliser les tags et tout le reste.

Mais @codinghorror et @sam nous ont dit à plusieurs reprises que les permissions spécifiques aux sujets n’allaient pas se produire (ce que je comprends tout à fait, car cela ajoute beaucoup de complexité).

---

Je vois deux voies à suivre : utiliser les boîtes de réception de groupe #3 et espérer que ces inconvénients soient résolus, ou donner une autre chance à l’idée des sujets privés #4.

Entre-temps, quelques plugins qui tripotent implémentent des permissions par sujet sont apparus, comme Restricted Replies - autoriser uniquement certains groupes à répondre dans une catégorie - et Discourse Private Replies qui rend les réponses invisibles à tous sauf à l’initiateur du sujet (et au personnel)… et cela semble réalisable… j’ai donc envisagé de retenter ma chance avec un plugin.

Mais.

Avant de continuer, je serais intéressé d’entendre

• si d’autres personnes partagent mon opinion concernant les boîtes de réception de groupe, car je suis conscient que ces inconvénients perçus pourraient être très subjectifs.
• tout (!!) retour sur l’idée du plugin de sujets privés.

[Heliosurge (Dan DeMontmorency)]

C’est en effet un très bon sujet à aborder.

Les réponses privées pourraient peut-être être “forkées” pour aboutir à quelque chose qui ressemble à votre idée. Mais cela nécessiterait quelqu’un qui sait ce qu’il fait ou ce dont il discute, peut-être avec l’auteur du plugin si c’est un fork de plugin sponsorisé. Avec le sponsoring, ce serait formidable d’explorer une forme de concept de financement participatif.

Discourse Private Replies

Github: GitHub - communiteq/discourse-private-replies This plugin hides topic replies for everyone but the topic starter and the post author. Use cases This can be used for for instance homework assignments where the teacher opens a topic and posts an assignment, and all students make a post with their answers. When everyone has submitted their work, the teacher can open up the answers so the students will be able to discuss them. A second use case can be an auction where something is offered…

---

La boîte aux lettres de groupe est une excellente idée, cependant, à mon humble avis, le système de MP doit avoir une option de recherche facile à utiliser, ou des signets de groupe avec une option de dossier. Par exemple, les demandes du client A d’octobre 2020.

[Simon_Manning]

@RGJ

Mais @codinghorror et @sam nous ont dit à plusieurs reprises que les permissions spécifiques aux sujets n’allaient pas arriver (ce que je comprends tout à fait, car cela ajoute beaucoup de complexité).

Sans connaître le contexte original, les permissions spécifiques aux sujets semblent être une perspective beaucoup plus large (et, comme vous l’avez dit, beaucoup plus complexe) que ce qui serait nécessaire pour que le n° 4 fonctionne.

La façon dont j’envisagerais cela fonctionnerait serait d’étendre les permissions de catégorie pour inclure Voir Propre. Similaire à la façon dont les permissions sont maintenant, l’une de “Voir” ou “Voir Propre” doit être autorisée pour un groupe qui a été ajouté.

Comme autoriser la Création autorise automatiquement la Réponse, Voir Maintenant autoriserait automatiquement la Création - une catégorie où vous ne pouvez voir que vos propres sujets serait un peu inutile si vous ne pouvez pas créer de sujets.

Je pense que cela ne nécessiterait “que” deux changements supplémentaires en matière de permissions. Lorsque les groupes auxquels l’utilisateur actuel appartient n’accordent que la permission Voir Propre :

1. La liste des sujets devrait être filtrée pour n’afficher que les sujets créés par l’utilisateur actuel.
2. L’accès aux sujets devrait être refusé, sauf si le sujet a été créé par l’utilisateur actuel.

Je soupçonne qu’en réalité, il y a une complexité supplémentaire à gérer des choses comme la liste des derniers sujets, mais probablement (peut-être…) pas une quantité énorme de travail supplémentaire.

@RGJ

• si d’autres personnes partagent mon opinion concernant les boîtes de réception de groupe, car je suis conscient que ces désavantages perçus pourraient être très subjectifs.

Nous ne faisons pas actuellement de support privé dans Discourse, donc je n’ai pas d’expérience directe, mais je pense que mes propres perceptions sont en phase avec les vôtres.

La découvrabilité est importante, tant pour trouver où demander de l’aide que pour examiner les demandes de support actuelles et passées, ce qui semble potentiellement difficile avec l’approche des MP de groupe.

[RGJ (Richard - Communiteq)]

@Heliosurge

Les réponses privées pourraient peut-être être “forkées” pour aboutir à quelque chose dans la lignée de votre idée. Mais cela nécessiterait quelqu’un qui sache ce qu’il fait ou discute, peut-être avec l’auteur du plugin si c’est un fork de plugin sponsorisé. Avec le sponsoring, ce serait formidable d’explorer une forme de concept de financement participatif.

Merci pour votre retour ! Je suis l’auteur de ce plugin spécifique, et nous (Communiteq) sommes prêts à investir là-dedans si nous avons le sentiment que c’est la bonne direction. Ces choses ne poseront donc pas de problème.

@Simon_Manning

Je pense que cela ne nécessiterait “que” deux changements supplémentaires en matière d’autorisations. Lorsque les groupes auxquels l’utilisateur actuel appartient n’autorisent que la permission “Voir les siens” :

• La liste des sujets devrait être filtrée pour n’afficher que les sujets créés par l’utilisateur actuel.
• L’accès aux sujets devrait être refusé, sauf si le sujet a été créé par l’utilisateur actuel.

Oui, cela semble correct.

J’ai encore un peu de mal à comprendre comment cela serait structuré exactement, car Voir les siens implique Créer, Créer implique Répondre, et Répondre implique Voir.
Mais nous ne voulons pas que Voir les siens implique Voir.

[Heliosurge (Dan DeMontmorency)]

Oui, je vois ça. J’aurais dû faire plus attention.

[Simon_Manning]

@RGJ

J’ai encore un peu de mal à comprendre comment cela serait structuré exactement, car Voir soi-même implique Créer, Créer implique Répondre, et Répondre implique Voir.
Mais nous ne voulons pas que Voir soi-même implique Voir.

Oui, cela semble plus délicat que je ne le pensais. Il semble que Répondre n’implique pas réellement Voir, mais qu’un groupe ajouté aux permissions de catégorie le fasse.

Les permissions sont une énumération où un groupe a exactement l’un des rôles readonly, create_post ou full. Savoir si un utilisateur peut répondre/créer dans une catégorie donnée se résume à obtenir une liste de toutes les catégories où l’utilisateur fait partie d’un groupe qui a (create_post ou full) pour répondre ou (full) pour créer un sujet, et vérifier si la catégorie pertinente est dans cette liste.

Créer des sujets est facile, avoir une valeur supplémentaire dans l’énumération comme full_own fonctionne simplement avec elle ajoutée à la constante TOPIC_CREATION_PERMISSIONS dans category.rb. Si l’utilisateur a full ou full_own pour la catégorie pertinente, il peut créer un sujet.

Les réponses sont plus compliquées, mais je pense qu’il serait approprié d’ajouter une portée supplémentaire qui renvoie toutes les catégories où l’utilisateur a full_own. Quelque chose comme :

  OWN_TOPIC_POST_CREATION_PERMISSIONS ||= [:full_own]
  scope :own_topic_post_create_allowed,  -> (guardian) { scoped_to_permissions(guardian, OWN_TOPIC_POST_CREATION_PERMISSIONS) }

Ensuite, dans post_guardian.rb, can_create_post? a besoin d’une condition supplémentaire comme :

    (!SpamRule::AutoSilence.prevent_posting?(@user) || (!!parent.try(:private_message?) && parent.allowed_users.include?(@user))) && (
      !parent ||
      !parent.category ||
      Category.post_create_allowed(self).where(id: parent.category.id).count == 1 ||
      (parent.is_my_own? && Category.own_topic_post_create_allowed(self).where(id: parent.category.id).count == 1)
    )

Cependant, voir uniquement ses propres sujets et garantir que cela est vrai dans la page de catégorie pertinente, la dernière page, la recherche et partout ailleurs semble beaucoup plus difficile. Je n’ai pas encore trouvé.

[tobiaseigen]

Je pense que le plus facile à résoudre ici est la porte numéro 3, améliorer les boîtes de réception de groupe afin qu’elles fonctionnent bien pour fournir un support aux personnes qui se connectent, pas seulement à celles qui envoient un e-mail pour obtenir de l’aide.

@RGJ

• Les messages envoyés au groupe Support sont difficiles à trouver (en fait, à mon avis, tous les messages sont difficiles à trouver si vous n’avez pas de notification sur laquelle cliquer) et bien que le personnel de support ait une bonne vue d’ensemble, un utilisateur n’en a pas. Là où le personnel qui travaille sur les tickets voit une boîte de réception de groupe distincte, les utilisateurs qui ont créé les tickets ne peuvent les trouver qu’entre leurs e-mails “réguliers”.
• Manque de support de balisage dans les e-mails : seul le personnel peut baliser les e-mails et les utilisateurs ne peuvent pas voir ou filtrer par balises.
• Il n’y a pas d’“endroit” où l’on peut aller et envoyer un message. La possibilité de contacter l’équipe de support doit être explicitement annoncée quelque part (et je trouve difficile de trouver un endroit logique pour cela, la plupart du temps, cela finit dans une sorte de bannière).

Vos principales plaintes concernant les boîtes de réception de groupe semblent porter sur le manque de fonctionnalités côté utilisateur, ce qui est légitime si vos utilisateurs se connectent pour suivre leurs tickets et utilisent également les e-mails pour parler à d’autres personnes sur le site. Je n’ai pas beaucoup rencontré cela jusqu’à présent dans notre utilisation des boîtes de réception de groupe pour fournir un support ici sur meta. La plupart des personnes que nous aidons via les boîtes de réception de groupe ne se connectent jamais - elles utilisent principalement leur propre e-mail et peuvent donc utiliser leur e-mail pour organiser et archiver leur correspondance avec nous comme elles le souhaitent.

J’ai quelques utilisateurs avec lesquels je communique via @support-teams ici sur meta, je vais donc leur demander comment cela fonctionne pour eux et s’ils ont des suggestions. Je vais également faire quelques tests supplémentaires de mon côté pour voir comment cela fonctionne réellement maintenant. Il me semble que la demande est :

• permettre aux utilisateurs non-staff de voir les balises de message (actuellement, seuls les staff voient les balises. peut-être pouvons-nous utiliser des groupes de balises pour cela, afin de fournir certaines balises que les non-staff peuvent voir dans les messages ? )
• fournir un lien vers les boîtes de réception de groupe dans le menu des messages pour les utilisateurs lorsqu’ils envoient des messages à des groupes, pour voir leurs propres messages avec les groupes (cela fonctionne déjà pour le staff, je ne suis pas sûr de comment cela fonctionne pour les non-staff. il y a des problèmes ici avec la boîte de réception et l’archive, qui ne sont pas contrôlés individuellement par utilisateur)
• fournir un lien pour commencer un nouveau message à un groupe (je pense que cela existe sur la page du groupe si l’envoi de messages au groupe est autorisé)

La possibilité de commencer un nouveau message à un groupe est quelque chose que même moi j’ai remarqué, en tant que membre du groupe @support-teams pour fournir le support par e-mail de Discourse for Teams. Si je veux commencer un nouveau message de l’équipe de support, je dois inclure à la fois l’équipe de support et l’adresse e-mail de la personne à qui je veux écrire. C’est un peu maladroit.

De plus, la façon dont nous utilisons les boîtes de réception de groupe, nous ne fermons généralement pas les messages comme nous le ferions pour les sujets lorsqu’ils sont résolus. Nous les archivons simplement. Cela nous permet de les faire disparaître de notre vue lorsqu’ils sont résolus, mais aussi de permettre au client de faire un suivi par e-mail et de ramener le message dans la boîte de réception.

[Simon_Manning]

@tobiaseigen

De plus, la façon dont nous utilisons les boîtes de réception de groupe, nous ne fermons généralement pas les messages comme nous le ferions pour les sujets lorsqu’ils sont résolus. Nous les archivons simplement. Cela nous permet de les faire disparaître de notre vue lorsqu’ils sont résolus, mais aussi de permettre au client de faire un suivi par e-mail et de déplacer le message vers la boîte de réception.

C’est un point très intéressant que je n’avais pas vraiment considéré. Avec le support par e-mail, il est très courant que les clients retrouvent de vieux e-mails et y répondent plutôt que d’envoyer un nouvel e-mail. Si un sujet est fermé, cela sera probablement déroutant au mieux lorsqu’ils verront leur e-mail rejeté.

Derrière la porte numéro 4, quelle que soit la manière dont cela pourrait se produire, il serait probablement difficile pour le personnel d’identifier les sujets qui n’ont pas été traités s’ils ne peuvent pas être fermés, surtout avec un plus grand nombre de membres du personnel de support. Le plugin Solved n’aidera pas vraiment ici car le client pourrait répondre à un ancien sujet et les différents membres du personnel de support ne sauraient pas s’il a besoin d’attention ou si un autre membre du personnel l’a déjà résolu.

[RGJ (Richard - Communiteq)]

Je ne suis pas sûr que de jouer avec full, create_post et readonly soit la bonne approche, car full et create_post impliquent “voir tout” dans pas mal d’endroits. Il ne sera pas facile de créer un plugin maintenable de cette façon. De plus, je pense que ce ne serait pas très intuitif.

De plus, ce serait bien si l’auteur du sujet pouvait ajouter d’autres personnes (par exemple un collègue) au sujet, par exemple en les mentionnant, et dans ce cas ce mécanisme ne suffirait pas.

Pour l’instant, mon idée est de laisser les permissions intactes et d’ajouter une section sous les groupes de sécurité :

---

Activer les sujets privés dans cette catégorie
Autoriser les groupes suivants à voir tous les sujets [x personnel de support] [x support commercial]

---

@Simon_Manning

Cependant, ne voir que ses propres sujets et garantir cela sur la page de catégorie pertinente, le dernier, la recherche et partout ailleurs semble beaucoup plus difficile. Je n’ai pas trouvé de solution.

J’ai fait quelque chose de similaire dans le plugin de réponses privées, mais alors pour les messages dans un sujet au lieu des sujets dans une catégorie.
Je pense que j’irai assez loin avec quelques correctifs dans TopicGuardian.

@tobiaseigen

Je pense que le fruit le plus facile à cueillir ici est la porte numéro 3, améliorer les boîtes de réception de groupe afin qu’elles fonctionnent bien pour fournir un support aux personnes qui se connectent, pas seulement aux personnes qui envoient un e-mail pour obtenir de l’aide.

Oui, ce pourrait être un fruit très facile à cueillir. Votre résumé de ma demande est exact, et j’ai trouvé deux autres choses qui rapprocheraient les messages des sujets.

• Lorsque je recherche sur le forum, je dois explicitement ajouter in:private à ma requête de recherche pour rechercher mes messages. Parfois, je ne me souviens vraiment pas si quelque chose était un sujet (plus ou moins public) ou un message privé à un groupe. Pourquoi ne pas les inclure par défaut ?

• De plus, je pense qu’il serait agréable d’avoir un simple lien vers les messages dans l’onglet de droite du menu hamburger. Oui, il y a l’icône de l’enveloppe, mais elle contient une liste de messages, et pas un lien vers l’écran des messages à l’adresse /my/messages. Cet écran semble caché.

Les éléments du menu déroulant sont en partie les mêmes que les onglets de l’écran suivant, à l’exception de Messages et Badges. Donc, quand j’ai besoin d’aller voir mes messages, je clique toujours sur Résumé, puis sur Messages.

Comparez les éléments du menu déroulant

avec les onglets de l’écran de profil

Il y a Résumé, Activité, Invites et Préférences dans les deux, mais Brouillons dans l’un et Notifications, Messages et Badges dans l’autre. Donc, “Messages” me semble très caché (cela vaut aussi pour Notifications et Badges, mais je ne les utilise pas si souvent).

[tobiaseigen]

@RGJ

• Lorsque je recherche sur le forum, je dois explicitement ajouter in:private à ma requête de recherche pour rechercher mes messages. Parfois, je ne me souviens vraiment pas si quelque chose était un sujet (plus ou moins public) ou un message privé à un groupe. Pourquoi ne pas les inclure par défaut ?

Bon point. Je ne suis pas sûr de la logique derrière cette barrière. J’ai également remarqué que lorsque vous êtes dans vos messages, il ajoute in:personal par défaut, ce qui est bien ! Mais il n’ajoute pas par exemple in:support-teams pour rechercher uniquement dans la boîte de réception du groupe des messages, ce que je pense serait une bonne idée. La recherche avancée n’a pas non plus de moyen simple de filtrer par boîte de réception de groupe, à ma connaissance. (cc @pmusaraj)

@RGJ

De plus, je pense que ce serait bien s’il y avait un lien simple vers les messages dans l’onglet de droite du menu hamburger. Oui, il y a l’icône de l’enveloppe, mais elle a une liste de messages, et pas un lien vers l’écran des messages à /my/messages. Cet écran semble caché.

C’est une bonne idée, mais je pense qu’il y a un problème d’espace dans ce menu déroulant - vous ne voulez pas avoir plus de 7 éléments dans cette liste. De plus, pour la plupart des communautés, je ne pense pas que nous voulions réellement promouvoir la messagerie… nous voulons que les gens discutent publiquement ! Pour ceux qui discutent par messages, le menu déroulant des notifications et les notifications par e-mail, etc., offrent un accès juste à temps aux messages nécessitant une attention particulière.

Cela dit, nous travaillons activement à l’amélioration des systèmes de menu (mot-clé : sideburger) et prendrons donc cette question en compte. La barre latérale dans Discourse for Teams offre déjà un accès facile aux boîtes de réception de groupe et aux balises surveillées, que nous pouvons intégrer à Discourse de base avec le projet sideburger.

Voici à quoi cela ressemble maintenant lorsque je suis dans la boîte de réception du groupe Kabissa, sur mon site Discourse for Teams :

[Simon_Manning]

@tobiaseigen

• fournir un lien pour démarrer un nouveau message à un groupe (je pense que cela existe sur la page du groupe si la messagerie du groupe est autorisée)

Je me demande si l’on pourrait désigner des groupes comme groupes de support et avoir une entrée de menu hamburger basée sur cela, avec ces états :

• 0 groupes désignés pour le support, pas d’entrée de menu
• 1 groupe désigné, une entrée “Message de support” qui démarre un message au groupe

• 1 groupes désignés, une entrée “Support” qui renvoie à une page similaire à Groupes, affichant tous les groupes désignés avec des boutons de message

Peut-être que l’entrée de menu et la page supplémentaires sont excessives. Une section générée supplémentaire sur la page À propos ?

@RGJ

• De plus, je pense que ce serait bien s’il y avait un simple lien vers les messages dans l’onglet de droite du menu hamburger. Oui, il y a l’icône de l’enveloppe, mais elle a une liste de messages, et pas un lien vers l’écran des messages à /my/messages. Cet écran semble caché.

Ce n’est pas totalement évident, mais c’est là dans l’onglet messages, la flèche vers le bas en bas de la liste des messages vous mènera à l’écran /my/messages. Pas moins de clics que Résumé, puis Messages, mais un chargement de page en moins.

@tobiaseigen

Voici à quoi cela ressemble maintenant lorsque je suis dans la boîte de réception du groupe Kabissa, sur mon site Discourse for Teams :

Si j’étais un utilisateur envoyant un message à Kabissa, ce sujet serait-il principalement associé au groupe d’une manière ou d’une autre, ou le sujet n’aurait-il rien de plus que mon utilisateur et le groupe Kabissa ayant accès ?

S’il est principalement associé au groupe, serait-il possible de montrer cette boîte de réception Kabissa sur ma page de messages de la même manière, tout en n’incluant évidemment que les messages auxquels j’ai accès.

[tobiaseigen]

Lorsque j’ai testé cela ici sur meta, en créant un utilisateur tl0, j’ai pu naviguer vers la page du groupe support-teams et sélectionner le bouton Message pour envoyer un message au groupe. Une fois le message posté, il a atterri dans mon dossier de messages envoyés. Donc, cela fonctionne, bien que peut-être un peu trop enfoui pour certains cas. Vous pouvez toujours ajouter des liens au menu hamburger comme bon vous semble pour servir les objectifs de votre site, ou dans une bannière sur votre page d’accueil, etc. Donc, je ne vois pas grand-chose d’autre à faire ici ?

La boîte de réception Kabissa dans cette capture d’écran n’est visible que par les membres du groupe Kabissa. Les personnes qui envoient un message à Kabissa verraient les messages dans leurs propres messages.

[jomaxro (Joshua Rosenfeld)]

@RGJ

• Lorsque je recherche sur le forum, je dois explicitement ajouter in:private à ma requête de recherche pour rechercher mes messages. Parfois, je ne me souviens vraiment pas si quelque chose était un sujet (plus ou moins public) ou un message privé à un groupe. Pourquoi ne pas les inclure par défaut ?

Notez que in:all existe. Cela affichera à la fois les messages publics et personnels dans une seule recherche.

Si ma mémoire est bonne, l’idée était d’imposer une séparation entre les messages personnels et les sujets publics. Minimiser toute confusion quant à ce qui est public et ce qui est personnel. Cela dit, les boîtes de réception de groupe brouillent considérablement cette séparation.

[Simon_Manning]

@tobiaseigen

Vous pouvez toujours ajouter des liens au menu hamburger comme bon vous semble pour répondre aux besoins de votre site, ou dans une bannière sur votre page d’accueil, etc. Je ne vois donc pas grand-chose de plus à faire ici ?

Je pensais à augmenter la découvrabilité des groupes spécifiques au support. L’ajout de liens au menu hamburger conviendrait certainement à une communauté avec un seul groupe de support (ce qui est en fait idéal pour mes propres besoins), mais une communauté avec de nombreux groupes de support pourrait bénéficier d’une page ou d’une section sur la page “À propos” générée pour des groupes spécifiés.

Rétrospectivement, cela conviendrait probablement mieux à un plugin si une communauté en a besoin.

@tobiaseigen

La boîte de réception Kabissa dans cette capture d’écran n’est montrée qu’aux membres du groupe Kabissa. Les personnes qui envoient des messages à Kabissa verraient les messages dans leurs propres messages.

Ce que j’essayais de demander, peut-être maladroitement, c’est si le modèle dispose actuellement de suffisamment d’informations pour permettre (à l’avenir) d’afficher aux utilisateurs des boîtes de réception filtrées pour les groupes avec lesquels ils interagissent mais auxquels ils n’appartiennent pas. Ceci est lié à la préoccupation de @RGJ concernant la difficulté à trouver les messages envoyés aux groupes.

Par exemple, moi, en tant qu’utilisateur normal sur votre site Discourse for Teams, je pourrais voir une boîte de réception Kabissa dans mes messages qui affiche tous les messages que j’ai envoyés au groupe Kabissa. (Ou probablement les messages auxquels je participe.)

Mon soupçon est que ce n’est pas le cas, il n’a probablement que les participants sur lesquels se baser, ce qui pourrait être n’importe quel nombre d’utilisateurs et de groupes.

[schungx (Stephen Chung)]

@RGJ

Au cours des derniers mois, j’ai parlé à pas mal de personnes qui essaient de mettre en place un support client direct - où une équipe de support résout des problèmes spécifiques aux clients (confidentiels) - en complément de leur forum de support communautaire (public) existant.

C’est formidable que cela prenne de l’ampleur ! C’est parce que je trouve que Discourse est un système fabuleux pour les tickets de support privés et, quand ça marche, ça marche à merveille.

Je sais très bien que ce n’est pas pour cela que Discourse est conçu, et que j’essaie de forcer Discourse à faire quelque chose qu’il n’est pas censé faire, mais entre les boîtes de réception privées et la pleine gloire et les fonctionnalités des sujets principaux, je choisirais ces derniers n’importe quel jour et continuerais à essayer de les adapter…

[codinghorror (Jeff Atwood)]

@schungx

Je sais très bien que ce n’est pas pour cela que Discourse est conçu, et que j’essaie de forcer Discourse à faire quelque chose qu’il n’est pas censé faire, mais entre les boîtes de réception privées et la pleine gloire et les fonctionnalités des sujets principaux, je choisirais ces derniers n’importe quel jour et continuerais à essayer de les forcer…

C’est quelque chose que nous voulons soutenir, (figurativement et littéralement), mais nous ne voulons pas être cantonnés dans le coin d’un « outil de support ». Si vous avez des commentaires spécifiques sur la façon de rendre Discourse meilleur dans ce rôle, faites-le nous savoir.

Nous sommes toujours à l’écoute

[jrgong]

@RGJ

Et s’il existait une sorte de catégorie « boîte de dépôt » où les gens pourraient créer un sujet et interagir avec le personnel de support (en gros : un groupe), où seuls eux et les membres de ce groupe pourraient voir le sujet ?

J’adore l’idée ! Même au sein de notre communauté, nous avons des demandes de tickets de support distincts de leur boîte de réception utilisateur. Ce type de catégorie dans laquelle les utilisateurs ne peuvent voir que leurs propres tickets serait super utile.

[jerry0 (Jerry)]

@codinghorror

C’est quelque chose que nous voulons prendre en charge, (figurativement et littéralement), mais nous ne voulons pas être cantonnés dans le rôle d’un « outil de support ». Si vous avez des commentaires spécifiques sur la façon de rendre Discourse meilleur dans ce rôle, faites-le nous savoir.

Merci !

Nous utilisons un groupe de messagerie privée pour le support privé - cela fonctionne bien. La principale plainte des utilisateurs intensifs du système de support est l’impossibilité de rechercher leurs messages.

Nous avons essayé de leur apprendre qu’ils doivent ajouter le code in:personal à la requête de recherche afin de rechercher leurs messages, mais ce n’est pas intuitif et, pour être honnête, je n’ai vu aucun des utilisateurs réussir à le faire, ils abandonnent simplement et se plaignent de ne pas pouvoir rechercher leurs messages.

Ils ne comprennent même pas à quoi sert cette « suggestion » sous la boîte de recherche.

Et s’ils vont à la recherche avancée, ils sont peut-être assez avancés pour cocher le bouton radio « rechercher des messages », mais tout commence à paraître étrange lorsqu’ils ajoutent les mots in:personal et qu’ils abandonnent à ce moment-là.

S’il existait un moyen beaucoup plus intuitif de rechercher des messages qui n’implique pas d’ajouter du code dans la boîte de recherche, ce serait une amélioration massive.

Sinon, utiliser un langage plus intuitif, par exemple le code « in:messages », serait une légère amélioration.

[pfaffman (Jay Pfaffman)]

Ou peut-être que la recherche inclut par défaut les messages privés ?

[jerry0 (Jerry)]

En effet - ce serait merveilleux !

Un réglage « Rechercher les MP par défaut » (qui est normalement désactivé) serait vraiment idéal.

De cette façon, toute inquiétude quant aux utilisateurs se mélangeant entre les résultats de recherche pour les sujets normaux et les sujets de MP (que je n’ai pas) pourrait être mise en balance avec le fait que les gens ne peuvent pas du tout rechercher les sujets de MP (ce que j’ai).