Offrire "supporto privato" come parte di una community di supporto pubblico

[RGJ (Richard - Communiteq)]

Ho pensato a lungo a questo e ho deciso di condividere le mie idee con il gruppo e chiedervi cosa ne pensate.

Negli ultimi mesi ho parlato con parecchie persone che stanno cercando di impostare un supporto clienti diretto - dove un team di supporto risolve (confidenziali) problemi specifici del cliente - in aggiunta al loro attuale forum di supporto della community (pubblico).
La maggior parte di queste soluzioni coinvolge i plugin ‘assign’, ‘solved’ e ‘ticket’ e poi ci sono molteplici approcci (ma sembra che non ci sia una soluzione perfetta ed è per questo che sto creando questo topic).

Soluzione #1: Creare categorie / gruppi separati per ogni cliente

Questo funziona solo quando hai un numero relativamente piccolo di clienti, non quando ne hai centinaia.

Soluzione #2: Quella descritta da schungx “How to Use Discourse as a Private Support/Ticket System”

Il principale inconveniente qui è: “(…) che stai creando una piattaforma di ticketing dedicata, o che almeno non ci sarà sovrapposizione tra gli utenti della tua interfaccia web Discourse e coloro che richiedono ticket di supporto.”

Ma questo topic affronta uno dei problemi principali: " Hai esaminato il sistema di sicurezza/permessi e non trovi quello che vuoi: fondamentalmente i permessi puri di Creazione e Creazione/Risposta non esistono. " Ci tornerò più avanti.

Soluzione #3: Caselle di posta dei gruppi.

L’idea originale di Sam “Discourse as a private email support portal” che è diventata caselle di posta dei gruppi. Imposti una casella di posta di gruppo, la assegni al tuo team di supporto, e tutti possono inviare messaggi alla casella di posta.
Questa è ora la soluzione più utilizzata e funziona.

Tuttavia, non mi piace molto.

Secondo me (!), ci sono una serie di svantaggi in questo approccio, e i tre principali sono:

• I messaggi inviati al gruppo di supporto sono difficili da trovare (in realtà, IMHO tutti i messaggi sono difficili da trovare se non hai una notifica su cui cliccare) e sebbene lo staff di supporto abbia una buona panoramica, un utente no. Mentre gli utenti dello staff che lavorano sui ticket vedono una casella di posta di gruppo separata, gli utenti che hanno creato i ticket possono trovarli solo tra i loro PM ‘regolari’.
• Mancanza di supporto per i tag nei PM: solo lo staff può taggare i PM e gli utenti non possono vedere o filtrare per tag.
• Non c’è un “luogo” dove si possa andare e inviare un messaggio. La possibilità di inviare un messaggio al team di supporto deve essere esplicitamente pubblicizzata da qualche parte (e trovo difficile trovare un posto logico per questo, il più delle volte finisce in una sorta di banner).

Tutto sommato, per me sembra un po’ ‘aggiunto’ e un compromesso tra argomenti di categoria e PM.

#4 Argomenti privati

Questa idea è stata proposta più volte (anche qui qui e qui), e ho già menzionato i permessi di “creazione” e “creazione/risposta” sopra.

E se ci fosse una sorta di categoria ‘dropbox’ dove le persone possono avviare un argomento e interagire con lo staff di supporto (in pratica: un gruppo), dove solo loro e i membri di quel gruppo possono vedere l’argomento?
Sarebbe la soluzione perfetta per questo caso d’uso. Avremmo una categoria di supporto chiaramente definita dove ogni utente può vedere i propri (e solo i propri) ticket di supporto. Tutto è in un unico posto e si possono usare i tag e tutto il resto.

Ma sia @codinghorror che @sam ci hanno detto molte volte che i permessi specifici per argomento non accadranno (il che capisco perfettamente, dato che aggiunge molta complessità).

---

Vedo due strade da percorrere: usare le caselle di posta dei gruppi #3 e sperare che questi svantaggi vengano risolti, o dare un’altra possibilità all’idea degli argomenti privati #4.

Nel frattempo sono emersi alcuni plugin che si occupano di implementano permessi per argomento, come Restricted Replies - consentono solo a determinati gruppi di rispondere in una categoria - e Discourse Private Replies che rende le risposte invisibili a chiunque tranne all’avviatore dell’argomento (e allo staff) … e sembra fattibile… quindi ho considerato di riprovare con un plugin.

