Verwenden Sie Discourse als privates Support-/Ticket-System

[schungx (Stephen Chung)]

On and off I’ve seen posters asking about how to use Discourse as a support (or ticketing) platform. I’d like to share my setup here for those with similar needs.

Background

You run/work for an organization. You need to provide pre-sales, after-sales, technical and/or one-on-one support to your customers, agents, distributors and/or partners (which organization doesn’t?).

What is Discourse

Discourse is primarily a forums software, geared towards public, open conversations of various topics. It is incredibly modern and performant, runs at lightning speed, and you have a lot of flexibility in how to setup your environment.

You want to see if you can coerce this fabulous piece of software to do what it isn’t originally designed to do.

Prior Art

• Configure incoming email to create new topics or group messages
• Discourse as a private email support portal
• Set up reply by email with POP3 polling
• Private Topics - are they supported?
• Using discourse as a community ticket system
• How to optimize issue/support ticket like workflow?
• Can incoming Discourse email support replace old ticket portals?
• Create/See and Create Permissions (again)

What You Want

Your customers will open issues, or help tickets, on the system. They either open it under their own folder/category, or you can have some systematic/manual way of reclassifying them later on.

There may be sensitive things discussed, so by default you don’t want each customer to be able to see the issues or inquiries raised by other customers. In other words, each customer conversation should be private.

You want your support teams to each work on their allocated areas/categories. In other words, your teams should be able to see a list of all the support requests in their own categories, and be able to easily sort through them, manage them and follow-up on them without a lot of searching and filtering.

Some information may be sensitive, so each team’s area may be separated from another team’s, so they cannot view each other’s data.

Note: This method assumes that you are creating a dedicated ticketing platform, or that at the very least there will be no overlap between the users of your Discourse web interface and those requesting support tickets.
In the event that you might need to support users who are already on the same instance, consider instead using private messages to a group, and configure inbound email for the group inbox.

Your Problem

1. Some core features are geared towards an open community, and may not be relevant to a private support forum, for example the badges.

2. You looked at the security/permissions system and you don’t find what you want: basically pure Create and Create/Reply permissions do not exist.

3. Your customers don’t really want to go through the hassle of creating an account on your forum just to ask a support question. But you also don’t want to open up your forum to the public and have silly posters come in and waste your time.

   You want a way to detail with these one-off inquiries quickly, but leave open the possibility of maintaining a long-term relationship with certain customers.

4. A lot of your customers work with emails, and you want to reply to them via email, but you also want your support teams to be able to manage these requests quickly and easily without digging through piles of email.

How it Will Work

• You have a bunch of email addresses published for customers to send inquiries. For example, you may have an email address called wonderful_product@support.example.com for people to send questions regarding the Wonderful Product product line of your company.

• A customer sends an email to this address.

• The email is automatically turned into a topic in the appropriate Wonderful Product category.

• A staged user (say, MrFoo) with no rights is created on the system to track all the requests sent by that email.

• You internal team support staff, under the group WonderfulProductTeam, which has Reply/See permission on the Wonderful Product category, sees the topic and post replies.

• Each reply turns into a reply email back to the originating customer.

• The customer feels that his/her email is being replied personally.

• The customer has no way to see the emails of any other customer on the system. Meanwhile, the WonderProductTeam sees all the emails sent to wonderful_product@support.example.com all together in a single list.

• You find that user MrFoo has been a great contributor and would actually like to involve him into your support pipeline. Go to his user profile and send him an invitation to become a member. Put him in an appropriate Group with appropriate access rights.

• MrFoo, now an valued member of your support organizatio, logs in and sees all his previous emails neatly under his account.

Setup Instructions

Basic Discourse setup

• Turn off Settings|Basic Setup|enable badges because badges are not awarded for posts in non-Everyone categories, which most of your categories will probably be. They will just confuse your users. Keep it if you have large, open-to-all-users categories.

• Turn on Settings|Basic Setup|enable whispers if you want whispers. This may be useful when you have many moderators.

