Discourse as a private email support portal

Feature
,
1

Purpose

We would like to set it up so Discourse can act as a private email support portal for a team. In this mode a single email address will be mapped to a category, all incoming mail will create new messages in that category that can be viewed by all the users with permission on the category. Users will be automatically provisioned as emails come in.

Advantages over central email box

Historically we have used a central email box for our team “support” this has proven to have quite a few drawbacks.

  1. No per-user read / unread tracking, we keep needing to “mark stuff as unread” to avoid confusing the main owner.
  2. Very poor historic record, no ability to search cleanly.
  3. Very hard to have in context out-of-band discussion about a support issue. (whisper feature)
  4. Long email threads are a huge pain to cope with

Proposed solution

To solve this we would like to allow messages to have a category. As it stands categories already can have an incoming email address.

The big change is allowing “messages” to have categories with all the fallout that ensues.

Staged accounts

The first step of the process is going to be accepting incoming mail. To accept incoming mail from an unknown user we will need to create an account.

One huge area of confusion we have seen with mailing list migrations is account creation. If we automatically “create” accounts for users, a large amount of confusion ensues

“Why can I not create an account on the site”.

Additionally, if we automatically create accounts there is are quite a few side effects:

  1. We start sending digests to the users
  2. User becomes “part” of the site unwittingly. They can be mentioned, searched and so on.

For support this is highly undesirable.

Instead I would like to amend it so incoming mail just create an “inactive staged account”, if later the user attempts to register it we should allow them to do so with minimal confusion, including allowing the user to pick a username and name. For all intents and purposes this account will not exist, except when posting on very specific messages.

As it stands if you try to register with an “inactive” account we will prompt you with confusing warnings. We will add another flag to users to explain this “inactive” account was in a “staged” state.

If the user is already in the system with an active account this is a non-problem.

Topic Allowed Users

Currently, to keep track of the users that have access to a message we use the table “topic_allowed_users” this maps users to topics. Each topic may have 0 or more “topic allowed users”

Message permission changes

  • Allow messages to have a category

  • Messages in a category all follow the same permissions as assigned to the category in addition to explicit permissions on the topic. EG: “support staff EMEA” may have permission on “EMEA support”. After an email is processed “topic allowed users” will include ONLY the author. “EMEA support” will be able to view the message because they have permission on the category.

  • Messages will have to start showing up in topic lists (except for messages with no category)

  • If a response is made to a message the responder should automatically be added to “topic allowed users”, this should have always been the case.

  • Staged inactive accounts need to get email notifications for any replies to messages, but nothing else

  • If a user has full permissions on a “message” type group, they can add and remove users from “topic allowed users”

Onboarding staged accounts

Emails we send usually include various links to Discourse, if clicked by “staged accounts” they should first funnel through an onboarding process, where a user is presented with the sign up form.

Migration concerns

Often (like in our case) there is already an incoming mail box for support, we would like to make the transition to Discourse as smooth as possible. To do so it is best to allow this system to operate side-by-side during the migration.

As it stands we only allow one set of credentials for “email polling”, this leaves 2 options:

  1. Allow user to specify email credentials per category.
  2. Allow “polled” mailbox to accept automatically forwarded emails from another mailbox.

Initial implementation will focus on (2), it is fairly trivial to setup email forwarding rules, additionally this will play much nicer with the hosted email-in solution we are going to be offering all our customers.

Notifications

At the moment the only type of notification a message can generate is a “green bubble” notification. This is the strongest type of notification in the system. The green bubble will not go away until you visit a message.

This behavior is highly undesirable for a support team, only the assigned “supporter” should be disrupted in this way.

Instead we will allow notifications on messages to be standard blue notification IF the user is not in the “topic allowed user” list (and instead has implicit permissions due to group permissions)

To reduce friction, always add people who reply to messages to “topic allowed users” this should be done globally.

What about latest and topic lists

We need to decide if we allow messages in categories to be mixed up in the “latest” category list.

Since we already have a setting on categories that allows you to exclude a category from latest we will simply respect it and allow the forum owner decide if they want to “mingle” data or not.

User page changes

No changes really need to be made on the user page, we should only display messages where a user is in “topic allowed users” in the sections there. To see “support” issues “staff” are managing they will need to visit the “support” category.

Creating support topics outside of email

Support categories will be suppressed from the category selector, if we leave it there it can quickly cause confusion and force us to implement messy migration of messages to non message categories etc.

Only way to create “support” style topics from the UI will be a dedicated link on the “support” category. (this will have a nice URL and be easily linkable - with anonymous onboarding if needed)

Search

Message that have a category set should show up in search IF the user has permissions on the category and category is not suppressed from latest. Otherwise they will need to explicitly search in the category to see the messages.

Suggested topics changes for Messages

As it stands suggested topics are absent from messages. Instead we should amend it for messages containing categories.

  • Always show a list of all other messages by the OP (priority 1) - this provides context for support.
  • Try to show new/unread in the same category for users with permissions (priority 2)
  • No random
  • Initially only apply this rule for messages with categories

Whisper changes

In the context of a message in a support category, whispers should be visible and usable by all users who have access to the support category. This means that in some cases non-moderators may have access to the whisper feature.

For example: a company of 1000 people using Discourse with a regional support group handling a regional support email.

Related topics

https://meta.discourse.org/t/create-a-user-with-username-generated-from-email/33859

