Difference between revisions of "Support Overhaul by gerg"
(Some changes re: how the helpful/unhelpful buttons & elaboration on the linking KWs & reqs function) |
|||
| (2 intermediate revisions by 2 users not shown) | |||
| Line 19: | Line 19: | ||
The changes are small but important. First, the userpic is gone (oh no), but that's OK, because users can see all the pics anyway, by clicking on the number of userpics they have left. First, the concept of "accounts" (whatever they'll ultimately be called) exists on DW - and that's the first line. The single login that corresponds with however many accounts can be linked and information about that '''account''' are on the first line. Then, information about that particular journal is available. Userpics are broken into base and purchased, so that volunteers can see if the user currently has paid userpics. Expiration dates on paid time and UPI addons are listed. Since I think DW is moving to a more selective model for Support volunteers, I think it is likely that vols will be given access to more info, hence having it on the new see_request. The text on how many UPIs are used is also important so that people who have uploaded too many and have had some go inactive could be identified. | The changes are small but important. First, the userpic is gone (oh no), but that's OK, because users can see all the pics anyway, by clicking on the number of userpics they have left. First, the concept of "accounts" (whatever they'll ultimately be called) exists on DW - and that's the first line. The single login that corresponds with however many accounts can be linked and information about that '''account''' are on the first line. Then, information about that particular journal is available. Userpics are broken into base and purchased, so that volunteers can see if the user currently has paid userpics. Expiration dates on paid time and UPI addons are listed. Since I think DW is moving to a more selective model for Support volunteers, I think it is likely that vols will be given access to more info, hence having it on the new see_request. The text on how many UPIs are used is also important so that people who have uploaded too many and have had some go inactive could be identified. | ||
| + | |||
| + | NOTE: Not pictured in the screenshot above is that "Journal Info" would be a link to an (unmocked-up) page that shows full info on the user. Everything on the request, their disk quota and usage, recent e-mail post log, voice post quota, a link to click to get entryprops of their last entry, etc. This page would obviously be restricted to Support people, and not reveal info beyond what can be seen publicly (so if the user made an e-mail post that was private, the email post log would just show [private post].) This would be very important, because right now it is often necessary to run all over LJ checking 20 different pages of logs and details. This is why we have computers. | ||
The next set contains the search terms the user used to get to the request form, the known issues files that were presented to them (if any), and the FAQs that were given to them (and which ones they read). I envision that FAQs can be much shorter and much more direct answers to questions if this system is implemented. This way, volunteers know what has already been said to the user, so that there aren't "but I already tried that" fests. They also can say "as was shown when you opened this request, the system is down, yo." as appropriate. The last thing is to add the "stale" and "(over 48 hours old)" tags. This could be configured by category and would flag requests over a certain age maybe in a brighter shade of green or something. | The next set contains the search terms the user used to get to the request form, the known issues files that were presented to them (if any), and the FAQs that were given to them (and which ones they read). I envision that FAQs can be much shorter and much more direct answers to questions if this system is implemented. This way, volunteers know what has already been said to the user, so that there aren't "but I already tried that" fests. They also can say "as was shown when you opened this request, the system is down, yo." as appropriate. The last thing is to add the "stale" and "(over 48 hours old)" tags. This could be configured by category and would flag requests over a certain age maybe in a brighter shade of green or something. | ||
| Line 60: | Line 62: | ||
</pre> | </pre> | ||
If a user closed a request from the e-mail message, the request would show up on the request board with a status of "Self-closed" and then on the request detail page "Closed by user with FAQ #XX". They would also show up in a user's support history (and, of course, could be filtered out of a user's support history if the volunteer viewing the history wanted to do so), so that if a user had a lot of trouble with one thing and had obviously searched a lot, volunteers could take that into account. | If a user closed a request from the e-mail message, the request would show up on the request board with a status of "Self-closed" and then on the request detail page "Closed by user with FAQ #XX". They would also show up in a user's support history (and, of course, could be filtered out of a user's support history if the volunteer viewing the history wanted to do so), so that if a user had a lot of trouble with one thing and had obviously searched a lot, volunteers could take that into account. | ||
| − | [[Category: | + | [[Category: Obsolete]] |
Latest revision as of 19:16, 29 October 2023
The idea I had to overhaul the Support System is documented on this page.
Instead of like on LJ and clone sites, where you can just go to the request page and type, this system attempts to figure out the most useful information that the user needs at the time and shows it to them.
Instead of the current request submittal form, clicking "Help" would take the user to a page like this:
There, we can say text about the support system, estimated wait, etc. but it also gives the user a very clear idea of how to move forward (type a query into the box.) There are also links to the special forms for abuse, feedback, webmaster, payments, and suggestions. Outages can be reported in the BRB (big red box) and planned maintenance can be reported in the BBB (big blue box.) This is intended for things that affect the entire site, not small issues. Small issues can go in KI files.
After the user enters what they need help with, they see a page like this:
The gold box appears if a known issue file is entered for that search term. KI files would be like FAQs, but in a separate database. Anyone with supporthelp priv would be able to create them, and they provide a way for small issues (like the RTE not working right in FF3, or the statistics not working for Russian users, etc.) to be able to be stopped from even filing requests, without polluting the box on the main page that will contain genuinely important things. Both ![[info]](http://wiki.dreamwidth.net/wiki/extensions/LJ/images//userinfo.gif){kind=small}
tango and RB have mentioned the "This answer was helpful/not helpful" links. These are in place so that we can optimize future searches based on what things people thought were helpful for any given keyword. Lastly, if the user doesn't think any of the information on this page is helpful, they can click the link to get to the request form anyway.
After that, the request is handled the same way. However, I am proposing a few changes to the see_request page as well. Here is my new version:
The changes are small but important. First, the userpic is gone (oh no), but that's OK, because users can see all the pics anyway, by clicking on the number of userpics they have left. First, the concept of "accounts" (whatever they'll ultimately be called) exists on DW - and that's the first line. The single login that corresponds with however many accounts can be linked and information about that account are on the first line. Then, information about that particular journal is available. Userpics are broken into base and purchased, so that volunteers can see if the user currently has paid userpics. Expiration dates on paid time and UPI addons are listed. Since I think DW is moving to a more selective model for Support volunteers, I think it is likely that vols will be given access to more info, hence having it on the new see_request. The text on how many UPIs are used is also important so that people who have uploaded too many and have had some go inactive could be identified.
NOTE: Not pictured in the screenshot above is that "Journal Info" would be a link to an (unmocked-up) page that shows full info on the user. Everything on the request, their disk quota and usage, recent e-mail post log, voice post quota, a link to click to get entryprops of their last entry, etc. This page would obviously be restricted to Support people, and not reveal info beyond what can be seen publicly (so if the user made an e-mail post that was private, the email post log would just show [private post].) This would be very important, because right now it is often necessary to run all over LJ checking 20 different pages of logs and details. This is why we have computers.
The next set contains the search terms the user used to get to the request form, the known issues files that were presented to them (if any), and the FAQs that were given to them (and which ones they read). I envision that FAQs can be much shorter and much more direct answers to questions if this system is implemented. This way, volunteers know what has already been said to the user, so that there aren't "but I already tried that" fests. They also can say "as was shown when you opened this request, the system is down, yo." as appropriate. The last thing is to add the "stale" and "(over 48 hours old)" tags. This could be configured by category and would flag requests over a certain age maybe in a brighter shade of green or something.
Also, showing the search terms and the resulting FAQs on the request page lets volunteers (anyone with supporthelp priv) say "Hey, FAQ #283 should be linked to people who search for "applesauce"." i.e. If they are constantly referencing FAQs that the system doesn't find, the FAQs can be tagged to come up when a certain keyword is entered. This would ideally be an easy, and fast operation. Ideally, the Help search system would take these volunteer-created linkages into effect, and also use information from the "This helped/This sucked" links in the FAQs to decide what FAQs should be shown in response to any particular question.
The color scheme works out to be: Red - Outage, Blue - Maintenance, Goldenrod - Known Issue, Gray - FAQ Reference
Additionally, tango suggests here (gerg):
"Based on this design, it would make sense to me to have email requests checked over for key words (delete, unsubscribe, etc) and possibly email the users the relevant FAQs when their request is created and the request details indicate which FAQs were sent out." - which I agree with. The autoreply/request confirmation could be something like:
Dear greg@dreamwidth.com: Your request to Dreamwidth's Support department has been filed and assigned request number 12345. You may view this request at http://dreamwidth.com/support/foo. Below are some resources that my help answer your question. If one of them does so, please click on the appropriate link, and your request will be closed. FAQ #28: How do I delete my account? To delete your account, do foo. If this answered your question, please click here: http://dw.com/support/act.bml?close&faq=28&req=12345&auth=kjyd FAQ #84: How do I shot web? [img-timeline] If this answered your question, please click here: http://dw.com/support/act.bml?close&faq=84&req=12345&auth=tcks ... If none of these documents helped, don't worry. A Dreamwidth Support Volunteer will get back to you as soon as they can. signature, etc.
If a user closed a request from the e-mail message, the request would show up on the request board with a status of "Self-closed" and then on the request detail page "Closed by user with FAQ #XX". They would also show up in a user's support history (and, of course, could be filtered out of a user's support history if the volunteer viewing the history wanted to do so), so that if a user had a lot of trouble with one thing and had obviously searched a lot, volunteers could take that into account.