• Turn on Settings|Login|invite only unless you want to allow customers to self-register themselves. You may not want the hassle.

• Turn on Settings|Login|login required because you are not running a public forum.

• Set Settings|Trust Levels|default trust level to 0 to make sure staged users created via email is level 0.

• Set Settings|Trust Levels|default invitee trust level to 1 to make sure that the users you actually want to be on the system are level 1.

• Turn on Settings|Email|enable staged users

• (Optional) Settings|Login|must approve users may not be necessary if your forum runs on invitation only.

• (Optional) Set Settings|Posting|approve new topics unless trust level to 1 so that your staged users (which will be created as level 0) will have their topics pending staff approval.

  Note: As of 1.9.0beta13 this doesn’t work because topic approvals by-pass all staged users. This may be corrected in the future.

• Turn off SSO because you obviously don’t want any unknown persons to sign into your forum.

Set Up the Appropriate Email Addresses

• On your email system, setup a MASTER mail-in email account, for example: master@support.example.com.

• For each area/team/category, create a new, specific email account, for example: wonderful_product@support.example.com.

• FORWARD all emails to those specific accounts to the MASTER email account. For example, an automatic forwarding should be created to forward all mail received by wonderful_product@support.example.com to master@support.example.com.

Turn on email in

• Turn on Settings|Email|reply by email enabled

• Turn on Settings|Email|email in

• Turn on Settings|Email|pop3 polling enabled

• (Optional) Turn on Settings|Email|pop3 polling ssl if your POP3 email server requires SSL.

• (Optional) Turn on Settings|Email|pop3 polling openssl verify if your POP3 server uses SSL.

• Turn on Settings|Email|reply by email enabled

• Set Settings|Email|reply by email address to the MASTER email account in the section above (for example: master@support.example.com).

• (IMPORTANT) If your email system does NOT support the + feature, then turn off Settings|Email|find related post with key. This will use each email’s In Reply To header to find the correct thread, with certain security considerations.

• Set Settings|Email|pop3 polling host, pop3 polling port, pop3 polling username, pop3 polling password for your POP3 email server. The username and password should be for the MASTER email address.

• Set Settings|Email|email in min trust to 0 because your staged users will be created with trust level 0.

• Set Settings|Email|maximum staged users per email to a small number unless you have a good reason to allow creating large number of staged users from an email.

• Set up suspected SPAM email domains in Settings|Login|blocked email domains. This prevents emails from unwanted domains from creating staged users in your forum and littering them with SPAM topics.

  Notice that regexp expressions work in this, EXCEPT for the dot (.). You do NOT need to escape the dot because it will be automatically escaped. In other words, \d+\d\d\d.\w+ will actually be \d+\d\d\d\.\w+$ and will match any domain that is a string of digits more than 3 long plus a root domain (.com, .org etc.).

• Set up suspected SPAM email subjects in Settings|Email|ignore by title. This prevents emails with suspicious subjects from creating topics.

  Notice that regexp expressions work in this. Wrap your entries with \b if you want to match whole words in English. BEWARE, \b works for English language only!!!

Attachments

• Add allowed attachment formats in Settings|Files|authorized extensions because customers who requires support will typically send in attachments other than photos (maybe a PDF file, an Excel spreadsheet, a CAD drawing, an error log file, or a zip file).

• Set Settings|Files|max attachment size kb large enough so that reasonable attachments do not bounce. Typically 1MB to 2MB is enough.

Set Up Email Info in Categories

• For each category that will receive emails from outside, set Custom incoming email address (in the Settings of the Edit dialog of that particular category) to the appropriate email account.

  For example, in the Wonderful Product category, press Edit and go to the Settings tab. Custom incoming email address should be set to wonderful_product@support.example.com. Then, all emails sent to wonderful_product@support.example.com will be created as topics in this category.

• Turn on the Accept emails from anonymous users with no accounts setting for each category that will receive emails.

Set Up Security in Categories

• Remove the Everyone group from each category’s access list.
• Use Groups to manage access to each category.

