Using discourse as a community ticket system

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