Using discourse as a community ticket system

We are doing something similar to this at the National Library of Finland in the development of the Finna service. We do have a separate ticket system as well, but Discourse is useful as a way for our client organizations to discuss what they want. Because we are developing a single (although customizable) service for many different organizations, there needs to be a way for the organizations to talk to each other as well as to us. An ordinary ticket system is not adequate, because often the needs of our clients are not easily translated into tickets. There needs to be room for freely flowing conversation as well.

Unfortunately our Discourse forum is not accessible to the public but after a few months of experience it seems to be working well for our purposes.


Hahaha, that’s quite ironic!

First I got some healthy criticism about it, when I was supporting the idea.

Now, just yesterday, I talked to my client and figured it wouldn’t be appropriate for our usage for 3 basic reasons… The irony is that now people came forward supporting the idea and now I’m not so much into it. At least without the plugins and improvements needed:

  1. As it turns out, we actually do have sensitive data and there must at least be a way for private tickets (it just happened to me: making invisible posts aligned with private messages might still do the trick, hmmm - ideally we should be able to private message more than 1 person, through groups).
  2. Client contact information. We need a form with some data from clients. This is quite crucial for our ticketing, and it’s certainly something plugin-able.
  3. Client history. Although possible to track somehow, it needs to be simpler, faster and easier; simply because there are ticket systems that do it already.

In any case, I’m so glad to see people have already applied this idea somehow! :slight_smile:

Do you guys already use a ticketing system?

You may want to check out the [Zendesk plugin] (Create Zendesk Tickets from Discourse posts) as well.


Nope, we are going after one now.

It should focus on Service Orders and preferably be opensource done in rails. osticket in rails would be perfect! I’ve heard much of zendesk of course, but haven’t tried it (nor knew it was rails). Their very cheap plan is quite attractive (and I never meant “free” opensource).

We should probably give zendesk a shot!

We are looking at similar problem. We already use Discourse for our forums, but we shall be soon releasing an alpha version of our product and we would like our customers to be able to use some public bugtracker to track issues they encounter (we are talking 1,000+ users, all of them already have login in Discourse). The way I see it, we would need to be able to attach some meta information to a topic (severity, version, etc.). Is this something that can be done or is planned?

On slightly related topic, what is your – Discourse developers’ – experience here on Discourse Meta with the bug category? Does it work well for you? Do you have some other bug tracking system?

Thank you for any information.


Since nobody replied, I’ll give some input:

I don’t think any of the staff is planning to add meta information to topics nor improve upon the ticketing concept. But I do think the bug category is not just a little side from github. Sam said he wants to use Discourse as a bug tracker. But that was almost 2 years ago. So, even if they do want something, they probably won’t ever have time to focus on it and are hoping someone will step forward. Looks like nobody did, so far.

Also, in case there’s anyone else taking notes and are too ashamed to manifest themselves, I just noticed one more thing I’d need on my list there, which would be awesome:

4. Anonymous email support. Someone email in, it creates a new topic. That’s done already. But then it also associates that topic to that email. So when I reply to the topic (or edit my replies), whoever created the topic will receive a notification to which they can answer. They only need to create an account if they want to participate on the website.

So, for now zendesk it is.


Writing a “Uservoice” plugin is something that pops up a bit, problem is it would take a fair amount of time to build so it would have to be funded by a paying customer. It is not slotted into any of our future releases yet.


It should be called “email mode” instead of “anonymous”. I was reading another topic and this has nothing to do with anonymity.

I don’t think it needs to be a plugin or have connection with other ticket systems. I think this could be something completely different as a concept, and it really needs “little” implementation to be a reality.

We’ve gotten closer now:

You can now do this by adding a tag.

Can also be covered by tags.

The Solved plugin. is great for this. Ideally it will also allow marking as solved without specifying a specific answer.

Don’t think we’ll ever have that natively, but how many ticketing systems (or companies) actually use this feature? I’ve worked professionally with two different ticketing systems (HelpScout and UserVoice) and time tracking was never a concern. It’s also something that’s easily left up to a separate program.

Some important “others”: Excellent search and automatic related-post suggestions to facilitate independent problem solving and fewer duplicate requests.

Also, and most importantly in my humble opinion, a ticketing system is the closest thing to a community for many companies. Starting off with Discourse as a ticketing system would be a great way to set yourself up for a more expansive community story as your company evolves.


But unfortunately You still can’t filter two tags ?To get person / priority combination

1 Like

I’ve being using it as a ticket system already (no community helping though, it’s just me), and I don’t think we’re getting any closer.

Assigning to person could already easily be done with @mentioning. Severity, priority or status could be done with categories, probably sub ones. I think having more than 1 kind of status only make things unnecessarily more confusing anyway.

And I agree tracking time is not productive or that useful.

I think the main issue still lies on handling emails and logins. People still are kind of required to login before starting a ticket, but most people will only bother to send emails. It’s a huge friction in the beginning there.


A workaround (that isn’t yet possible) could be:

  • In addition to allowing anonymous emails to create topics, subscribe that email address to “Watching” notifications for that topic.
1 Like

Oh yeah! That’s a good simplified statement of what I’ve already said! But it makes the task of implementing it not at all easier as there are still so many steps needed to make it work. :smiley:

You do introduce the idea of making it anonymous to begin with, which is a very nice addition. Currently we can create topic with email-in, but they’re not anonymous.

In either case, the created topic need to be done by the email-profile and not by the system like it is today.

Thinking a little bit more about it…

Maybe instead of making an email-profile, it would create an instant anonymous profile based on the email, which could then be used to claim the profile and opt-in to remove anonymous! :slight_smile:

+1 on this one - I do this all the time and it works.