If You Have a Multi-Lingual (Worldwide ) Customer Base

• Turn on Settings|Basic Setup|allow user locale

• Turn on Settings|Basic Setup|set locale from accept language header

  Notice that it doesn’t work for redemption from invitations as of 1.9.0beta13.

• Consider the discourse-translator plugin

• If you have Chinese users, please make sure to search meta for the settings required to support Chinese language posts.

[Walker_Blackwell]

@schungx

Turn on the Accept emails from anonymous users with no accounts setting for each category that will receive emails.

I think I’ve found a minor bug with this and am interested in other’s opinions. I’ve set up everything just about exactly like these instructions however I have a email-receiver docker running to receive emails directly at my hosted discourse forum and send to the forum via API. This is better than POP3. Email server forwards emails from help@test.com to help@myforum.test.com which is set up as the category incoming email. All good and fine. When I send an email to help@test.com with a nonregistered email accout it creates a new ticket/topic in the thread and I can handle that.

The problem comes after I’ve invited the user to become a member of the forum. When they are anything OTHER than anonymous or staged they suddenly can’t sent a support request email to help@test.com. The email gets rejected because the category is restricted to admins only for see/replying/posting AND to anon/staged (0-level) users for posting.

There is no way to allow for a level 1,2,3 user to POST/EMAIL to the category without actually seeing the category and all the other topics available correct? At least I don’t see how to fix this.

tldr: the second a user is no longer level-0 (when email-receiver is the way incoming email is handled) they can’t email to create a new support ticket.

It’s almost like this needs to be toggles so Create/Reply can be set but not See.

How to fix?

[Dannii]

I just had this same problem. The conclusion is that you should only use a category if the forum is closed to general registrations and the only users will be staff. Otherwise you should instead have a group set to receive emails. That is detailed here. I’ll edit this howto to warn against what we’ve both tried.

[Stephen]

I don’t think your edit makes much sense. The title is ‘How to use Discourse as a Private Support/Ticket System’ while you’re both trying to use Discourse as a community and a ticketing system. That’s not the same thing by any stretch of the imagination.

[Dannii]

What exactly is wrong with the edit? I’m clarifying that you shouldn’t use a category to receive emails unless the whole forum is private. Handling the contact email address within a community forum must be a common desire, but it won’t work with category email in. I misunderstood the implications of this howto, and so edited it to help others like me and Walker avoid making the same problem in the future.

[codinghorror (Jeff Atwood)]

@Dannii

you shouldn’t use a category to receive emails unless the whole forum is private

I think that’s a fine clarification.

[schungx (Stephen Chung)]

I would think it is very strange for your setting.

Now, why would you:

1. Just anybody ==> email in and start a topic
2. Registered user ==> email in and start a topic
3. Registered user ==> start topic in browser NOT ALLOWED

To me it makes no reasonable sense. You’re allowing anybody on the street to start a topic in that category. Why would you ever want to prevent your registered users to do the same (which is to start a topic)?

The method that they start a topic (via browser vs. via email) should not affect their ability to start a topic.

The behavior in Discourse is absolutely logical and it should be this way. Staged users (i.e. from emails) are created by the system and they cannot login; and since they are created automatically, you don’t really give them specific permissions.

Note: I’m not considering the fact that you can make normal users all trust_level_1 and staged users trust_level_0 then disallow topic creation for trust_level_0. I have not tried it to see what happens…

Now, registered users fall under normal permissions control, and if you disallow a user from starting topics in a category, the system should disallow him/her from starting a topic REGARDLESS of the method (i.e. email or via browser).

[schungx (Stephen Chung)]

However, I do second (strongly) your suggestion to create Create/Reply as a separate permissions tier.

There was a lengthy discussion on this a long time ago:

Create/See and Create Permissions (again)

