Community Wishlist Survey 2019/Editing/Route users through knowledgebase before contacting OTRS

Route users through knowledgebase before contacting OTRS

  • Problem: The "Contact us" page at en:Wikipedia:Contact us generates a lot of mail to OTRS, many of which are sufficiently answered with boilerplate templates. The OTRS info-en queues are constantly backlogged. Many of the incoming emails (such as those pointing out errors in articles) would be more appropriate if posted to an article talk page instead, others would be best answered by online knowledgebase articles displayed to the user in response to a query. OTRS volunteers continually face a flood of emails that must be handled manually when many of these emails could be pre-filtered by an automated help system. This would free up OTRS volunteers to focus on more difficult and complex requests.
  • Who would benefit: Less workload for OTRS volunteers. Wikipedia community may end up getting more participation. Ceasing public exposure of email addresses would reduce the incoming spam load to OTRS also.
  • Proposed solution: Remove the email addresses from the "Contact us" pages and set up a system that guides the user to a solution before attempting to contact OTRS. The workflow would look like this:
    1. User has a question, goes to help page, which asks "What do you want to know or need help with?"
    2. User selects from list of common topics: I want to request an article, I want to write an article, I found an error, I want to be unblocked, I forgot my password, delete an article, etc.
    3. Depending on the topic, there may be another list: "I want to write an article" would provide options such as: I want to write about myself, I want to write about my company, I want to write about my band, etc.
    4. Depending on the selection, the user is shown a knowledgebase page which would be the boilerplate template that OTRS volunteers would manually respond with anyway — or is directed to one of the help desks or one of the reference desks.
    5. The knowledgebase page, if reached via this support flow, has a button at the bottom asking if this was helpful.
    6. If not, then the user is not shown an email address but is directed to a web form to fill in.
    7. If the message deals with an error in the article, the user is given an option to post the message to the appropriate article talk page rather than emailing, pointing out that the message will have a wider audience that way.
    8. If the user proceeds to emailing, the web form is processed so that an email is sent to the appropriate OTRS queue.
  • More comments: Much of the above can be accomplished by rearranging the pages in the "Contact us" hierarchy. OTRS agents should also be able to add new topics to the flow above, and create new pages, to prevent future mailings. We don't have to hide the OTRS email addresses, but rather show them as a last resort after the user has had a chance to get an answer without emailing. The system we have in place now absolutely doesn't scale, as evidenced by the backlogs and not enough bodies.
  • Phabricator tickets:
  • Proposer: Anachronist (talk) 01:39, 11 November 2018 (UTC)[reply]

Discussion

  • Very cool!   — Jeff G. ツ please ping or talk to me 03:26, 11 November 2018 (UTC)[reply]
  • Great idea! Ciell (talk) 09:05, 11 November 2018 (UTC)[reply]
  • I support this. Good stuff. Ww2censor (talk) 09:34, 11 November 2018 (UTC)[reply]
  • This would be useful for OTRS. It would also be useful in many other places. There is a sort of decision tree which new users can go through in the en:Wikipedia:Article_wizard, where new users can answer questions to land on the support they need. One way this could be developed is as a decision tree, chatbot, or whatever other publishing format this takes, and only for OTRS. Another way this could go is to technically develop interactive knowledgebases for general application in any situation. Blue Rasberry (talk) 13:46, 11 November 2018 (UTC)[reply]
  • I support this as long as the email “info-[language]@wikimedia.org” is not removed from contact pages and support pages. People should still be able to email in directly, although a form like this would be nice to allow the more common questions to be answered without taking volunteer time. Vermont (talk) 17:39, 11 November 2018 (UTC)[reply]
    I agree, the email addresses shouldn't be totally hidden. I added a note to that effect the comment in my proposal above. Anachronist (talk) 16:20, 12 November 2018 (UTC)[reply]
  • Not in favour of this. I have read thousands of OTRS tickets, and generally speaking they are written by people who do *not* want to edit Wikipedia. All of the other solutions offered on that page require editing. Some of them even refer the person to convoluted policies (e.g., en:Wikipedia:Dispute resolution) which even experienced Wikipedians have difficulty following. I'd like to see some evidence that a form is more likely to result in customer satisfaction than an email would; someone still has to respond to the form. I'd also like to see mock-ups of forms that would be able to feed directly into the OTRS system. I do not think that the proposal has shown that it will improve workflow, improve customer satisfaction, or reduce the frequency that individuals feel they need to contact someone. Risker (talk) 18:44, 14 November 2018 (UTC)[reply]
    For tickets that result in a templated response (from our "knowledge base" of templates), the users should see this before writing an email. Companies who must provide technical support (Dell and A2 Hosting come to mind from personal experience) have similar systems in place because they have already been proven to improve workflow and reduce the need for manual communication. The intent of the proposal here is to provide some directed guidance and information to users before they send an email. Consider also that OTRS is not only in English, but also in other languages where agents are desperately understaffed. Some sort of guided direction and filtering is in order here. Anachronist (talk) 19:31, 14 November 2018 (UTC)[reply]
