Oferecendo "suporte privado" como parte de uma comunidade de suporte público

[RGJ (Richard - Communiteq)]

Tenho pensado nisso há algum tempo e decidi expor minhas ideias ao grupo e perguntar a todos o que acham.

Nos últimos meses, conversei com muitas pessoas que estão tentando configurar suporte direto ao cliente - onde uma equipe de suporte resolve (confidenciais) problemas específicos do cliente - como um complemento ao seu fórum de suporte comunitário (público) existente.
A maioria dessas soluções envolve os plugins ‘assign’, ‘solved’ e ‘ticket’, e então existem várias abordagens (mas parece que não há uma solução perfeita e é por isso que estou criando este tópico).

Solução nº 1: Criar categorias / grupos separados para cada cliente

Isso só funciona quando você tem uma quantidade relativamente pequena de clientes, não quando você tem centenas.

Solução nº 2: A descrita por schungx “Como usar o Discourse como um sistema privado de suporte/ticket”

O principal problema aqui é: “(…) que você está criando uma plataforma de tickets dedicada, ou que pelo menos não haverá sobreposição entre os usuários da sua interface web do Discourse e aqueles que solicitam tickets de suporte.”

Mas este tópico aborda uma das principais questões: “Você analisou o sistema de segurança/permissões e não encontra o que deseja: basicamente, permissões puras de Criar e Criar/Responder não existem.” Voltarei a isso abaixo.

Solução nº 3: Caixas de entrada de grupo.

A ideia original de Sam “Discourse como um portal de suporte por e-mail privado” que se tornou caixas de entrada de grupo. Você configura uma caixa de entrada de grupo, a atribui à sua equipe de suporte, e todos podem enviar mensagens para a caixa de entrada.
Esta é agora a solução preferida e funciona.

No entanto, eu não gosto muito dela.

Na minha opinião (!), há uma série de desvantagens nessa abordagem, e as três principais são:

• Mensagens enviadas para o grupo de suporte são difíceis de encontrar (na verdade, na minha opinião, todas as mensagens são difíceis de encontrar se você não tiver uma notificação para clicar) e, embora a equipe de suporte tenha uma boa visão geral, um usuário não tem. Onde os usuários da equipe que trabalham nos tickets veem uma caixa de entrada de grupo separada, os usuários que criaram os tickets só podem encontrá-los entre seus e-mails privados ‘regulares’.
• Falta de suporte a tags em e-mails privados: Apenas a equipe pode marcar e-mails privados e os usuários não podem ver ou filtrar por tags.
• Não há um “lugar” para onde se possa ir e enviar uma mensagem. A possibilidade de enviar uma mensagem para a equipe de suporte deve ser explicitamente anunciada em algum lugar (e acho difícil encontrar um lugar lógico para isso, na maioria das vezes acaba em algum tipo de banner).

Resumindo, para mim parece um pouco “improvisado” e um compromisso entre tópicos de categoria e e-mails privados.

#4 Tópicos privados

Esta ideia foi apresentada várias vezes (também aqui aqui e aqui), e eu já mencionei as permissões de “criar” e “criar/responder” acima.

E se houvesse algum tipo de categoria de ‘caixa de correio’ onde as pessoas pudessem iniciar um tópico e interagir com a equipe de suporte (basicamente: um grupo), onde apenas elas e os membros desse grupo pudessem ver o tópico?
Isso seria uma solução perfeita para este caso de uso. Teríamos uma categoria de “suporte” claramente definida onde cada usuário pode ver seus (e apenas seus) tickets de suporte. Tudo estaria em um único lugar e você poderia usar tags e tudo mais.

Mas tanto @codinghorror quanto @sam nos disseram muitas vezes que permissões específicas de tópico não acontecerão (o que eu entendo perfeitamente, pois adiciona muita complexidade).

---

Vejo duas maneiras de seguir em frente: usar as caixas de entrada de grupo #3 e esperar que essas desvantagens sejam resolvidas, ou dar outra chance à ideia de tópico privado #4.

