Using discourse as a community ticket system

Feature
1

I understand we should probably not use discourse for this, but what if I want a new kind of “community open” ticket system? Can you picture any deal breaker issues with this?

Also, is there maybe someone else who tried to do anything similar?

Without any extensibility, this is how I envision it might work right away, for our little business:

  • We’d slowly and even personally warn users of how it works. They’re already used with our different thinking methodology anyway.
  • Anyone would be able to comment on other people’s tickets.
  • You’re responsible for tracking (getting updates on) your own ticket if you want.
  • Staff would need to manually give the topic link for each new ticket associated with the corresponding customer, at least for new users.

Maybe a few issues, but not so terrible given the concept:

  • You can’t have an automated list of your own tickets in the site (as already implied, unless you bookmark / star them yourself).
  • No user sensitive information must be shared on the site (not like facebook is all that much safer, if you know what I mean).

I would guess it shouldn’t be too hard to extend it to make it more private and thus “covering” those issues:

  • Make new topics invisible per default in a specific category.
  • Let users list invisible topics to which they’re assigned or simply “have read”.
  • Pre-assign emails to topics, so new users can have their own invisible topics list.

It wouldn’t be a “community ticket system” any longer, but it’d still be a great tool IMHO.

Instead, I’m really into the whole idea of opening the tickets and see what happens!

Man am I excited about this? :stuck_out_tongue:

There must be a huge problem I’m over seeing here…

6 Likes
2

The concept of a “community ticket system” isn’t bad, but I don’t see why you’d use Discourse for this. It lack a lot of stuff that a ticket system really needs.

If you could use Discourse for only the commenting part of the system, it would make sense. But as the entire system, you’ll end up with something that isn’t manageable and gives you a false sense of control.

3 Likes
3

I thought almost all ticket systems allow collaboration on tickets?

2 Likes
4

First and foremost, because I never really used any ticket system (as an admin), and I’m not so sure what kind of stuff it is lacking. I’d love to see a list, reasons and examples. :blush:

Also because it’s open source and, if I feel the lack of anything, in theory, I can fork it and implement it.

Using it only for the commenting part makes the most sense, indeed. Maybe that’s the best “answer” to my “question”. :slight_smile:

Hmmm… Now that you brought this, maybe you’re right. GitHub and Google Code do have collaborative tickets. I wasn’t thinking about those up to this very point (even at my answer to @boomzilla). I was thinking enterprise and private tickets. So much, in fact, I can’t even remember if I had any specific examples in mind. GetSatisfaction do come to mind, but I’m not sure it would work as a ticket system…

Looking at google, first thing I found was osTicket, and I got to this online demo. There you can see almost what I thought of a ticket system. And it’s closed, non-collaborative at all. For that, it looks like a great system, though. Maybe much better than my “extended discourse” version, with invisible topics. But maybe not. Again, I wouldn’t know, I’d have to try in practice at least once.

One thing I didn’t make clear, to my usage case here, is that I’m looking for a Service Order system more than Ticketing. For whatever reason, I thought it’d be easier to explain it as Ticketing though, as that sounded good enough for me. Now I just found another FOSS solution out there which describes exactly my needs here, but… Once again, really not community collaborative.

Now I’m trying to think how I could merge it with discourse as boom suggested… :sunny:

5

Tickets usually have confidential information attached to them, at least in my company. It does sound interesting since Discourse has email service done to perfection. Some one-on-one action only between moderators/staff and users/clients.

1 Like
6

Here are a few things that Discourse can’t do:

  • Assign a ticket to a person
  • Assign a severity / priority
  • Track the status (only very coarse grained tracking in Discourse - open and closed)
  • Track time spent working on a ticket
2 Likes
7

I think I’ve covered most of those in my first post, including @Webinsane’s comment on confidentiality (I’ve called it “sensitive information”, with no clue which one would be a better name).

  • Assigning to a person is not needed, in this idea. Just mention that person and email them the link. That’s their “assigned” community ticket.
  • Severity or priority, I think, is also not important. It’s not like we’re throwing emails away and centralizing anything. Although the point is we don’t currently have a ticketing system, so “anything” might be better than nothing. I’m actually hoping this turns out to be better than regular ticket systems… After all, all support requests are urgent, aren’t they? :stuck_out_tongue:
  • For status, almost same issue as priority. It’s yet another field to keep track of, and I’m not sure it’s all that relevant.

Now, tracking time spent working on a ticket, I’d say that’s something I haven’t thought. Hmm… I’m currently going through a lot of thoughts about the financial system as a whole, and how bitcoins will change it a lot soon enough… Maybe tracking time will soon become moot point. But that’s really something to think about! :open_mouth:

8

If you please allow me to engage in debate

Because in our company we use Discourse for many kind of things. There I have already users which communicate for other needs.It is hard to push and learn my users to use different systems for separate business process. When they are at discource they already have group bio contact info and other stuff which help to registered user and see their need. Support (ticketing) is in my case side part of business and by using discource I am trying to ingratiate it in one bigger system where my users is resident

I hope so that these things will be covered once when Tagger plugin be in production version.
These two would be easily covered by adding tags to topics. Every person woud have own tag.
When proxy users get read ticket it simply edit tags on topic to mark topics for persons and prority.

Tracking time I just hope so that discource will soon have plugin that will track time per posts. There is an idea to discource be used as BUG tracker and other things. So sooner or later someone will make plugin that will track time.
I did asked for time tracking already.
https://meta.discourse.org/t/how-to-measure-efficiency-of-workers-in-conjunction-with-discourse-posts/20571

Once again why I thing that Discource cloud be ticketing system:
Becouse We use it allready for:
Communicating to each other
Wiki posts (knowledge base)
Mail Lists
Work Sharing
Announcements
Social integrating
Calendar integrating
and many others

1 Like
9

FYI … I added an op_likes ordering today (ordered by likes on first post) … and added a bugs and features top level nav items on meta today.

Makes finding important bugs a tad easier.

3 Likes
10

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.

3 Likes
11

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:

12

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.

2 Likes
13

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!

14

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.

2 Likes
15

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.

2 Likes
16

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.

3 Likes
17

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.

18

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.

6 Likes
19

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

1 Like
20

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.

2 Likes