Ma.

Prima di procedere, sarei interessato a sentire

• se altre persone condividono la mia opinione riguardo alle caselle di posta dei gruppi, poiché sono consapevole che questi svantaggi percepiti potrebbero essere molto soggettivi.
• qualsiasi (!!) feedback sull’idea del plugin per argomenti privati.

[Heliosurge (Dan DeMontmorency)]

Questo è davvero un ottimo argomento di discussione.

Le risposte private potrebbero essere in grado di essere “forkate” (derivate) per arrivare a qualcosa di simile alla tua idea. Ma richiederebbe qualcuno che sappia cosa sta facendo o discutendo, magari con l’autore del plugin se si trattasse di un fork sponsorizzato del plugin. Con la sponsorizzazione, sarebbe fantastico esplorare una forma di concetto di crowdfunding.

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 casella di posta di gruppo è un’ottima idea, tuttavia, a mio parere, il sistema PM deve avere un’opzione di ricerca facile da usare, o segnalibri di gruppo con l’uso di un’opzione cartella. Ad esempio, richieste del Cliente A Ottobre 2020.

[Simon_Manning]

@RGJ

Ma sia @codinghorror che @sam ci hanno detto molte volte che i permessi specifici per argomento non accadranno (cosa che capisco perfettamente, dato che aggiunge molta complessità).

Senza conoscere il contesto originale, i permessi specifici per argomento sembrano una prospettiva molto più ampia (e, come hai detto, molto più complessa) di quanto sarebbe necessario per far funzionare il punto 4.

Il modo in cui immagino che questo funzioni sarebbe estendendo i permessi di categoria per includere “Vedi Proprio”. Simile a come sono ora i permessi, uno tra “Vedi” o “Vedi Proprio” deve essere consentito per un gruppo che è stato aggiunto.

Poiché consentire la Creazione consente automaticamente la Risposta, Vedere Ora consentirebbe automaticamente la Creazione: una categoria in cui si possono vedere solo i propri argomenti sarebbe piuttosto inutile se non si possono creare argomenti.

Penso che questo richiederebbe “solo” due modifiche aggiuntive nell’ambito dei permessi. Quando i gruppi a cui appartiene l’utente corrente concedono solo il permesso “Vedi Proprio”:

1. L’elenco degli argomenti dovrebbe essere filtrato per gli argomenti creati dall’utente corrente
2. L’accesso agli argomenti dovrebbe essere negato a meno che l’argomento non sia stato creato dall’utente corrente

Sospetto che in realtà ci sia ulteriore complessità nel gestire cose come l’elenco degli argomenti più recenti, ma probabilmente (forse…) non un’enorme quantità di lavoro aggiuntivo.

@RGJ

• se altre persone condividono la mia opinione riguardo alle caselle di posta di gruppo, poiché sono consapevole che questi svantaggi percepiti potrebbero essere molto soggettivi.

Attualmente non offriamo supporto privato in Discourse, quindi non ho esperienza diretta, ma penso che le mie percezioni siano in linea con le tue.

La reperibilità è importante, sia nel trovare dove chiedere supporto sia nel rivedere le richieste di supporto attuali e passate, il che sembra potenzialmente impegnativo con l’approccio dei messaggi privati di gruppo.

[RGJ (Richard - Communiteq)]

@Heliosurge

Le risposte private potrebbero essere in grado di essere “forkate” per arrivare a qualcosa di simile alla tua idea. Ma richiederà qualcuno che sappia cosa sta facendo o discutendo, magari con l’autore del plugin se si trattasse di un fork sponsorizzato del plugin. Con la sponsorizzazione, sarebbe fantastico esplorare una forma di concetto di crowdfunding.

Grazie per il tuo feedback! Sono l’autore di quel plugin specifico e noi (Communiteq) siamo pronti a investire in questo se avremo la sensazione che sia la direzione giusta. Quindi queste cose non saranno un problema.

@Simon_Manning

Penso che questo richiederebbe “solo” due modifiche aggiuntive nell’ambito dei permessi. Quando i gruppi a cui appartiene l’utente corrente consentono solo il permesso “Vedi Proprio”:

• L’elenco degli argomenti dovrebbe filtrare per gli argomenti creati dall’utente corrente
• L’accesso agli argomenti dovrebbe essere negato a meno che l’argomento non sia stato creato dall’utente corrente

Sì, sembra giusto.

Sto ancora lottando un po’ su come sarebbe esattamente strutturato, dato che Vedi Proprio implica Crea, Crea implica Rispondi, e Rispondi implica Vedi.
Ma non vogliamo che Vedi Proprio implichi Vedi.

[Heliosurge (Dan DeMontmorency)]

Sì, lo vedo. Avrei dovuto prestare più attenzione.

[Simon_Manning]

@RGJ

Sto ancora lottando un po’ su come verrebbe strutturato esattamente, dato che Vedi proprio implica Crea, Crea implica Rispondi e Rispondi implica Vedi.
Ma non vogliamo che Vedi proprio implichi Vedi.

Sì, questo sembra più complicato di quanto pensassi. Sembra che Rispondi non implichi effettivamente Vedi, ma piuttosto che un gruppo venga aggiunto alle autorizzazioni della categoria.
Le autorizzazioni sono un’enumerazione in cui un gruppo ha esattamente uno tra readonly, create_post o full. Capire se un utente può rispondere/creare in una determinata categoria si riduce a ottenere un elenco di tutte le categorie in cui l’utente fa parte di un gruppo che ha (create_post o full) per rispondere o (full) per creare un argomento e verificare se la categoria pertinente è in quell’elenco.

Creare argomenti è facile, avere un valore aggiuntivo nell’enumerazione come full_own funziona semplicemente con esso aggiunto alla costante TOPIC_CREATION_PERMISSIONS in category.rb. Se l’utente ha full o full_own per la categoria pertinente, può creare un argomento.

Le risposte sono più complicate, ma penso che sarebbe appropriato aggiungere uno scope aggiuntivo che restituisca tutte le categorie in cui l’utente ha full_own. Qualcosa come:

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

Quindi in post_guardian.rb, can_create_post? necessita di una condizione aggiuntiva come:

    (!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)
    )

Tuttavia, vedere solo i propri argomenti e garantirlo in modo trasversale nelle pagine delle categorie pertinenti, nelle ultime, nella ricerca e ovunque altro sembra molto più impegnativo. Non l’ho ancora capito.

[tobiaseigen]

Penso che la soluzione più semplice qui sia la porta numero 3, migliorare le caselle di posta di gruppo in modo che funzionino bene per fornire supporto alle persone che accedono, non solo a quelle che inviano e-mail per supporto.

@RGJ

• I messaggi inviati al gruppo di supporto sono difficili da trovare (in realtà, IMHO tutti i messaggi sono difficili da trovare se non si dispone di una notifica da cliccare) e sebbene il personale di supporto abbia una buona panoramica, un utente no. Dove il personale che lavora sui ticket vede una casella di posta di gruppo separata, gli utenti che hanno creato i ticket possono trovarli solo tra i loro messaggi “regolari”.
• Mancanza di supporto per i tag nei messaggi privati: solo il personale può taggare i messaggi privati e gli utenti non possono vedere o filtrare per tag.
• Non esiste un “luogo” dove si possa andare e inviare un messaggio. La possibilità di inviare un messaggio al team di supporto deve essere esplicitamente pubblicizzata da qualche parte (e trovo difficile trovare un posto logico per questo, il più delle volte finisce in una specie di banner).

I tuoi principali reclami sulle caselle di posta di gruppo riguardano la mancanza di funzionalità dal lato utente, il che è legittimo se i tuoi utenti accedono per seguire i ticket e utilizzano anche i messaggi privati per parlare con altre persone sul sito. Non ho riscontrato molto questo finora nel nostro utilizzo delle caselle di posta di gruppo per fornire supporto qui su meta. La maggior parte delle persone a cui forniamo supporto tramite le caselle di posta di gruppo non accede mai: utilizzano principalmente la propria e-mail e quindi possono utilizzare la propria e-mail per organizzare e archiviare la corrispondenza con noi come ritengono opportuno.

Ho alcuni utenti con cui comunico tramite @support-teams qui su meta, quindi chiederò loro come funziona per loro e se hanno suggerimenti. Farò anche ulteriori test da solo per vedere come funziona effettivamente ora. Mi sembra che la richiesta sia:

• consentire agli utenti non staff di vedere i tag dei messaggi (attualmente solo lo staff vede i tag. forse possiamo usare gruppi di tag per questo, per fornire alcuni tag che i non staff possono vedere nei messaggi? )
• fornire un link alle caselle di posta di gruppo nel menu dei messaggi per gli utenti quando inviano messaggi ai gruppi, per vedere i propri messaggi con i gruppi (questo funziona già per lo staff, non sono sicuro di come funzioni per i non staff. ci sono problemi qui tra casella di posta e archivio, che non sono controllati individualmente su base per utente)
• fornire un link per avviare un nuovo messaggio a un gruppo (penso che questo esista nella pagina del gruppo se è consentito inviare messaggi al gruppo)

La possibilità di avviare un nuovo messaggio a un gruppo è qualcosa che ho notato anch’io, come membro del gruppo @support-teams per fornire supporto via e-mail per Discourse for Teams. Se voglio avviare un nuovo messaggio dal team di supporto, devo includere sia il team di supporto sia l’indirizzo e-mail della persona a cui voglio scrivere. Questo è un po’ macchinoso.

Inoltre, nel modo in cui utilizziamo le caselle di posta di gruppo, di solito non chiudiamo i messaggi come faremmo con gli argomenti quando vengono risolti. Li archiviamo semplicemente. Questo ci consente di toglierli dalla nostra vista quando vengono risolti, ma anche di consentire al cliente di dare seguito via e-mail e spostare il messaggio nella casella di posta.

[Simon_Manning]

@tobiaseigen

Inoltre, nel modo in cui utilizziamo le caselle di posta di gruppo, di solito non chiudiamo i messaggi come faremmo con gli argomenti quando vengono risolti. Li archiviamo e basta. Questo ci permette di farli sparire dalla nostra vista quando vengono risolti, ma anche di consentire al cliente di dare seguito via email e spostare il messaggio nella casella di posta.

Questo è un punto piuttosto interessante che non avevo considerato veramente. Con il supporto via email è molto comune che i clienti trovino vecchie email e rispondano ad esse piuttosto che inviare una nuova email. Se un argomento viene chiuso, ciò sarà probabilmente fonte di confusione, nella migliore delle ipotesi, quando scopriranno che la loro email è stata rifiutata.

Dietro la porta numero 4, in qualunque modo ciò possa accadere, sarebbe probabilmente difficile per il personale identificare gli argomenti che non sono stati trattati se non possono essere chiusi, specialmente con un maggior numero di personale di supporto. Il plugin Solved non aiuterà molto qui perché il cliente potrebbe rispondere a un vecchio argomento e i vari membri del personale di supporto non sapranno se necessita di attenzione o se un altro membro del personale lo ha già risolto.

[RGJ (Richard - Communiteq)]

Non sono sicuro che manipolare full, create_post e readonly sia la strada giusta, poiché full e create_post implicano “vedi tutto” in molti posti. Non sarà facile creare un plugin manutenibile in quel modo. Inoltre, penso che non sarebbe molto intuitivo.

Inoltre, sarebbe bello se l’autore dell’argomento potesse aggiungere altre persone (ad esempio un collega) all’argomento, ad esempio menzionandole, e in tal caso questo meccanismo non sarebbe sufficiente.

Al momento la mia idea è di lasciare intatte le autorizzazioni e aggiungere una sezione sotto i gruppi di sicurezza:

---

Abilita argomenti privati in questa categoria
Consenti ai seguenti gruppi di vedere tutti gli argomenti [x staff di supporto] [x supporto vendite]

---

@Simon_Manning

Tuttavia, vedere solo i propri argomenti e garantirlo in modo coerente nella pagina della categoria pertinente, nell’elenco più recente, nella ricerca e ovunque altro sembra molto più impegnativo. Non ci ho ancora capito nulla.

Ho fatto una cosa simile nel plugin delle risposte private, ma per i post in un argomento invece che per gli argomenti in una categoria.
Penso che farò molta strada con alcune patch in TopicGuardian.

@tobiaseigen

Penso che la cosa più facile da fare qui sia la porta numero 3, migliorare le caselle di posta dei gruppi in modo che funzionino bene per fornire supporto alle persone che accedono, non solo a quelle che inviano email per supporto.