Enquanto isso, alguns plugins que mexem com implementam permissões por tópico surgiram, como Restricted Replies - permite apenas que certos grupos respondam em uma categoria - e Discourse Private Replies que torna as respostas invisíveis para todos, exceto para o iniciador do tópico (e a equipe)… e parece factível… então tenho considerado tentar isso novamente em um plugin.

Mas.

Antes de prosseguir com isso, eu estaria interessado em ouvir

• se outras pessoas compartilham minha opinião em relação às caixas de entrada de grupo, pois estou ciente de que essas desvantagens percebidas podem ser muito subjetivas.
• qualquer (!!) feedback sobre a ideia do plugin de tópicos privados

[Heliosurge (Dan DeMontmorency)]

Este é, de fato, um ótimo tópico para discutir.

As respostas privadas podem ser talvez “forked” (derivadas) para criar algo alinhado à sua ideia. Mas exigirá alguém que saiba o que está fazendo ou discutindo, talvez com o autor do plugin, se for um “fork” de plugin patrocinado. Com patrocínio, seria ótimo explorar uma forma de conceito de financiamento coletivo.

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…

---

A caixa de correio de grupo é uma ótima ideia, no entanto, na minha opinião, o sistema de PM precisa ter uma opção de Pesquisa fácil de usar, ou Marcadores de Grupo com uma opção de Pasta. Ou seja, solicitações do Cliente A de Outubro de 2020.

[Simon_Manning]

@RGJ

Mas tanto o @codinghorror quanto o @sam nos disseram muitas vezes que permissões específicas de tópico não acontecerão (o que eu entendo perfeitamente, pois adiciona muita complexidade).

Sem conhecer o contexto original, permissões específicas de tópico parecem uma perspectiva muito mais ampla (e, como você disse, muito mais complexa) do que o que seria necessário para fazer o #4 funcionar.

A maneira como eu imaginaria isso funcionar seria estendendo as permissões de categoria para incluir Ver Próprio. Semelhante a como as permissões são agora, uma de “Ver” ou “Ver Próprio” deve ser permitida para um grupo que foi adicionado.

Como permitir Criar automaticamente permite Responder, Ver Agora permitiria automaticamente Criar - uma categoria onde você só pode ver seus próprios tópicos seria meio inútil se você não puder criar tópicos.

Acho que isso “apenas” precisaria de duas alterações adicionais no território de permissões. Quando os grupos aos quais o usuário atual pertence só concedem permissão Ver Próprio:

1. A listagem de tópicos deve ser filtrada para tópicos criados pelo usuário atual
2. O acesso aos tópicos deve ser negado, a menos que o tópico tenha sido criado pelo usuário atual

Suspeito que, na realidade, há complexidade adicional lidando com coisas como a lista de tópicos mais recentes, mas provavelmente (talvez…) não uma quantidade enorme de trabalho extra.

@RGJ

• se outras pessoas compartilham minha opinião em relação às caixas de entrada de grupo, pois estou ciente de que essas desvantagens percebidas podem ser muito subjetivas.

Atualmente, não oferecemos suporte privado no Discourse, então não tenho experiência em primeira mão, mas acho que minhas próprias percepções estão alinhadas com as suas.

A descoberta é importante, tanto para encontrar onde pedir suporte quanto para revisar consultas de suporte atuais e passadas, o que parece ser potencialmente desafiador com a abordagem de mensagens privadas de grupo.

[RGJ (Richard - Communiteq)]

@Heliosurge

As respostas privadas talvez possam ser adaptadas para surgir com algo em linha com a sua ideia. Mas exigirá alguém que saiba o que está fazendo ou discutindo, talvez com o autor do plugin, se for uma adaptação de plugin patrocinada. Com patrocínio, seria ótimo explorar uma forma de conceito de financiamento coletivo.

Obrigado pelo seu feedback! Acontece que sou o autor desse plugin específico, e nós (Communiteq) estamos preparados para investir nisso se sentirmos que essa é a direção certa. Portanto, essas coisas não serão um problema.

@Simon_Manning

Eu acho que isso “apenas” precisaria de duas alterações adicionais no território de permissões. Quando os grupos aos quais o usuário atual pertence só permitem a permissão “Ver Próprio”:

• A listagem de tópicos deve ser filtrada para tópicos criados pelo usuário atual
• O acesso aos tópicos deve ser negado, a menos que o tópico tenha sido criado pelo usuário atual

Sim, isso parece certo.

Ainda estou lutando um pouco com a forma como isso seria exatamente estruturado, já que Ver Próprio implica Criar, Criar implica Responder, e Responder implica Ver.
Mas não queremos que Ver Próprio implique Ver.

[Heliosurge (Dan DeMontmorency)]

Sim, eu vejo isso. Deveria ter prestado mais atenção.

[Simon_Manning]

@RGJ

Ainda estou com um pouco de dificuldade em como isso seria exatamente estruturado, já que Ver Próprio implica Criar, Criar implica Responder, e Responder implica Ver.
Mas não queremos que Ver Próprio implique Ver.

Sim, isso parece ser mais complicado do que eu pensava. Parece que Responder não implica Ver, mas sim que um grupo é adicionado às permissões de categoria.
As permissões são uma enumeração onde um grupo tem exatamente um de readonly, create_post ou full. Descobrir se um usuário pode responder/criar em uma determinada categoria se resume a obter uma lista de todas as categorias onde o usuário faz parte de um grupo que tem (create_post ou full) para responder ou (full) para criar um tópico e verificar se a categoria relevante está nessa lista.

Criar tópicos é fácil, ter um valor extra na enumeração como full_own funciona com ele adicionado à constante TOPIC_CREATION_PERMISSIONS em category.rb. Se o usuário tiver full ou full_own para a categoria relevante, ele poderá criar um tópico.

Responder é mais complicado, mas eu acho que seria apropriado adicionar um escopo adicional que retorna todas as categorias onde o usuário tem full_own. Algo como:

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

Então, em post_guardian.rb, can_create_post? precisa de uma condição extra como:

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

No entanto, ver apenas os próprios tópicos e garantir que isso seja verdadeiro nas páginas de categoria relevantes, mais recentes, pesquisa e em qualquer outro lugar parece muito mais desafiador. Eu não descobri isso.

[tobiaseigen]

Acredito que a solução mais fácil aqui seja a porta número 3, melhorar as caixas de entrada de grupo para que funcionem bem no suporte a pessoas que fazem login, não apenas para pessoas que enviam e-mails para suporte.

@RGJ

• Mensagens enviadas para o grupo de Suporte são difíceis de encontrar (na verdade, na minha opinião, todas as mensagens são difíceis de encontrar se você não tiver uma notificação para clicar) e, embora a equipe de suporte tenha uma boa visão geral, um usuário não tem. Onde os usuários da equipe que trabalham nos tickets veem uma caixa de entrada de grupo separada, os usuários que criaram os tickets só os encontram entre suas mensagens particulares ‘regulares’.
• Falta de suporte de marcação em mensagens particulares: apenas a equipe pode marcar mensagens particulares e os usuários não podem ver ou filtrar por marcações.
• Não há um “lugar” para onde se possa ir e enviar uma mensagem. A possibilidade de enviar uma mensagem para a equipe de Suporte deve ser explicitamente anunciada em algum lugar (e acho difícil encontrar um lugar lógico para isso, na maioria das vezes acaba em algum tipo de banner).

Suas principais reclamações sobre caixas de entrada de grupo parecem ser sobre a falta de funcionalidade do lado do usuário, o que é legítimo se seus usuários fazem login para acompanhar tickets e também usam mensagens particulares para conversar com outras pessoas no site. Eu não encontrei isso muito até agora em nosso uso de caixas de entrada de grupo para fornecer suporte aqui no meta. A maioria das pessoas para as quais fornecemos suporte via caixas de entrada de grupo nunca faz login - elas usam principalmente seu próprio e-mail e, portanto, podem usar seu e-mail para organizar e arquivar suas correspondências conosco como acharem melhor.

Tenho alguns usuários com quem me comunico via @support-teams aqui no meta, então perguntarei a eles como funciona para eles e se eles têm alguma sugestão. Também farei mais testes por conta própria para ver como isso realmente funciona agora. Parece-me que o pedido é:

• permitir que usuários não-staff vejam marcações de mensagens (atualmente apenas staff veem marcações. talvez possamos usar grupos de marcações para isso, para fornecer algumas marcações que não-staff possam ver nas mensagens? )
• fornecer um link para caixas de entrada de grupo no menu de mensagens para usuários quando eles estiverem enviando mensagens para grupos, para ver suas próprias mensagens com grupos (isso já funciona para staff, não tenho certeza de como funciona para não-staff. há problemas aqui com caixa de entrada vs arquivo, que não são controlados individualmente por usuário)
• fornecer um link para iniciar uma nova mensagem para um grupo (acho que isso existe na página do grupo se o envio de mensagens para o grupo for permitido)

A capacidade de iniciar uma nova mensagem para um grupo é algo que até eu notei, como membro do grupo @support-teams para fornecer suporte por e-mail do Discourse for Teams. Se eu quiser iniciar uma nova mensagem da equipe de suporte, tenho que incluir tanto a equipe de suporte quanto o endereço de e-mail da pessoa para quem quero escrever. Isso é um pouco desajeitado.

Além disso, da maneira como usamos as caixas de entrada de grupo, geralmente não fechamos mensagens como faríamos com tópicos quando eles são resolvidos. Nós apenas os arquivamos. Isso nos permite tirá-los de vista para nós mesmos quando são resolvidos, mas também permite que o cliente acompanhe por e-mail e mova a mensagem de volta para a caixa de entrada.

[Simon_Manning]

@tobiaseigen

Além disso, a forma como usamos caixas de entrada de grupo, nós não costumamos fechar mensagens como faríamos com tópicos quando eles são resolvidos. Nós apenas os arquivamos. Isso nos permite tirá-los de vista quando são resolvidos, mas também permite que o cliente acompanhe por e-mail e mova a mensagem de volta para a caixa de entrada.

Este é um ponto bastante interessante que eu não tinha realmente considerado. Com o suporte por e-mail, é muito comum que os clientes encontrem e-mails antigos e respondam a eles em vez de enviar um novo e-mail. Se um tópico for fechado, isso provavelmente será confuso, na melhor das hipóteses, quando eles encontrarem seu e-mail rejeitado.

Atrás da porta número 4, de qualquer forma que isso pudesse acontecer, provavelmente seria difícil para a equipe identificar tópicos que não foram tratados se eles não puderem ser fechados, especialmente com um número maior de pessoal de suporte. O plugin Solved não ajudará realmente aqui porque o cliente pode responder a um tópico antigo e os vários membros da equipe de suporte não saberão se ele precisa de atenção ou se outro membro da equipe já o resolveu.

[RGJ (Richard - Communiteq)]

Não tenho certeza se mexer com full, create_post e readonly é a melhor abordagem, já que full e create_post implicam “ver tudo” em muitos lugares. Não será fácil criar um plugin de fácil manutenção dessa forma. Além disso, acho que não seria muito intuitivo.

Além disso, seria bom se o autor do tópico pudesse adicionar outras pessoas (por exemplo, um colega) ao tópico, por exemplo, mencionando-as, e nesse caso esse mecanismo não seria suficiente.

No momento, minha ideia é deixar as permissões intactas e adicionar uma seção abaixo dos grupos de segurança:

---

Habilitar tópicos privados nesta categoria
Permitir que os seguintes grupos vejam todos os tópicos [x staff de suporte] [x suporte de vendas]

---

@Simon_Manning

No entanto, ver apenas os próprios tópicos e garantir isso em toda a página da categoria relevante, mais recente, pesquisa e em qualquer outro lugar parece muito mais desafiador. Eu não descobri isso.

Fiz algo semelhante no plugin de respostas privadas, mas para posts em um tópico em vez de tópicos em uma categoria.
Acho que chegarei longe com alguns patches em TopicGuardian.

@tobiaseigen

acho que o mais fácil de resolver aqui é a porta número 3, melhorar as caixas de entrada de grupo para que funcionem bem para fornecer suporte a pessoas que fazem login, não apenas para pessoas que enviam e-mail para suporte.

