Who else is running a primarily support oriented forum?


(John ) #1

There is a very unique set of goals, challenges and opportunities when using Discourse to provide customer and developer support. Who else is doing this?

Here’s a bit about our situation:

We’re a hosted discourse customer using https://community.coinbase.com/

I see it as serving two major user types, with further distinction within them.

  1. Customers: They come to us with questions about Bitcoin, bank transfers, etc. Their often not looking for a community of peers to discuss something of interest to them, they’re just looking for help. Our business is heavily regulated, which sometimes results in angry or confused customers.

  2. Developers: We have a bunch of APIs, and we help devs use them on our forum. This is the fun part, and the group that presents and opportunity to build community within. The developers category has a lot of sub category, and I hope that it feels like a separate forum to those visitors.

Beyond that I won’t talk too much about the specific challenges I’m trying to solve, but I’d love to hear from others with a similar use case, and hopefully we can help one another out.


(Scott Trager) #2

Our (very different) company uses it for user-to-user support. When customers have a question that only we can answer we usually push them to contact us via traditional support methods. In your case I’d focus your forums around developers and maybe have a “General bitcoin discussion” board or something where less technical discussions can be had. Because of the sensitive nature of financial transactions, you don’t want to risk a stupid confused customer accidentally posting their banking information on your board.


(Allen - Watchman Monitoring) #3

We use our closed discourse for customer support & discussion.

Rubymotion runs this discourse much like you do: http://community.rubymotion.com

A number of people in this thread are taking support to the next level, and it’s exciting!

Discourse as a private email support portal


(Joshua Rosenfeld) #4

The discourse I help moderate (discourse.stonehearth.net) is heavily support oriented, but I am not sure if I would describe it as primarily support oriented.

The forum is for a game in active development, so a large bulk of discussion on the forum is in regards to bug reporting, but there is also discussion regarding the game’s development (as a whole), modding, suggestions, and other discussion.


(Thomas Huulbæk Titanium) #5

Ours - http://forum.spywarefri.dk - is almost only for support. It’s coming from two conversions since 2004 and Discourse has only been the choice for a fortnight - but I’m loving it :smile:


(Lisa Wess) #6

https://discuss.newrelic.com is for support. :slight_smile:


(John ) #7

Yay,

Thanks all for raising your hand.

Here’s a few simple procedural things that I’m curious about how you’re handling:

  1. Not missing stuff
  • It happens regularly enough that we miss a new reply from a user on an existing topic. Multiple sets of eyes, and making use of the Desk/Zendesk help with that, but some still get through.
  • Are others locking down a lot of old posts?
  1. Repetitive questions
  • We’ve added an FAQ link to the Top Menu to make it as prominent and persistent as possible
  • Are others moving questions into pre-existing topics, or just linking to one another?

I would love to hear more about other people’s challenges and what’s working for them as well.


(Joshua Rosenfeld) #8

It certainly happens, but we do our best to make sure it doesn’t. Personally, I track all topics created and watch the support related categories. There are 4 active moderators, and we do the primary triage and “level 1” support for users. For us, most of the posts in our support category are bug reports, and thus an immediate fix/solution doesn’t happen. When we do have a more “traditional” support request, like a crashing game, we usually treat it as first come, first serve. Whichever mod posts first handles the case, and can ping others as needed. Further, we support 8 developers, and as such bring them in where needed/distribute the bug reports.

No. With a few exceptions we do not close/lock old posts. We actually prefer that posts are “necro-ed” as it allows the developers to see that an issue still exists/has returned.

It certainly happens. We do have a number of pinned topics in different categories with common solutions, but we get a fair number of them.

This is one of the situation where we do close threads. If something is reported that is a duplicate, we close the thread, split all posts into the “original” topic, and then move the duplicate to a separate “other reports” category.


(John ) #9

This is where I think we differ a bit, in that many of our customers are consumers, so we tend to get things like “Do you accept paypal?” repeatedly. I think it might make sense to start closing those, and linking to the one canonical response.


(Sam Saffron) #10

A huge reason I used to miss stuff was mobile, I would catch up on mobile but did not have time to reply so stuff goes off my stack.

To resolve this I use bookmarks quite a lot. If I do not have time to handle something I bookmark it and deal with later. The gb keyboard shortcut is a godsend here.

In a full support environment I would possibly look at using staff tags as well, then you could tag stuff as requiring action.


(Joshua Rosenfeld) #11

Definitely different there, but the forum did previously handle more questions like that back when the game was doing a Kickstarter and was sold only through Humble Bundle (now it is on Steam).

We just started using the tag plugin, but in a slightly different way. Being a game, most of the bug reports deal with different aspects of the game (ie. Building, AI, terrain, crafting, etc.). We now tag all support topics with tags related to the bug type, as well as tagging based on the game version and bug report status. Let me give an example:

  1. Bug report comes in related to water in the latest stable release, no tags are applied.
  2. Moderator see post, acknowledges it via a post, and adds tags. In this case we might apply terrain and a12r472 (alpha 12, release 472).
  3. Another user posts a few days later with the exact same issue.
  4. Moderator adds confirmed_by_users tag, that way developers can easily see that it is not a one off issue.
  5. Developer posts in thread acknowledging bug, potentially requesting more details, or announcing a fix. acknowledged_by_devs tag added to let users know that it has been seen.
  6. Bug is patched in a future release. All exisiting tags are removed, resolved tag is added, topic moved from bug report category to resolved reports category. It is NOT closed, that way if the error returns (or was not fully fixed), a user can post there and we return the thread to bug reports and re-apply tags.

As the moderators, we maintain a large list of the tags we use, and have a number of other tags used in specific situations. For example, we have a not_reproducible tag that we can apply to a report when there is not enough information provided by the user and they do not respond to requests for more details, or when the developers cannot reproduce the error despite having enough information. We use not_a_bug when a user reports something that is not in fact an error. We tend to get these when features are changed in a way that is not clear to users. We use no_longer_applicable for reports related to old features, systems, or code that no longer exist, and therefore are not technically “resolved,” but are not an issue either. Finally, we have a few tags used to detail certain report details that are especially helpful, like crash.dmp_provided, log_provided, and save_game_provided.

Overall, the tagging system helps all 3 groups of discourse users. 1, the “users” can see the status of their report quickly as it moves along, 2, the moderators can see when a new report is submitted (no tags) and keep an eye out for duplicates (if all tags match is a good clue), and 3, the developers can see if a certain build or feature is having more issues than others, and when bugs are seen by multiple people versus just one.


(John ) #12

Using bookmarks is interesting. I don’t use them too much now, so I can see how it might serve as a good ‘queue’.

I’ve also just discovered m+w, which will hopefully make it harder for me to miss a unread notifications.


(Alessio Fattorini) #13

http://community.nethserver.org is product based and primarily support oriented but not just this, it’s really similar to meta
New features, bugs, community discussions, feedback, testing, translations, etc…