Continuing the discussion from "Create" Permission: Now that the “whisper” functionality (https://i.imgur.com/orfu6df.png) has been added to Discourse, I feel like this topic should have new life breathed into it again. This proposal is for two new permission sets: Create, and Create/See. Both of these could be used in “fringe” forums where confidentiality or experience is required. These won’t be used on all the Discourse forums in existence, but the ones that could/want to use something li…

As I mentioned in that discussion, Create/Reply will be ideal for a secured support-ticket system where you don’t want everybody to be able to see other people’s tickets.

[Walker_Blackwell]

My original question above was a bit naive as I had not properly understood group message dynamics. The group incoming email/post system works perfectly and essentially is exactly what I/we need simply in a Group instead of Category (there isn’t much difference there really).

New on-boarded support staff with access to the support group(s) have access to the historical ticket archive by simply going to /g/[thegroupname]/messages/inbox which is essentially a category topics list.

As a side note for those interested I set the pre-foward incoming email system (help@test.com) to auto-reply a canned “thank you for your question” type email. Then the email is sent to the email-receiver to create the post. This keeps the customers calm and not posting a second time and gives me a bit of time to work the ticket response.

best,
Walker

[tknospdr (David Muszynski)]

Gibt es einen ebenso gut geschriebenen Artikel für diejenigen, die ihr Discourse sowohl als Standard-Online-Community ALS AUCH als Ticketsystem nutzen möchten?
Einen, bei dem es absolut Überschneidungen zwischen Nutzern von Hilfe-Tickets und Nutzern von Community-Foren geben wird?
Ist das überhaupt möglich, ohne einen Schubkarren voller Vorbehalte?

[merefield (Robert)]

Als Option für diesen Anwendungsfall (und viele weitere) habe ich das folgende Plugin geschrieben:

Discourse Workflow

Summary A workflow system for Topics that implements a configurable multi-stage process Repository Link https://github.com/merefield/discourse-workflow Install Guide How to install plugins in Discourse Enjoying this plugin? Please it on GitHub ! [A person in a business suit is writing on a piece of paper with a pen at a table, pointing at a graph. (Captioned by AI)] [The image depicts a purchasing workflow t…

Das Sie in einer Kategorie (und deren Unterkategorien) einrichten und so berechtigen können, dass es nicht im Hauptbereich der Community sichtbar ist.

[tknospdr (David Muszynski)]

Ich schätze die Informationen. Kennen Sie einen Artikel mit dem Titel „Anleitung“, der diesen Artikel mit Ihrem Plugin zusammenführt, damit Neulinge wie ich ihn zum Laufen bringen können?

[nathank (Nathan Kershaw)]

Die andere Option ist dieses gut etablierte Plugin von den Machern von Communiteq:

Private Topics Plugin

Summary Private Topics Enables private topics in a regular category Repository Link GitHub - communiteq/discourse-private-topics Install Guide How to install plugins in Discourse Features This plugin allows you to add an extra security setting to categories so that users can only access their own topics. You can also designate one or more groups that can see all topics in the category. This is typically used for providin…

Dies löst das oben beschriebene Problem gut.

[tknospdr (David Muszynski)]

Ich verstehe, und das wird in Verbindung mit den gestaffelten Benutzern funktionieren, die hauptsächlich „Tickets“ im System erstellen werden, wie im Hauptteil dieses Beitrags beschrieben?

[mcwumbly (Dave McClure)]

Ich werde auch mitteilen, dass wir unsere Meta-Community hier auf diese Weise bei Discourse nutzen.

Wenn Kunden uns eine E-Mail senden, wird diese, anstatt in eine Kategorie zu gehen, wie hier beschrieben^[1], als private Nachricht in einer Gruppen-Inbox erstellt, die wir als unser Ticketsystem verwenden. Wir haben im Laufe der Zeit einige leichte Verzierungen zur Inbox-Ansicht hinzugefügt, um dabei zu helfen, aber hauptsächlich nutzen wir integrierte Funktionen.

Die wesentlichen Bestandteile unseres Workflows sind 1) die Verwendung einer Gruppen-Inbox, in der jeder im Support-Team antworten kann, und 2) das Archivieren von privaten Nachrichten, wenn wir auf die letzte Antwort reagiert haben.