Sim, essa poderia ser uma solução bem fácil. Seu resumo da minha solicitação está correto, e encontrei mais duas coisas que trariam as mensagens mais em sintonia com os tópicos.

• Quando pesquiso no fórum, tenho que adicionar explicitamente in:private à minha consulta de pesquisa para pesquisar minhas mensagens. Às vezes, realmente não me lembro se algo era um tópico (mais ou menos público) ou uma mensagem privada para um grupo. Por que não incluí-los por padrão?

• Além disso, acho que seria bom ter um link simples para as mensagens na aba direita do menu hambúrguer. Sim, há o ícone do envelope, mas ele tem uma lista de mensagens, e não um link para a tela de mensagens em /my/messages. Essa tela parece escondida.

Os itens no menu suspenso são parcialmente os mesmos das abas na próxima tela, exceto por Mensagens e Badges. Então, quando preciso ir às minhas mensagens, sempre clico em Resumo e depois em Mensagens.

Compare os itens no menu suspenso

com as abas na tela de perfil

Há Resumo, Atividade, Convites e Preferências em ambos, mas Rascunhos em um e Notificações, Mensagens e Badges no outro. Então, “Mensagens” parece muito escondido para mim (o mesmo vale para Notificações e Badges, mas não os uso com tanta frequência).

[tobiaseigen]

@RGJ

• Ao pesquisar no fórum, preciso adicionar explicitamente in:private à minha consulta de pesquisa para pesquisar minhas mensagens. Às vezes, realmente não me lembro se algo era um tópico (mais ou menos público) ou uma mensagem privada para um grupo. Por que não incluí-los por padrão?

Bom ponto. Não tenho certeza qual é o raciocínio por trás dessa barreira. Também notei que, quando você está em suas mensagens, ele adiciona in:personal por padrão, o que é bom! Mas ele não adiciona, por exemplo, in:support-teams para pesquisar apenas na caixa de entrada do grupo por mensagens, o que eu acho que seria uma boa ideia. A pesquisa avançada também não tem uma maneira fácil de filtrar por caixa de entrada do grupo, que eu saiba. (cc @pmusaraj)

@RGJ

Além disso, acho que seria bom se houvesse um link simples para as mensagens na aba direita do menu hambúrguer. Sim, há o ícone do envelope, mas ele tem uma lista de mensagens e não um link para a tela de mensagens em /my/messages. Essa tela parece escondida.

Esta é uma boa ideia, mas acho que há um problema de espaço naquela lista suspensa - você não quer ter mais de 7 itens nessa lista. Além disso, para a maioria das comunidades, não acredito que realmente queiramos promover mensagens… queremos que as pessoas conversem publicamente! Para aqueles que estão conversando por mensagens, a lista suspensa de notificações e as notificações por e-mail, etc., fornecem acesso suficiente no momento certo às mensagens que precisam de atenção.

Dito isso, estamos trabalhando ativamente em melhorias para o sistema de menu (palavra-chave: sideburger), então levaremos essa questão em consideração. A barra lateral no Discourse for Teams já oferece acesso rápido a caixas de entrada de grupo e tags observadas, que podemos trazer para o discourse principal junto com o projeto sideburger.

Veja como está agora quando estou na caixa de entrada do grupo Kabissa, no meu site Discourse for Teams:

[Simon_Manning]

@tobiaseigen

• fornecer um link para iniciar uma nova mensagem para um grupo (acho que isso existe na página do grupo se a mensagem para o grupo for permitida)

Eu me pergunto sobre designar grupos como grupos de suporte e ter uma entrada de menu hambúrguer com base nisso, com estes estados:

• 0 grupos designados para suporte, sem entrada de menu
• 1 grupo designado, uma entrada “Mensagem de Suporte” que inicia uma mensagem para o grupo

• 1 grupos designados, uma entrada “Suporte” que vincula a uma página semelhante a Grupos, exibindo todos os grupos designados com botões de Mensagem

Talvez a entrada de menu e a página extras sejam um exagero. Uma seção gerada adicional na página Sobre?