Sì, quella potrebbe essere una cosa molto facile da fare. La tua sintesi della mia richiesta è accurata e ho trovato altre due cose che porterebbero i messaggi più in linea con gli argomenti.

• Quando cerco nel forum devo aggiungere esplicitamente in:private alla mia query di ricerca per cercare i miei messaggi. A volte non ricordo davvero se qualcosa era un argomento (più o meno pubblico) o un PM per un gruppo. Perché non includerli per impostazione predefinita?

• Inoltre, penso che sarebbe bello se ci fosse un semplice link ai messaggi nella scheda destra del menu hamburger. Sì, c’è l’icona della busta, ma ha un elenco di messaggi e non un link alla schermata dei messaggi in /my/messages. Quella schermata sembra nascosta.

Gli elementi nel menu a discesa sono in parte gli stessi delle schede nella schermata successiva, ad eccezione di Messaggi e Badge. Quindi, quando ho bisogno di andare ai miei messaggi, clicco sempre su Riepilogo e poi su Messaggi.

Confronta gli elementi nel menu a discesa

con le schede nella schermata del profilo

Ci sono Riepilogo, Attività, Inviti e Preferenze in entrambi, ma Bozze in uno e Notifiche, Messaggi e Badge nell’altro. Quindi “Messaggi” mi sembra molto nascosto (lo stesso vale per Notifiche e Badge, ma non li uso così spesso).

[tobiaseigen]

@RGJ

• Quando cerco nel forum devo aggiungere esplicitamente in:private alla mia query di ricerca per cercare i miei messaggi. A volte non ricordo davvero se qualcosa fosse un argomento (più o meno pubblico) o un PM a un gruppo. Perché non includerli per impostazione predefinita?

Buon punto. Non sono sicuro di quale sia il ragionamento dietro questa barriera. Ho anche notato che quando sei nei tuoi messaggi, aggiunge in:personal per impostazione predefinita, il che è buono! Ma non aggiunge ad esempio in:support-teams per cercare solo nella casella di posta del gruppo messaggi, il che penso sarebbe una buona idea. La ricerca avanzata inoltre non ha un modo semplice per filtrare per casella di posta del gruppo, per quanto ne sappia. (cc @pmusaraj)

@RGJ

Inoltre, penso che sarebbe bello se ci fosse un semplice link ai messaggi nella scheda destra del menu hamburger. Sì, c’è l’icona della busta, ma ha un elenco di messaggi, e non un link alla schermata dei messaggi in /my/messages. Quella schermata sembra nascosta.

Questa è una buona idea, ma penso che ci sia un problema di spazio in quel menu a tendina: non vuoi avere più di 7 elementi in quell’elenco. Inoltre, per la maggior parte delle community non crediamo che vogliamo promuovere la messaggistica… vogliamo che le persone parlino pubblicamente! Per coloro che parlano tramite messaggi, il menu a tendina delle notifiche e le notifiche via email ecc. forniscono un ampio accesso just-in-time ai messaggi che necessitano di attenzione.

Detto questo, stiamo lavorando attivamente a miglioramenti per il sistema di menu (parola chiave: sideburger) quindi terremo conto di questo problema. La barra laterale in Discourse for Teams fornisce già un accesso rapido alle caselle di posta dei gruppi e ai tag monitorati, che possiamo portare nel core di Discourse insieme al progetto sideburger.

Ecco come appare ora quando sono nella casella di posta del gruppo Kabissa, sul mio sito Discourse for Teams:

[Simon_Manning]

@tobiaseigen

• fornire un link per avviare un nuovo messaggio a un gruppo (penso che esista sulla pagina del gruppo se è consentito inviare messaggi al gruppo)

Mi chiedo se designare i gruppi come gruppi di supporto e avere una voce nel menu hamburger basata su questo, con questi stati:

• 0 gruppi designati per il supporto, nessuna voce di menu
• 1 gruppo designato, una voce “Messaggio di supporto” che avvia un messaggio al gruppo

• 1 gruppi designati, una voce “Supporto” che collega a una pagina simile a Gruppi, che mostra tutti i gruppi designati con pulsanti di messaggio

Forse la voce di menu aggiuntiva e la pagina sono eccessive. Una sezione generata aggiuntiva nella pagina Informazioni?

