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

Question form page

• Name (prefill if user is logged in)
• Email (prefill if user is logged in)
• Type the question
• When the problem started to occur (selectable option)
• How often the problem happens (selectable option)
• text: Are you currently on the computer that is having the problem? (checkbox default to yes)
• Which agent the user would prefer to chat with

Clarification page (only show if their browser doesn't allow autodetect)

• Which OS (autodetect)
• Which Firefox version (autodetect)
• Which plugins are used (autodetect)
• Article/search used to get to chat (autodetect, hidden from user)

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 freely, and people with "Room Monitor" permission can watch without joining.

• 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
• If a user closes the window instead of hitting button, prompt with new window
• Flash the browser bar when there's new status if user isn't focused on that window
• Large messages (~20KB) must be supported for large pastes. HTML support would be ideal for pasted screenshots, but this is not required.
• 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 chat multiplier, to control how many people are allowed into the queue
• See questions in the queue, ideally on the chat dashboard
• Get notifications upon chat offers, invitations, and messages
• Join #sumo via the Live Chat interface (P2 requirement)

Upon accepting/joining a chat

• See the full chat history when joining an ongoing chat
• See chat details (OS, plugins, version, question, etc)
• See canned responses in a dropdown menu
• 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 some sort of notification (blinking tab, notification text) when chats need attention. (This is replacing the invitations as a P1)
  • Username mentioned in a chat
  • User activity in a chat that has no agent activity for X minutes
  • Private message received
• Be able to communicate with other helpers via a contributors conference (eg. integrate #sumo) and/or by private instant message.
• See the chat interface integrate with SUMO without popup window(s) (P2 requirement)
  • Ideas for how this might work at Support/Live Chat/UI
• Chat sessions can't be lost when the browser crashes or is restarted.

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 the sum of all helpers' chat multipliers. The default multiplier is 2, but can be bumped up to allow more into the queue.
• The entire queue should be displayed on the chat dashboard
• 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
• All helpers in the "Live Chat helpers" group must be able to pick any question from the queue
• Helpers must be able to join chats in progress. Helpers without queue permission should be able to "knock" on a room to request permission to join.

Contributor permissions

All of these permissions should be configurable, so we can change which groups have which permissions. The groups below may change with future policy decisions.

• Ability to speak in a chat. (Concept of "voice"/"mute" permission)
• Access the chat dashboard
• Join any chat (either queued or active)
• Ability to unmute oneself
• If we need to limit Trainees' ability to join rooms, one or more of the following permissions (P3 requirement)
  • Ability to configure a chat to allow Trainees to join
  • Ability to invite a Trainee to a chat
  • Ability for a Trainee to request to join ("knock on") a chat
• Ability to stay invisible while muted (room monitoring)
• Ability to mute others
• Ability to kick from a chat and ban from joining more chats
• Open and close the chat queue
• Change configuration settings, assign users to groups
• Ability to set tags on a chat
• Ability to see chat logs
  • See all chat logs
  • See chat logs that one has participated in
  • See previous chat logs from users currently chatting

Group roles

Unregistered users

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

Trainees

Felix's user story

• See the chat dashboard
• Some method to join chats for training purposes, either with or without permission from another contributor

Live Chat helpers group

Abby's user story

• Pick any question from the queue to answer
• Join any ongoing chat from the current questions list
• Ability to speak in any chat (may require unmuting oneself)
• Apply tags to chats (P2 requirement)

Room Monitors (or Moderators)

John's user story

• Watch any chat without the user or agent knowing
• 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 multipliers
• See chat metrics and be able to search the chat logs (P5 requirement)

Metrics and database tables

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
• Date/time
• Wait time in the queue
• Was the chat answered by an agent (yes/no)?

Chat message storage

• Chat's unique ID
• Sender's username
• Message text (each message up to 20KB)
• Date/time

Conversation participants (only include joined users, not monitoring users)

• Chat's unique ID
• Username (agent)
• Date/time that the person joined.

Survey result in DB

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