@RGJ

• Além disso, acho que seria bom se houvesse um link simples para as mensagens na aba direita do menu hambúrguer. Sim, existe o ícone do envelope, mas ele tem uma lista de mensagens, e não um link para a tela de mensagens em /my/messages. Essa tela parece escondida.

Não é totalmente óbvio, mas isso está lá na aba de mensagens, a seta para baixo na parte inferior da lista de mensagens o levará para a tela /my/messages. Não menos cliques do que Resumo, então Mensagens, mas uma carga de página a menos.

@tobiaseigen

É assim que parece agora quando estou na caixa de entrada do grupo Kabissa, no meu site Discourse for Teams:

Se eu fosse um usuário enviando uma mensagem para Kabissa, esse tópico estaria primariamente associado ao grupo de alguma forma, ou o tópico não teria mais do que meu usuário e o grupo Kabissa tendo acesso permitido?

Se ele for primariamente associado ao grupo, seria viável mostrar essa caixa de entrada Kabissa na minha página de mensagens da mesma forma, embora obviamente incluindo apenas mensagens às quais eu tenho acesso.

[tobiaseigen]

Quando testei isso aqui no meta, criando um usuário tl0, consegui navegar até a página do grupo support-teams e selecionar o botão Message para enviar uma mensagem ao grupo. Assim que postei a mensagem, ela foi para a minha pasta de mensagens enviadas. Então, isso está funcionando, embora talvez um pouco escondido para alguns casos. Você sempre pode adicionar links ao menu hambúrguer como achar melhor para atender aos propósitos do seu site, ou em um banner na sua página inicial, etc. Então, não vejo que há muito mais a ser feito aqui?

A caixa de entrada Kabissa nessa captura de tela é mostrada apenas para pessoas do grupo Kabissa. Pessoas que enviam mensagens para Kabissa veriam as mensagens em suas próprias mensagens.

[jomaxro (Joshua Rosenfeld)]

@RGJ

• Quando pesquiso no fórum, tenho que adicionar explicitamente in:private à minha consulta de pesquisa para pesquisar minhas mensagens. Às vezes, realmente não me lembro se algo era um tópico (mais ou menos público) ou uma mensagem pessoal para um grupo. Por que não incluí-los por padrão?

Note que in:all existe. Isso mostrará mensagens públicas e pessoais em uma única pesquisa.

Se me lembro corretamente da história, a ideia era impor a separação entre mensagens pessoais e tópicos públicos. Minimizar qualquer confusão sobre o que é público e o que é pessoal. Dito isso, as caixas de entrada de grupo obscurecem bastante essa separação.

[Simon_Manning]

@tobiaseigen

Você sempre pode adicionar links ao menu hambúrguer como achar melhor para atender aos propósitos do seu site, ou em um banner na sua página inicial, etc. Portanto, não vejo que haja muito mais a ser feito aqui?

Eu estava pensando em aumentar a descoberta de grupos específicos de suporte. Adicionar links ao menu hambúrguer certamente serviria a uma comunidade com um único grupo de suporte (o que é realmente ideal para meus próprios propósitos), mas uma comunidade com muitos grupos de suporte poderia se beneficiar de uma página ou seção na página “sobre” gerada para grupos especificados.

Em retrospecto, isso é provavelmente mais adequado para um plugin, se uma comunidade precisar disso.

@tobiaseigen

A caixa de entrada Kabissa nessa captura de tela é mostrada apenas para pessoas do grupo Kabissa. As pessoas que enviam mensagens para Kabissa veriam as mensagens em suas próprias mensagens.

O que eu estava tentando perguntar, talvez mal formulado, era se o modelo atualmente tem informações suficientes para possibilitar (no futuro) mostrar aos usuários caixas de entrada filtradas para grupos com os quais eles interagem, mas aos quais não pertencem. Isso se relaciona à preocupação de @RGJ de que as mensagens enviadas para grupos são difíceis de encontrar.

Por exemplo, eu, como um usuário normal no seu site Discourse for Teams, poderia ver uma caixa de entrada Kabissa em minhas mensagens que mostra todas as mensagens que enviei para o grupo Kabissa. (Ou provavelmente mensagens das quais sou participante.)