@RGJ

• Inoltre, penso che sarebbe bello se ci fosse un semplice link ai messaggi nella scheda destra del menu hamburger. Sì, c’è l’icona della busta, ma ha un elenco di messaggi, e non un link alla schermata dei messaggi in /my/messages. Quella schermata sembra nascosta.

Non è del tutto ovvio, ma questo è presente nella scheda messaggi, la freccia verso il basso in fondo all’elenco dei messaggi ti porterà alla schermata /my/messages. Non meno clic di Riepilogo, quindi Messaggi, ma un caricamento di pagina in meno.

@tobiaseigen

Ecco come appare ora quando sono nella casella di posta del gruppo Kabissa, sul mio sito Discourse for Teams:

Se fossi un utente che invia un messaggio a Kabissa, quell’argomento sarebbe principalmente associato al gruppo in qualche modo, o l’argomento non avrebbe altro che il mio utente e il gruppo Kabissa autorizzati all’accesso?

Se venisse principalmente associato al gruppo, sarebbe fattibile mostrare quella casella di posta Kabissa nella mia pagina dei messaggi allo stesso modo, sebbene includa ovviamente solo i messaggi a cui ho accesso.

[tobiaseigen]

Quando ho testato qui su meta, creando un utente tl0, sono riuscito a navigare alla pagina del gruppo support-teams e selezionare il pulsante Messaggio per inviare un messaggio al gruppo. Una volta inviato il messaggio, è finito nella mia cartella dei messaggi inviati. Quindi, questo funziona, anche se forse è un po’ troppo nascosto per alcuni casi. Puoi sempre aggiungere collegamenti al menu hamburger come ritieni opportuno per soddisfare le esigenze del tuo sito, o in un banner sulla tua homepage, ecc. Quindi, non vedo che ci sia molto altro da fare qui?

La casella di posta di Kabissa in quello screenshot viene mostrata solo alle persone del gruppo Kabissa. Le persone che inviano messaggi a Kabissa vedrebbero i messaggi nella propria posta.

[jomaxro (Joshua Rosenfeld)]

@RGJ

• Quando cerco nel forum devo aggiungere esplicitamente in:private alla mia query di ricerca per cercare i miei messaggi. A volte non ricordo davvero se qualcosa era un argomento (più o meno pubblico) o un PM a un gruppo. Perché non includerli per impostazione predefinita?

Nota che esiste in:all. Questo mostrerà sia messaggi pubblici che personali in un’unica ricerca.

Se ricordo bene la storia, l’idea era di imporre la separazione tra messaggi personali e argomenti pubblici. Minimizzare qualsiasi confusione su ciò che è pubblico e ciò che è personale. Detto questo, le caselle di posta di gruppo sfocano parecchio quella separazione.

[Simon_Manning]

@tobiaseigen

Puoi sempre aggiungere link al menu hamburger come ritieni opportuno per soddisfare le esigenze del tuo sito, o in un banner sulla tua homepage, ecc. Quindi non vedo che ci sia molto altro da fare qui?

Stavo pensando di aumentare la reperibilità dei gruppi specifici di supporto. L’aggiunta di link al menu hamburger si adatterebbe certamente a una community con un singolo gruppo di supporto (che in realtà è ideale per i miei scopi), ma una community con molti gruppi di supporto potrebbe beneficiare di una pagina o sezione nella pagina “informazioni” generata per gruppi specifici.

Ripensandoci, questo è probabilmente più adatto a un plugin se una community ne ha bisogno.

@tobiaseigen

La casella di posta Kabissa in quello screenshot viene mostrata solo alle persone del gruppo Kabissa. Le persone che inviano messaggi a Kabissa vedrebbero i messaggi nella propria posta.

Quello che stavo cercando di chiedere, forse in modo poco chiaro, era se il modello avesse attualmente abbastanza informazioni per rendere possibile (in futuro) mostrare agli utenti caselle di posta filtrate per i gruppi con cui interagiscono ma a cui non appartengono. Questo si collega alla preoccupazione di @RGJ riguardo ai messaggi inviati ai gruppi che sono difficili da trovare.

Ad esempio, io, come utente normale sul tuo sito Discourse for Teams, potrei vedere una casella di posta Kabissa nei miei messaggi che mostra tutti i messaggi che ho inviato al gruppo Kabissa. (O probabilmente messaggi a cui partecipo.)