I also use the title to indicate it’s a task and status e.g.

Task: This is the task (new)

I love this example :slight_smile: Could you tell us more about your workflow and organization? Do you use any additional ticket system to track who’s getting stuff done? I just thought we could replace basecamp with discourse for our project discussions.

Our workflows are not very rigid. In addition to Discourse, we have a system for service requests that arrive via email, and another system for tasks ready for implementation. Both of these are implemented with Jira. We have been encouraging our customers to use the Discourse forum, and it works quite well.

Quite often we still need to create tickets about questions that our customers post on the forum (we link to the Jira task from the forum and vice versa), but on the other hand we have had many good conversations that would not have been possible with a regular ticket system. Sometimes our customers have already figured out a workaround when they first post about a problem, and this is very helpful to us.


Yes, the best ticketing systems allow for the agent to add time on each ticket update, and will automatically tally it for you as the life of the ticket progresses.

Web HelpDesk, Autotask, ConnectWise, all do this, and there are extensions for Freskdesk & Zendesk to do this as well. If I were specing a ticketing system, I’d certainly have this on my list.

Benefits include knowing who’s taking up the most time, how long agents have had to spend on people from a certain organization, and in the cases where support is billed by the hour, it’s the best way to track how long the agent has actually spent, since he or she can add time to the ticket every time they add in notes on the matter.


It really depends on what your needs are though. A lot of these features may not really be required for many organizations, particularly those with small teams or small numbers of tickets.

In fact, I found that many of them get in the way when I was at my previous company.

We had a small team (4-6 people, which included developers, a product manager and a community / marketing person). We supported hundreds of users not thousands.

We knew them by their first names. Many of them had worked with us for years and had our email addresses and phone numbers. They were used to emailing or calling us either through our prior official channels (support@ and a support phone #), or their personal contacts directly.

We certainly worked hard to wean people off of contacting individuals directly, as that caused certain people (like myself) to carry a much larger share of the burden than necessary.

But when we tried systems like Zendesk, it created a fair bit of overhead all around. We didn’t need to track time. Our users couldn’t contact us as easily. Responses felt much less personal coming through that interface.

We did find that Discourse fit in very well though. We were quickly able to demonstrate the benefits to our users of having a community there to help respond and build a knowledge base. Not only of answers to questions they had, but answers to questions they didn’t know they had. And our team participation was much higher than when we tried to use Zendesk as well, so not only was the work divided more naturally, but there was greater visibility into the fact that there was more than one helpful person out there.

The email features in Discourse helped smooth the way for our users who were used to just using email to contact us.

That said, our business still required answering certain requests privately. More urgent issues sometimes required screen-sharing and phone calls or text messages as well. For these we used our official support email address and phone number, which would be re-directed to whomever was on call.

But again, Discourse helped to put a human face on those interactions because users became more familiar with the team supporting them.

For our situation, the features of a ticketing system I still felt we were missing sometimes were:

  • ability to track status (really just to know which issues were still open)
  • ability to know who is assigned

The way we addressed #1 was to not let many issues stay open. The way we addressed #2 was also largely addressed by our solution to #1, and additionally to rotate who was on call.

All that said, I think it would make a lot of sense to add features or plugins to discourse to enable features that would better facilitate handling and tracking private support requests through the system. Time tracking and severity/priority classification would be very low on my list.

This would be my wish list:

  • intuitive way for user to open a private support request
  • a shared queue of support requests (private messages to a support group)
    • ability to track status (really just to know which issues were still open)
    • ability to know who is assigned
  • a notion of a primary group that a user belongs to, with the ability for them to make their private support requests also visible to members of that group by default

(Almost) completely agreed with you there, @mcwumbly ! Except…

My wish list still have that one item above anything else. It’s basically about facilitating communication through email only, without requiring to create an account for that. The whole email-profile thing (am I hammering on this too much?).

Private communication would definitely come next.

As for tracking status, again, it could be done using categories. And assigning can be done with @mentioning. Why would you need any more functionality for those?

Without having any experience with large scale, or even smaller ones, I’d say it should be low on any list.

Time tracking doesn’t work for the same reason time republik won’t ever work: you’re using the wrong metrics. Time is money so do use money instead. Just measure productivity. If it can’t be done through dollar signs, trying to hack it through counting time won’t be any better. There are so many variables not accounted in when you measure just time which are already built in when you simply check the results. Including luck.

Severity and priority are just counter productive and way too subjective. But even applying money here wouldn’t be a good idea. There’s already a metric for it: who came first. Always attack the oldest items first. If there really are life threatening cases, create a category for it. There could be 3: open, finished and urgent. In the later only mods can create topics. There’s no need for more than this.

1 Like

I’ve never seen a ticketing system with a time tracker that I like. I’d like such a thing to be more like a time sheet system with close links into the ticketing system. I’d want any given ticket to be tied to some sort of tracking/billing entity that might include multiple tickets, might be associated with a particular client and /or project, and would allow for pre-allocation of total time to be worked, as well as due date, to keep track of what’s going off the rails. There’s a bunch of report and alert types needed to make all this useful.

More generally, there’s any number of ticket systems that can give you a place to keep notes on a given ticket. What distinguishes a good system is the tools you have to keep track of what work needs doing. E.g. being able to look over what tickets assigned to me (or that are assigned to any of hte members of a team) haven’t been touched in a while (with the meaning of that based on urgency), or have had a client submission to the ticket that hasn’t had a response.

Systems that make it easy to see the big picture around a ticket are important. If a given client has been submitting a ticket about the same problem every week, and we only deal with them individually without seeing the bigger picture, then that client is getting pissed off at us not dealing with the underlying issue, and we can’t see it. StackExchange’s related questions system comes to mind here.