Minha suspeita é que não, provavelmente tem apenas os participantes para se basear, o que pode ser qualquer número de usuários e grupos.

[schungx (Stephen Chung)]

@RGJ

Nos últimos meses, conversei com muitas pessoas que estão tentando configurar suporte direto ao cliente - onde uma equipe de suporte resolve problemas específicos (confidenciais) do cliente - como um complemento ao seu fórum de suporte comunitário (público) existente.

É ótimo que isso esteja se popularizando! Isso porque acho que o Discourse é um sistema fabuloso para tickets de suporte privados e, quando funciona, funciona maravilhosamente.

Sei muito bem que este não é o propósito do Discourse, e que estou tentando forçar o Discourse a fazer algo que não deveria fazer, mas entre caixas de entrada privadas versus toda a glória e recursos dos tópicos principais, eu escolheria o último a qualquer dia e continuaria tentando forçar…

[codinghorror (Jeff Atwood)]

@schungx

Sei muito bem que não é para isso que o Discourse foi projetado, e que estou tentando forçar o Discourse a fazer algo que não deveria, mas entre caixas de entrada privadas vs. toda a glória e recursos dos tópicos principais, eu escolheria o último a qualquer dia e continuaria tentando forçar…

Isso é algo que queremos apoiar, (figurativa e literalmente), mas não queremos ser forçados a um canto de "ferramenta de suporte". Se você tiver feedback específico sobre como tornar o Discourse melhor nesse papel, nos avise.

Estamos sempre ouvindo

[jrgong]

@RGJ

E se houvesse algum tipo de categoria de ‘caixa de entrada’ onde as pessoas pudessem iniciar um tópico e interagir com a equipe de suporte (basicamente: um grupo), onde apenas eles e membros desse grupo pudessem ver o tópico?

Adorei a ideia! Mesmo em nossa comunidade, recebemos solicitações de tickets de suporte separados de suas caixas de entrada de usuário. Esse tipo de categoria em que os usuários só podem ver seus próprios tickets seria super útil.

[jerry0 (Jerry)]

@codinghorror

Isso é algo que queremos apoiar, (figurativa e literalmente), mas não queremos ser forçados a um canto de "ferramenta de suporte". Se você tiver feedback específico sobre como tornar o Discourse melhor nesse papel, nos diga.

Obrigado!

Usamos um grupo de PM para suporte privado - funciona bem. A principal reclamação dos usuários intensivos do sistema de suporte é a incapacidade de pesquisar suas mensagens.

Tentamos ensiná-los que eles devem adicionar o código in:personal à consulta de pesquisa para pesquisar suas mensagens, mas não é intuitivo e, para ser franco, não vi um único usuário conseguir fazer isso, eles simplesmente desistem e reclamam que não conseguem pesquisar suas mensagens.

Eles nem sequer entendem para que serve esta "sugestão" abaixo da caixa de pesquisa.

E se eles forem para a pesquisa avançada, eles podem ser avançados o suficiente para marcar o botão de rádio "pesquisar mensagens", mas tudo começa a parecer estranho quando isso adiciona as palavras in:personal e eles desistem naquele ponto.

Se houvesse uma maneira muito mais intuitiva de pesquisar mensagens que não envolvesse adicionar código à caixa de pesquisa, isso seria uma melhoria enorme.

Se não, apenas usar uma linguagem mais intuitiva, por exemplo, o código "in:messages" seria uma pequena melhoria.

[pfaffman (Jay Pfaffman)]

Ou talvez apenas fazer com que a pesquisa inclua pms por padrão?

[jerry0 (Jerry)]

De fato - isso seria maravilhoso!

Uma configuração “Pesquisar MPs por padrão” (que normalmente está desativada) seria realmente ideal.

Dessa forma, qualquer preocupação sobre os usuários se confundirem entre os resultados de pesquisa para tópicos normais e tópicos de MP (que eu não tenho) poderia ser equilibrada com as pessoas não conseguindo pesquisar tópicos de MP (que eu tenho).