Wenn ein Kunde antwortet, wird die archivierte private Nachricht automatisch wieder in die Inbox geholt, sodass das gesamte Team sie wieder sieht.

Das Team kann auch auf diesen privaten Nachrichten flüstern, um miteinander zu kommunizieren, und wir haben kürzlich auch begonnen, mit KI-Flüstern zu experimentieren, bei denen einige erste Recherchen dem Team vorab mitgeteilt werden.

---

1. Wir nutzen in bestimmten Fällen auch private Kategorien, aber das ist mittlerweile eher die Ausnahme als die Regel – der Gruppen-Inbox-Workflow ist das, was für uns zur Norm geworden ist. ↩︎

[tknospdr (David Muszynski)]

@schungx

LEITEN Sie alle E-Mails an diese spezifischen Konten an das MASTER-E-Mail-Konto weiter. Erstellen Sie beispielsweise eine automatische Weiterleitung, um alle E-Mails, die von wonderful_product@support.example.com empfangen werden, an master@support.example.com weiterzuleiten.

Für diejenigen unter uns, die pro E-Mail-Konto bezahlen müssen: Können Sie ein einziges Master-Support-Konto erstellen und einfach Aliase für die einzelnen Adressen auf diesem Konto erstellen?

Derzeit hat mein Hauptkonto, glaube ich, 12 Aliase, einige davon sind sogar unterschiedliche Domainnamen. E-Mails, die an eine dieser Adressen gesendet werden, gehen an mein tatsächliches Konto.

Würde das für diesen Zweck funktionieren?

[tknospdr (David Muszynski)]

[quote=“Walker_Blackwell, post:2, topic:72268”]Das Problem tritt auf, nachdem ich den Benutzer eingeladen habe, Mitglied des Forums zu werden. Wenn sie etwas ANDERES als anonym oder staged sind, können sie plötzlich keine Supportanfrage-E-Mail mehr an help@test.com senden. Die E-Mail wird abgelehnt, da die Kategorie für Administratoren zum Anzeigen/Antworten/Posten UND für anonyme/gestellte (Level 0) Benutzer zum Posten eingeschränkt ist.

Es gibt keine Möglichkeit, einem Benutzer der Stufe 1, 2, 3 zu erlauben, per POST/E-Mail an die Kategorie zu senden, ohne die Kategorie und alle anderen verfügbaren Themen tatsächlich zu sehen, richtig? Zumindest sehe ich nicht, wie ich das beheben kann.

[/quote]

Ich weiß, dass dies eine sehr alte Frage ist, aber ich habe niemanden gefunden, der sie beantwortet hat, und ich glaube, ich habe die Lösung. Zumindest funktioniert es für mich. Ich weiß nicht, ob es unbeabsichtigte Folgen hat, da ich gerade erst anfange, aber hier ist sie.

Ich mochte die Idee von Kategorien gegenüber Gruppen, also folgte ich dieser Einrichtungsanleitung, wollte aber auch ein offenes Forum haben und stieß auf das gleiche Problem wie oben beschrieben.

Wenn Sie im Adminbereich nach E-Mail-Einstellungen suchen, finden Sie die unten stehende Seite. Sie zeigt eine Vertrauensstufe von 2 an, die Benutzer benötigen, um E-Mail-Beiträge zu erstellen.

Gestellte Benutzer umgehen diese Anforderung, aber sobald sie Vollbenutzer werden, sind sie immer noch Vertrauensstufe 0 und E-Mail funktioniert nicht. Entfernen Sie also einfach TL2 und fügen Sie TL0 hinzu, und Sie sind bereit.

Ich habe dies zusammen mit der Verwendung des oben genannten Private Topics Plugin getan, damit Benutzer auch direkt auf der Website Support anfordern können, und ich bin fast fertig.

Ich muss nur noch Prioritäts- und Status-Tags sauber integrieren, und ich denke, wir sind bereit.

[RGJ (Richard - Communiteq)]