The "knowledge base" is almost exclusively geared to directing the person to edit Wikipedia themselves. That is not a good solution, and is very unfriendly to customers. (I already don't think we're customer-friendly when it comes to many of the responses we make to OTRS customers.) It may make OTRS agents happy, but it does almost nothing for the encyclopedia, and makes work for the editors and admins on the project who get stuck reverting or deleting junk or COI articles/edits. It expects that the OTRS customer actually *wants* to edit Wikipedia; many of them don't want to do that, and some of them already tried that and felt they were treated very poorly. (And in honesty, a lot of them *are* treated poorly.) So no, I think this is precisely the wrong solution to issues. Let's go back to backing up the perception of backlogs and overwork with some real evidence. Enwiki OTRS has about 100 tickets in it as I write; when I first started working on it many years ago, the typical backlog was 3-5 times that high. I don't have access to see the backlogs on other language queues, but this proposal is written in a way that is pretty specific to enwiki. So - let's get some information on the actual backlogs, the percentage of queries that are completed within 24 hours/72 hours/one week, how this compares to years previous, etc. I do have the sense that, just like in many areas of the project, some OTRS agents are feeling fatigued and frustrated. That doesn't mean the system isn't working, or that it should be revamped. It probably means it's time to recruit more OTRS agents and allow those who have been diligently making a large number of responses to slow down a bit. Burnout is a real problem - I know, I've been there - but the best solution for it is fresh faces to allow the most dedicated to take it a little easier. And I do think there is room for improvement with OTRS, but I don't think this would be one that leads to better customer relations, especially when the customers we're talking about are frequently concerned with what they see as serious problems in articles about themselves. Risker (talk) 01:01, 15 November 2018 (UTC)[reply]
I strongly disagree that throwing more bodies at a problem is not a good solution, when it's possible to implement a reasonably simple way to provide information to users before they write email. The impression you're giving is that this proposal is to replace humans with an automated process, and that's a straw man, not what is being proposed. Customers will still have the option to communicate with OTRS. Basically I'm proposing two things: that users be given information specific to their question before they contact OTRS, and that they are offered to post their question or complaint on an article talk page for broader exposure. They are not prevented from contacting OTRS. And so far, no one objecting has identified the harm in that. Anachronist (talk) 07:40, 15 November 2018 (UTC)[reply]
  • I Would support this as it will bring down the workload for OTRS agents. FitIndia Talk 20:20, 14 November 2018 (UTC)[reply]
  • An extremely poor idea, unless reworked to just be an alternative, not an obligatory step, in which case it's just a poor and impractical idea. . We want to encourage people to contact us for problems, not set an extra barrier. Sometimes the knowledge base will be a preferable way, but not always and certainly not for all people. We here are relatively accustomed to working with complex processes, and many of us are not all that happy with asking strangers questions. The general public probably does not share either of these characteristics.
If we do it at all, we should make it an equal option , not a barrier. (And for it to even work in a minimally acceptable way, ,we would first have to rewrite the "knowledge base" into a form that is comprehensible by non-wikipedians. Based on my own experience, that will be very much harder than writing individual answers--and the hardest part of the rewriting will be figuring out what actually happens, and what would be the right way for things to work. To try to put policy into a knowledge base means having clear and non-self-contradictory policy. But very little of our policy is actually of that nature, as a little experience at any process like AfD will show--everything actually depends upon the interpretation, and while the two ends of what we accept or reject may be clear, a great deal comes in the middle, where what actually happens can be almsot random. To get this right is a multi year project, and the writing doesn't need the WMF. Once we've rewritten our documentation successfully ,then willl be the time to consider it. If a few good volunteers made it a priority, and received a some technical support from the Foundation, we might be ready in two or three years (assuming we agree on what should be said, which in practice will mean revisiting almost every guideline we have and rearguing it from scratch) -- but I wouldn't count on it. And then we'd have to maintain it . Don't understimate that, because we have never been able to fully maintain anything. DGG (talk) 05:58, 15 November 2018 (UTC)[reply]
Sure, make it an equal option. We are not at the stage of making architectural decisions about how this is structured. In my view, however, doing nothing is not an option. Anachronist (talk) 07:41, 15 November 2018 (UTC)[reply]
  • Just so we are all aware here. Any admin with the interface editor right can create .js forms that execute from other areas of the project. I have confidence in our WMF developers to create gadgets and what not but to expect them to create multi-language, in depth, form resources when they don't know exactly what we are going for is just a waste of their time and resources. All that will do is for them to make something for someone who actually cares about the project to tell them they are all wrong making nobody happy. It would just be easier to have someone else do it. Which isn't that hard if you know javascript. --Majora (talk) 21:55, 15 November 2018 (UTC)[reply]

Voting