Discourse as a private email support portal

This also allows them to reply with a “Oops, nevermind, we resolved the issue by doing x, y, z” without creating a new topic.

Interesting. Sounds like you came up with a way to make the create/see permissions work. I don’t suppose you could open source these tweaks for others to look at?

I wish more companies would make fuller use of their Q&A community like that! Certainly hope this makes it into the spec. It is already possible to an extent.

How did you communicate this to users though? Obviously you’ll omit sensitive info and such, but beyond that: Do you ask users for permission / give them a heads up that their post will be made public, or do you just go ahead with it?

Would I be able to invite a staged account (i.e. an email-user without a username) to a PM by typing in their e-mail?

https://github.com/discourse/discourse/compare/tests-passed...Knagis:tests-passed

I modified the outgoing topic notification e-mail template to include such warning and also the automatic reply include such a warning.

4 Likes

Does this mean there will be some kind of “assign to” functionality added too?

2 Likes

That would be an unrelated change… not against it, but out of scope for now.

@zogstrip has been working on implementing this, I have been working lately on improving group support.

After quite a while contemplating this problem we have decided that giving messages a category is a bad idea :tm:. There is just way too much fallout.

Instead we are looking at beefing up group messaging support with the following changes, that can be rolled out incrementally.

Allow groups to have an incoming email

If we receive any email to the “incoming email” address for a group:

  1. Create a staged account for the user if user does not exist in the system.
  2. Create a new message targeted at the group. (This is already supported by the messaging system, not much new code needed)

Allow users to untangle messages targeted directly at them vs ones targeted at group

Add a new section here:

  • My Groups: Messages not targeted directly at me (but targeted at my groups)

Allow group members to view all messages on group page

This is a pretty simple change, allow a grouped view of all messages to a group

Allow users to specify default “loudness” of notifications for group messages

  • Allow users to specify default watching/tracking/muted for messages targeted at group
  • Allow user to opt in to “blue” notifications vs “green” sticky notifications for postings to the group (needs some discussion first)

These changes drastically reduce the amount of time we need to work on the feature, heavily simplify the implementation, can be be delivered piecemeal and fit very nicely into our theme for the upcoming release.

12 Likes

Pretty cool. The only big difference is that this won’t let you see the support messages in the latest overview.

I am going to take time and respond to some of the feedback from Twitter.

which triggred:

I get the complaints, and the initial design of this feature was quite high risk, what it has become however if very different and I strongly believe it fits in very nicely with our product. Sure, this can be sold as “Use Discourse as a private emails support portal” however at the core this is a natural extension of existing functionality that has been lacking:

  • In the past you were able to accept incoming email into a category. We extended it so you can accept incoming email to a group.

  • In the past you could only mention a @user, now you can mention a @group.

  • In the past you could not see the messages that were sent to groups you belong to separately to your messages, now you can.

This is all about making groups of users first class entities in Discourse. They can communicate privately, they can be mentioned and emailed and so on.

Additionally, we have also had issues around onboarding users, the concept of “staged” accounts is very welcome and very needed, which is generally useful for migrations, onboarding and so on. It allows us to have users in the system that never get digest emails and various other emails until they sign up for real.

Private/personal messaging has always been a key component of Discourse, the ability to communicate privately is critical to running any kind of community.

Handling incoming mail has also always been a key feature of Discourse, many people just want to stay away from the web browser.

So, I don’t see “Making groups first class entities”, “Improving private messaging UI”, “Improving incoming email handling” as huge risk technologies that will destroy us. They are key features of Discourse core that needed extra polish.

20 Likes

Some of those Professional Support Apps are expensive, especially at scale. Paying for a hosted copy of discourse can pale in comparison.

I agree that features supporting discourse as a private support portal help the core, and I’m glad to see them.

6 Likes

This is a shaping up really nicely. Nice work! I just read through this whole topic for the first time in a while. Once the functionality settles down, it would probably be a good idea to start a howto topic to explain how this all functions, in clear language. This will be really useful for us and having all this in discourse, together with our community discussions, will be valuable.

Question: did anyone ever create the functionality to convert a message into a topic?

1 Like

Our Discourse is for the members of a real-world club which has a very flat hierarchy - we make decisions collectively. There are about 100 Members. (>50% of all registered users are in the Members group and >90% Active users are Members.)

When 3rd parties want to talk to us, they tend to email the trustees@ email account, and we say “well that’s interesting but you’ll have to put it to our members - here’s our forum” and they never post.

With this system, we could create a members@ email address, which 3rd parties could email and from there be involved in a <=100-participant email conversation, using Discourse as an intermediary. Am I getting it right?

7 Likes

Thanks Sam! I definitely see the need for support tool like features in some communities and it’s obviously something you guys are going to use yourselves. Mostly my concern is around how much that need to add features for people using Discourse for private support start to pull Discourse away from it’s core mission.

This update definitely makes more clear how you’re doing it via improvements in the core (though it still seems like a pretty heavy update!) vs appending on support tools. I’d just hate to see Discourse become less focused and the burden of maintaining a lot of support specific features. As a company that uses Discourse for the public support of our support app I know how much work a support tool is :wink:

I’ll trust it to your guys capable hands to keep things going as well as they have been!

5 Likes

I’d say the main point of confusion here is caused by the words “support portal”. If we had announced this as three different feature announcements like Sam mentioned above - “Making groups first class entities”, “Improving private messaging UI”, “Improving incoming email handling” - I doubt there’d be much unrest to speak of.

Using this bundle of features for support purposes just happens to be our use case, “eating your own dog food” and all that. The biggest win here is still deeply community-centric.

10 Likes

I also felt some concern when I saw this direction, it felt like a case of dog-fooding taken too far, to the point that the product is being used beyond the bounds of the expected use case for most instances.

I mean, I just want to feed my dog with the product, it doesn’t need to feed my whole family.

This is much more palatable. Specifically the private communication element. Improving whispers so that they don’t increment the post count, and send unintentional notifications to non-staff users would be a step change in usefulness for us. For example, we would use private message on topics to share things like:

  • links to our internal issue tracker
  • background information on a given forum users to inform other staff about about how to respond
  • communicating to other staff that a topic is one we should observe, but leave to the community
  • internal feedback on staff’s responses to ensure consistency and a high quality of response.
4 Likes

Super excited about this feature, we find an interesting use case for this in order to manage communication with clients via auto-categorised messages instead of very long email threads, some of them with 0 interest for some coworkers :smiley:

Only one question: What will happen with emails with more than one recipients out of the community?

For example, client1 asks for support with an email to the specified address, but he copies another people: client2 and client3. So, could client2 and client3 see the topic in the Discourse instance? or only view the replies by email? I think if they view only the messages via email would be enough, but i was wondering about this.

If they don’t already have an account on Discourse, we’ll create a staged one based on their email address. They’ll then be able to see all the topics they’re in once they create an account using the same email address :wink:

5 Likes

So at this stage is there a way to turn the staged users ON and let people create support topics from unregistered emails?

1 Like

Yes this works now and we use it in meta, @zogstrip we really need a #howto on this.

7 Likes

I am quite keen on this as well. Look forward to seeing how this can work for us.

It’s working very well for us already. (http://talk.remobjects.com, support@ is hooked up to a private group)

2 Likes