New category permission : "Create and see"

Ways to post confidential info for moderator eyes only?

Create/See and Create Permissions (again)

I realize the scope here is quite huge, any feedback welcome, this is a planned feature for our upcoming release I will be working on.

44 Likes
4

Super excited about this. Reminds me of HelpScout and I hope it’ll turn out much like it: Very simple to set up and practically invisible to the end-user.

A support channel can be a great starting point for a community. For many businesses your helpdesk is your primary point of interaction with your customers. I’ve experienced this first-hand by working at the helpdesk of a company that was held in high regard by its customers. I had many pleasant exchanges with customers who happily shared experiences and ideas for our product, and I’m 100% sure they would have enjoyed discussing these experiences and ideas even more if they could share them with other users as opposed to just me.

We actually did discuss the possibility of migrating our support desk & knowledge base to Discourse, but the necessary features weren’t there yet.

6 Likes
5

I really like this idea!

I think that the username of a staged account should simply be his E-Mail address – which clearly separates staged from full accounts, which cannot have @ in their name.

Will this be configurable as a site setting? If this could be disabled, the proposed changes would have very little impact on those who don’t want to use this feature.

1 Like
6

Perhaps just known as a “staged account” or “provisional account” going forward?

Here’s a question - what happens when the user with the provisional account replies via email and cc’s their coworker(s)?

Would be great if that added the cc’d users to the message (and potentially confusing if it didn’t)…

7

I’ve been setting up something similar to use as a virtual office for a web development business. The way I am doing it is to have the client make their initial enquiry through the business website. The client fills out a contact form with their name, email, password, and a message. Through the Discourse API a user, category, and group are created for the client. A topic is created from the client’s message in the client’s category.

Permissions are set on the client’s category so that it is only accessible to members of the client’s group and members of the forum’s ‘staff’ group. The rest of the site is only accessible to ‘staff’. I manually set the client’s preferences so that they are watching their category. I disable the forum’s email digest.

When the work is complete, the client’s group is deleted. The client’s category is set as a subcategory of the ‘completed work’ category.

The biggest problem I’m running into is having to have the client confirm their account if they choose to log into the site. I would like to be able to do that manually.

I haven’t yet figured out how to set permissions on a category through the API. It should be possible though.

Could this be deal with by only giving the user access to the category that holds their work?

1 Like
8

Yeah, I like “staged account” … the word provisional has a fair amount of loaded meaning around it.

Sure sounds like a good idea, I think CCd users should be auto added as staged accounts. (and automatically added to topic allowed users.

Category per client is something that scares me a lot, at very large scale our performance is impacted, if you have say 5000 categories expect a lot of pain.

Regarding the “login” pain, I totally hear you. I am thinking that we will do something similar to the change @eviltrout made for /my/preferences for cases where an anonymous account tries to visit a message. Onboard the account directly from there.

2 Likes
9

Sorry, if this is said and I just didn’t find it, but what username will they get automatically? If you use the beginning of their email is there any chance we’re exposing data a user may not what to share with everyone to a wider audience?

Such as, Member Search, Mentions, et al.

Do they get a truly randomized username to begin with and when they choose to actually register, they get to change it? And changing it won’t affect prior mentions, quotes, etc. (like today, right?)

10

There are some complications here I need to work through.

“staged accounts” will not be mentionable, that is pointless anyway as they have no user profile so impact will be minimal.

The complication though is that if someone knows the email of a staged account they may be able to change the username of a staged account prior to validation, a big edge case but I do want to take care of it somehow.

1 Like
11

Ah, okay. I wasn’t sure what state of availability that account would have prior to it becoming “claimed”. Thanks for the clarification.

12

In this scenario - with groups and categories being used to control access - there probably won’t be a need to keep the category or the group for jobs that aren’t active. The idea still might not scale well enough to meet your needs, but it does seem to work well at a small scale.

13

I agree. For staged accounts, the email field should be null (for reasons Sam and others already mentioned, aye :+1: ) or has a specific database entry that further identifies the account as staged.

When the customer makes an actual account, their email address goes into a query that seeks out the staged account related to them and searches every staged account’s username, since they are actual email addresses.

If a match, the staged account is merged to this new account.

If no match, then nothing happens.

When a customer signs up with an email not the one they used to submit support requests/tickets, then the merge may be done manually by an admin.

2 Likes
14

This sounds exactly what we needed and ended up writing a scheduled task that uses API and modifying the source code of Discourse (custom guardian rules that allow topic creator to view/reply his topics in certain categories even when those categories are private).

One thing that I don’t see mentioned above and what we are using is to promote a private conversation to a public one by moving it in a public category. This was the main reason why we switched from Freshdesk to Discourse - we end up publishing most of our incoming support tickets.

Another thing I changed in the code that should be considered - disabled all rules for topic creation from e-mails. Since the sender of the e-mail does not know that the e-mail will be received by Discourse he should not receive replies like “minimum post length is 50 chars”.

Last thing to mention are automatic replies - support systems usually send out messages like “We have received your message and will respond within 1 day”. We have a small enhancement to this - we delay this reply by 1 hour and only send out if someone did not already respond to the topic manually.

8 Likes
15

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

16

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?

17

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

4 Likes
18

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

2 Likes
19

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

20

@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.

13 Likes
21

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

22

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.

21 Likes