Support/Live Chat/Requirements

Feature triage Google Spreadsheet

Getting to Live Chat

We must have multiple ways for users on SUMO to get into live chat

• Clicking an option from the ask a question page or ask a question form
• After pressing "No" on the survey of specific articles (P2 requirement)
  • Can't we just replace the current /chat page as P1 and work on the deeper integrations as P2? -djst

Asking a question

User stories with various types of questions

Before joining the queue

The chat system must allow users to ask questions. Ideally, this would be integrated with our existing Questions app for Kitsune as much as possible. Before beginning the chat, a user must see:

• Whether the queue is Open, Closed, or Full.
• The estimated wait time. (Based on the higher of a static multiplier times the number waiting in the queue or the current maximum wait time in the queue)
• A link or button for starting a chat

At some point before joining the queue, the user must be asked:

• What the question is
• Which OS (autodetect)
• Which Firefox version (autodetect)
• Which extensions are used
• Which plugins are used (autodetect)
• When the problem started to occur (selectable option)
• How often the problem happens (selectable option)
• Article/search used to get to chat (autodetect)

In the chat queue

At some point after providing the question details, the user must have a chance to join the chat queue.

• A position in the queue should be preserved when the user starts typing a question
• If a position in the queue can't be preserved, or the reservation times out, the user should be able to keep trying to join without having to retype the question.

The user must be see:

• Current queue status with estimated wait time, queue position, or other info (design TBD)
• A template containing rules and top issues
• Links to KB articles that the user might want to read while waiting. (search results from question) (P3 requirement)

Chatting with an agent

When the user's chat is accepted by an agent, both the user and the agent should join a multiuser chat. Other agents may join this chat if they are invited or have "room monitor" access.

• Both sides must be able to type messages to each other
• Both sides should see when the other is typing (P2 requirement)
• URLs sent by the agent must be linkified and must open in a new window, so as to not end the chat
• The entire chat session must be logged to the database
• There must be a button to end the chat session
• Basic wiki markup for '''bold''', ''italic'', and [[KB article names]] sent by the agent should be parsed. (P2 requirement)
• Variables like %agent%, %nick%, and %forum% should be parsed into the agent's username, the user's nickname, and a link to follow up in the forum. (P3 requirement)

After the chat has finished

When the chat session ends, the user must see:

• A message thanking them for using the service
• An ability to get a transcript (via e-mail, printout, or any other method). If not a logged in user, an opportunity to type in an e-mail address must be presented.
• A post-chat survey
• A button for following up to the forum (P3 requirement)

When following up to the forum, via a link from the agent or the post-chat button, the following must happen:

• All fields typed into the chat question must be transferred here
• An option to put the entire (collapsed) chat log into the forum post
• The original chat agent should be notified by e-mail

Answering questions

The core requirements for a chat contributor (agent) are:

Before accepting chats

• Set his/her status to available or away (optional, may be dropped)
• Set his/her maximum number of chats (optional, may be dropped)
• See questions in the queue, ideally on the chat dashboard
• Get notifications upon chat offers, invitations, and messages

Upon receiving a chat offer

• Receive a notification that a chat is being offered, showing the question details and time remaining to accept. (optional, may be dropped)
  • Implementation note: offers may be kept internally, but they should be fully transparent if we have them.
• Automatically join a multiuser chat room when accepting a chat.

Upon accepting a chat

• See chat details (OS, plugins, version, question, etc)
• See canned responses in a dropdown menu, which can be sent to a user
• Add tags to the chat (P2 requirement)
• Invite other agents to the chat
• Confirm his/her intent before closing the chat

Other

• Handle use cases of different numbers of chats. (Most helpers will have ~5 open, room monitors may have up to 50 open)
  • why exactly 50? it seems like a really big number if this is per agent. needs clarification on what kind of UI misbehaving we want to avoid -djst
    • Matthew's record for most chats at one time in Spark is 50, so this seems like an upper bound.
• See notifications showing which chats need attention. (eg. chat tabs should appear red if they have an unread response and blink red if gone unanswered for X seconds) (P2 requirement)
• Be able to communicate with other helpers via a contributors conference (eg. integrate #sumo) and/or by private instant message (P2 requirement)
• See the chat interface integrate with SUMO without popup window(s) (P2 requirement)

Chat queue

All questions that make it through the chat ask-a-question process must be added to a queue, so we can answer older ones first.

• The maximum number that can be in the queue is set to a configurable multiplier times the number of active agents
• The entire queue should be displayed on the chat dashboard
• Offers from the top of the queue should be offered to available agents with chats below their limit. The agent must have an exclusive period of time (20-30sec) during the offer where only he/she can take that chat. (optional, may be dropped entirely)
• Questions in the queue for more than X minutes should time out, and the user should be informed that we regrettably couldn't chat with them.
  • Note: messaging on /chat/ should set user expectations appropriately

Permissions

Unregistered users

• Ask a question
• See number of helpers online, number of users waiting, and the estimated wait time (via dashboard)

Logged in users

Felix's user story

• See the chat dashboard
• "Knock" (request to join) on a question being answered (P3)
• If invited to a chat session, see the full history and question details of that session
• Join #sumo via the Live Chat interface (P2)

Live Chat helpers group

Abby's user story

• Pick any question from the queue to answer
• Invite any registered user to any chat session
• Private message other online contributors (P3)
• Apply tags to chats (P2)

Room monitors

John's user story

• Watch any chat without the user or agent knowing
• Join any chat
• Talk in any chat
• Kick the agent out of any chat, to handle abuse
• Open and close the chat queue
• Temporarily prevent an agent from accepting more chats (currently controlled via chat limit, but we'll need a new method)

Administrators

• Assign people to room monitors and live chat helpers groups
• Edit canned responses
• Edit templates used on /chat/ and in the queue waiting page
• Set agents' chat limits (may be dropped)
• See chat metrics and be able to search the chat logs (P5 requirement)

Metrics

We must store data for collecting metrics, but a frontend for the metrics isn't part of our requirements

Questions we must be able to answer

1. How many chats did we solve in a given week?
2. Given a range of chats, what percentage were successful?
3. Of the people entering the queue, what percentage did we answer at all?
4. What was the median wait time in the queue?
5. Which tags and tag groups were most common in a time range? (if we have tag support)
6. Which chat helpers helped the most users?
7. Which chat helpers were most/least successful according to post-chat surveys?

Chat session database record in DB (created when the question is created, regardless of whether it gets an answer)

• Unique ID (key)
• Question fields (title, OS, version, etc)
• Tags
• Transcript
• ID's of all participating helpers
• Date/time
• Wait time in the queue
• Was the chat answered by an agent (yes/no)?

Survey result in DB

• Chat's unique ID (key)
• Helper username
• Customizable question/answer pairs.
  • Was the problem solved?
    • If yes, rate your experience from 1-5.
    • If no, tell us why.
    • If there was no Firefox problem to begin with, abort survey.