TL;DR: I think we can get by pretty well with existing features. Will let you know more when its been put into action.
After completely reading the topic I linked to above, I think that there are a lot of similarities in what I am looking for to those described by the likes of @mkirk and @haiku.
Another way of looking at it is that its a further extension of adding features such that Discourse can completely replace email / mailing lists.
We have use a variety of communication tools at our small company to provide our customers tech support including, a web ticketing system (zendesk), email, phone, and remote access vnc and teamviewer. There is a mixture of issues that can be discussed openly and those that cannot (especially / obviously when they require exchanging credentials for remote access).
Now we are looking at adding Discourse to the mix because having an open forum where users can discuss their issues, ideas, etc like you see happening here on meta would certainly be a valuable resource to them.
Each of these tools has their merits, but there are too many already, and so reducing the number of channels an end user has to consider when seeking support is one of my goals.
We have decided to cut out zendesk as the ticketing/knowledge-base system, as discourse will better fill the role of knowledge-base, and the ticketing system is under-utilized (in part because people are so used to using email for asynchronous communication).
Email is hard to replace though. Everyone already uses it every day and they can freely copy anyone in their address book on any message if its relevant to them.
They can email us at support@domain.com. The message is visible by anyone in the support group, as well as anyone else they have copied or that we copy in the future. The archives are visible by anyone that is later added to the support group, so it becomes a knowledge-base in of itself.
Its probably not replace-able unless we cut the cord and say: “you must use Discourse for support” - perhaps in combination with the email-in feature.
If it does the job and its so hard to replace, why would we want to do it at all?
- It would reduce the number of channels for support
Go here, search for your issue. If you can’t find it create a new topic or send a PM to support
- It would be easier to encourage people to search for their problem first if they are already in the place where they might find the answer
- It would be easier to encourage people to ask a question on the forum first if they are already in the place where they can do that
- It would encourage those of us handling support to link to relevant posts if we are already in the place where they exist
- It would reduce the amount of noise in our email inboxes
##OK - so on to my ideal workflow:
- Customer runs into a problem
- They log onto discourse
- They may search for their solution first
- They may post a question publicly first
- If they do not do the above, or they do not find their answer, then they send a PM to the support group
- Ideally, there would be a tab for ‘Support’ or ‘Tickets’ on the topic page
- When they click there, they would see any previous issues that they created or have been copied on
- The Create Topic button would say something like ‘Privately Message Support’
- Clicking the support button would open a new private message window:
- support as a non-expanded* group would be the recipient
- their ‘account’ group** would also be a recipient
- they would be able to add/remove additional recipients and write/send their message
- Those of use in the support group would receive a notification of a new private message
- One of us responds, as ourselves, linking to any appropriate public topics or previous private messages involving them
- If the request is one that seems like it could be discussed openly, we suggest they create a topic in the appropriate category, or later we may create one to document the problem and solution
- While responding, it shows us who else is responding***
- If the request requires internal discussion that is private within our group, then we discuss that in a new or existing topic in a private support category and link to this PM
*Non-expanded group
- Support is copied on these messages as a non-expanded group
- These messages are visible to the new members of this group
- Members of this group can control how they are notified of messages in this group, with defaults
-
notify me of new messages to support
-
only notify me of responses to messages that I am copied on personally
if unchecked, you will be notified of all responses to messages in this group
**Account group
- A group can be created for end users in one customer account
- This group will automatically be added to the recipient list on messages to support (thought it can be removed)
This would eliminate cases where different users at the same site contact us independently about the same issue - happens more often than you would think.
***Show who else is responding
- This has come up before on meta. It would help reduce duplication of efforts on our part - a rare occurence, but in the ‘would be nice’ category.
I realize a lot of this is way out of scope for what would go into discourse core any time soon if ever. But you asked for ideal, so I gave it to you.
I think that there are still enough incentives to try to keep people in this environment that something less than ideal would can certainly work.
##Here’s how I’ll try to do this with existing features:
- Create a pinned topic to tell people how to PM support
- Encourage them to look for their answer first
- Encourage them to post a public topic if possible
- Encourage them to copy their co-workers if they are going to send a PM
- Link to this topic whenever people request support via some other channel
- Be OK with the fact that it automatically expands to individual users
- Invite new members of support to relevant historical topics when necessary
- Be extremely happy with the fact that you can change the Tracking/Watching status on PMs
- Create an internal topic on handling support that reminds people in our group of that fact
Discourse team