[quote=“Walker_Blackwell, post:2, topic:72268”]Das Problem tritt auf, nachdem ich den Benutzer eingeladen habe, Mitglied des Forums zu werden. Wenn sie etwas ANDERES als anonym oder inszeniert sind, können sie plötzlich keine Supportanfrage-E-Mail mehr senden […] Die E-Mail wird abgelehnt, weil die Kategorie nur für Administratoren zum Anzeigen/Antworten/Posten UND für anonyme/inszenierte […] Benutzer zum Posten eingeschränkt ist.
[/quote]

[quote=“tknospdr, post:17, topic:72268”]Das habe ich zusammen mit der Verwendung des oben verlinkten Private Topics Plugins gemacht.
[/quote]

Ja, genau dafür wurde dieses Plugin gemacht!

[nathank (Nathan Kershaw)]

Das Private Topics Plugin ist brillant dafür, hat aber eine wichtige Schwäche: Es kann nur einem Benutzer pro Thema zugelassen werden. Das bedeutet, dass Sie keine anderen Benutzer zum Thema hinzufügen können, ohne ihnen alle Themen in dieser Kategorie preiszugeben.

Die Umgehung besteht darin, dieses Thema in eine PM umzuwandeln oder es, falls zutreffend, an einen offeneren Ort zu verschieben. Aber es wäre schön, andere Benutzer (und/oder Gruppen) angeben zu können, um auf dieses spezielle Thema zugreifen zu können. Ich denke, das würde eine ziemlich komplexe Lösung erfordern.

@mcwumbly

Die wesentlichen Teile unseres Workflows sind 1) die Verwendung eines Gruppenposteingangs, in den jeder im Support-Team antworten kann, und 2) das Archivieren von PMs, wenn wir auf die letzte Antwort reagiert haben.

Die Verwendung des PM-Systems für diesen Anwendungsfall ist ziemlich leistungsfähig und flexibel (und ermöglicht das Einbeziehen anderer Benutzer); es hat jedoch auch eine wichtige Schwäche: Es ist vom Forum selbst getrennt. Dies ist ein viel größeres Problem auf kleineren Websites ohne engagierte Mitarbeiter, die den Support-Workflow abwickeln, da es dazu neigt, entweder übermäßig zu benachrichtigen oder unterzugehen.

[RGJ (Richard - Communiteq)]

@nathank

Die Verwendung des PM-Systems für diesen Anwendungsfall ist sehr leistungsfähig und flexibel (und ermöglicht das Einbeziehen anderer Benutzer); es hat jedoch auch eine wichtige Schwäche: Es ist vom Forum selbst getrennt.

Ja, das ist in der Tat mein Hauptproblem. Das Private Topics Plugin ist alles andere als ideal und persönliche Nachrichten bieten mehr Flexibilität in Bezug auf die Möglichkeit, andere Benutzer zur Diskussion einzuladen.

Aber nach all den Jahren bestehen die seit langem bestehenden Probleme mit persönlichen Nachrichten immer noch:

• Es gibt keinen globalen Tag-Filter. Der Tag-Filter in der Seitenleiste zeigt nur Nicht-PM-Themen an. Sie könnten einen weiteren Link erstellen, aber er wird immer pro Posteingang sein.
• Das Taggen persönlicher Nachrichten funktioniert nicht intuitiv und ist aufgrund inkonsistenter Implementierung eingeschränkt.
• Die Benutzererfahrung verwirrt mich weiterhin
  • Ich verstehe nicht, wann eine Nachricht im Postausgang und wann sie im Posteingang ist.
  • Die Formulierung ist unklar.
  • Ich finde das Einrichten von Gruppenposteingängen immer noch schwierig (z. B. Group inboxes not appearing).
• Die Suche ist umständlich
  • Search for messages that involve (both from and to) a user
  • Sie müssen den Suchfilter explizit hinzufügen, außer wenn Sie sich in Nachrichten befinden, daher fühlt es sich wirklich isoliert an.