Il mio sospetto è che non sia così, probabilmente ha solo i partecipanti su cui basarsi, che potrebbero essere un numero qualsiasi di utenti e gruppi.

[schungx (Stephen Chung)]

@RGJ

Negli ultimi mesi ho parlato con parecchie persone che stanno cercando di impostare un supporto clienti diretto – dove un team di supporto risolve problemi specifici del cliente (confidenziali) – in aggiunta al loro attuale forum di supporto della community (pubblico).

È fantastico che questa tendenza stia prendendo piede! Questo perché trovo che Discourse sia un sistema favoloso per i ticket di supporto privati e, quando funziona, funziona meravigliosamente.

So benissimo che non è per questo che Discourse è stato progettato, e che sto cercando di forzare Discourse a fare qualcosa che non dovrebbe fare, ma tra le caselle di posta private e la piena gloria e le funzionalità degli argomenti principali, sceglierei quest’ultimi ogni giorno e continuerei a provare a forzarli…

[codinghorror (Jeff Atwood)]

@schungx

So bene che non è per questo che Discourse è stato progettato, e che sto cercando di forzare Discourse a fare qualcosa che non dovrebbe fare, ma tra le caselle di posta private e la piena gloria e le funzionalità degli argomenti principali, sceglierei quest’ultimi ogni giorno e continuerei a provare a forzarli…

Questo è qualcosa che vogliamo supportare, (in senso figurato e letterale), ma non vogliamo essere forzati in un angolo di "strumento di supporto". Se hai feedback specifici su come migliorare Discourse in questo ruolo, faccelo sapere.

Siamo sempre in ascolto

[jrgong]

@RGJ

E se ci fosse una sorta di categoria “drop box” dove le persone possono avviare un argomento e interagire con il personale di supporto (in pratica: un gruppo), dove solo loro e i membri di quel gruppo possono vedere l’argomento?

Adoro l’idea! Anche dalla nostra community abbiamo richieste di ticket di supporto separati dalla loro casella di posta utente. Questo tipo di categoria in cui gli utenti possono vedere solo i propri ticket sarebbe super utile.

[jerry0 (Jerry)]

@codinghorror

Questo è qualcosa che vogliamo supportare, (in senso figurato e letterale), ma non vogliamo essere relegati nell’angolo di uno “strumento di supporto”. Se avete feedback specifici su come migliorare Discourse in questo ruolo, fatecelo sapere.

Grazie!

Utilizziamo un gruppo di messaggi privati per il supporto privato: funziona bene. La lamentela principale degli utenti intensivi del sistema di supporto è l’impossibilità di cercare nei loro messaggi.

Abbiamo cercato di insegnare loro che devono aggiungere il codice in:personal alla query di ricerca per cercare i loro messaggi, ma non è intuitivo e, a dire il vero, non ho visto un singolo utente riuscire a farlo, si arrendono e si lamentano di non poter cercare nei loro messaggi.

Non capiscono nemmeno a cosa serva questo “suggerimento” sotto la casella di ricerca.

E se vanno alla ricerca avanzata, potrebbero essere abbastanza avanzati da selezionare il pulsante radio “cerca messaggi”, ma tutto inizia a sembrare strano quando questo aggiunge le parole in:personal e a quel punto si arrendono.

Se ci fosse un modo molto più intuitivo per cercare messaggi che non comportasse l’aggiunta di codice alla casella di ricerca, sarebbe un enorme miglioramento.

In caso contrario, utilizzare un linguaggio più intuitivo, ad esempio il codice “in:messages”, sarebbe un leggero miglioramento.

[pfaffman (Jay Pfaffman)]

O forse è sufficiente includere le conversazioni private nella ricerca per impostazione predefinita?

[jerry0 (Jerry)]

Certamente, sarebbe meraviglioso!

Un’impostazione “Cerca PM per impostazione predefinita” (che normalmente è disattivata) sarebbe davvero l’ideale.

In questo modo, qualsiasi preoccupazione riguardo agli utenti che si confondono tra i risultati di ricerca per argomenti normali e argomenti PM (che non ho) potrebbe essere bilanciata rispetto al fatto che le persone non possano affatto cercare argomenti PM (cosa che ho).