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. 
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! 
+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)
2 Likes
I love this example 
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.
5 Likes
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.
2 Likes
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
3 Likes
(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.
2 Likes
I disagree on this specific point. Yes, subjectivity is an issue, and the person submitting the ticket generally has an incentive to overstate priority. More generally though, inventing such practices from scratch without experience is probably not the best approach. People do degree courses in computer support these days, getting a hefty dose of ITIL best practices stuff. Which is to say that a lot has been learned and written about already.
Going straight to the ITIL docs would be very much overkill for where you are at, but I would strongly recommend that you look for existing guidelines at a level of complexity and formality that’s suited to your needs. Also consider that if you grab an existing system that’sdesigned around the needs of a service desk, then the initial default settings will likely get you started towards good practices in a way that you won’t get from trying to extend a more general purpose system like discourse into doing ticket management.
For your needs Cawas, something like Redmine (self hosted) or JIRA (hosted) might be an easy option for you to get started with, and then review your needs once you’re a little more familiar with the ground, and in particular once you have enough tickets that you start to understand what reporting you need to keep everything on track. It may be that you could get what you need out of discourse, but I would not recommend that you design such a system without experience when there are such easy off the shelf tools available that will help you learn what you need faster.
In terms of the discourse project, I think not having a proper ticketing system is a significant shortcoming, which will hinder the operations of the discourse team and of anyone external to that who wants to get involved. Currently this is being done within meta.discourse.org, but without good tools. I think there needs to be a decision to actually develop good support for use as a ticketing system, as this topic suggests, or a separate ticketing system wants to be put in place, perhaps with some integration with meta.discourse.org.
1 Like
Yes we have been totally hindered as you can plainly see progress has been at a complete standstill on the Discourse project since February 5, 2013. 
Using discourse only for the commenting aspect seems overkill to me
@def where that came from? Oh I see, you didn’t really read through… Comment in that context was about this:
Next…
I agree with that, but usually there will also come a lot of useless legacy caveats. As google inbox have shown me, priority might be one of those. Even tagging, but that’s a different topic.
Anyway, I’m just bringing in a mostly unfunded theory there. I kinda already expected most people to disagree with it. 
I’m not disagreeing with you. I should have quoted you properly. What I am saying is that any use of Discourse as a subset behaviour seems to me overkill as Discourse is really quite a substantial application. Funnily enough I had been wondering if something like Discourse is capable of being moulded into a support system and don’t think your question is at all a misplaced curiosity.
1 Like
My bad @def , I should have given it more thought. I also read you and your message wrong. You did say “commenting aspect” and I thought “system”.
Truth is, 1 year later, I’ve already lost track of what was being talked here, plus the little business I was talking about earlier on doesn’t exist any more and I’m lazy to read everything again now! 
All in all, I would argue my hands on experience with it, as small as it was, was generally good enough. Despite not having done any modification, I could use it to communicate with clients with (almost) no technical issues (there were some related with things I asked here) and I believe it even was beneficial in many tiny ways.
Actually, there were some issues with using a public place to talk about supporting through email, which some people expected to be private. And not everyone could adapt to using it.
1 Like
sam
How is the. op_like feature used?
1 Like
Important to mention we recently built discourse assign for this task.
8 Likes
can you share example of how you use Discourse for Calendar integrating and Wiki posts (knowledge base) and Communicating to each other ?
For Wiki posts,
We use separate Categories / Sub Categories where we posts only Wiki topics.
Also these posts are Wiki by default so any user can change, reedit wiki post and build up knowledge base.
For Calendar Intgration,
We use embedded google calendars, but we also use separate Categories / Subcategories where we post about things taht is common whit dates.
E.g. We have Category TRIPS on our discourse where trips being announcement
1 Like
We use Discourse for a customer support ticket system.
Each customer has a To Do Category and a Done category.
The workflow is handled by tags.
It works well enough for our purposes.
3 Likes