Jump to: navigation, search

Handling Interactions

Workspace supports the following interaction types:

Workspace also supports the following functionality for various interaction types:

Voice Interactions

Workspace employs the following Voice channel functions:

  • Make Call
  • Release Call (End Call)
  • Hold Call
  • Resume Call (Retrieve Call)
  • Mark done
  • Set Disposition
  • Send DTMF (Keypad)
  • Transfer
  • Consult
  • Conference

You use the following options in the interaction-workspace section to configure voice interactions:

  • voice.auto-answer — Specifies whether a voice interaction is automatically answered when a TServer Ringing event is received. This option can be overridden by a routing strategy.
  • voice.mark-done-on-release — Specifies whether the Mark Done function is required to complete the release of the call.
  • voice.prompt-for-end — Specifies whether Workspace displays a confirmation message when the agent clicks 'End'. This option can be overridden by a routing strategy as described in this Deployment Guide.
  • privilege.voice.can-one-step-conference — Enables instant conferencing of a voice call. Depends on privilege.voice.can-use.
  • privilege.voice.can-one-step-transfer — Enables instant conferencing of a voice call. Depends on privilege.voice.can-use.
  • privilege.voice.can-send-dtmf — Enables agents to send DTMF during a voice call. Depends on privilege.voice.can-use.
  • privilege.voice.can-use — Mandatory to use the voice channel. When the value of this option is set to true, the agent is permitted to use the Voice channel.
  • privilege.voice.show-monitoring.can-use — Enables agents to be notified that the current call is monitored by a supervisor.
  • interaction.disposition.is-mandatory — Specifies whether it is mandatory for the agent to set a disposition code before Marking Done an interaction. This option can be overridden by a routing strategy.
  • interaction.disposition.is-read-only-on-idle — Prevents changes to the disposition code after the interaction has been released. This option can be overridden by a routing strategy.
  • interaction.disposition.key-name — The key that is used to populate attached data or a user event when a disposition code is submitted to the back-end system, such as T-Server, Interaction Server, and Contact Server. This option can be overridden by a routing strategy.
  • interaction.disposition.use-attached-data — Enables the adding of attached data from the interaction in UserEvent. This option can be overridden by a routing strategy.
  • interaction.disposition.value-business-attribute — A character string that specifies the name of the Business Attribute that contains the Attribute Values that are used as an enumerated value for a disposition code. This option can be overridden by a routing strategy.

E-Mail Interactions

Workspace enables agents to handle e-mail interactions, including the following functionality:

  • Reply to inbound e-mails (with or without the original text)
  • Create new outbound e-mails
  • Check the spelling of an outbound e-mail
  • Apply a signature to an outbound e-mail
  • Store e-mails in a workbin
  • Transfer an e-mail to an internal target
  • Set a disposition code
  • Mark the interaction as Done
  • View and copy links to non-embedded images in inbound and outbound e-mail interactions
  • View and insert Standard Responses
  • Paste content from browsers and other applications that display HTML
  • Paste images from browsers and other applications that display HTML

Workspace enables the following E-mail interaction capabilities:

  • Decline an interaction
  • Release an interaction
  • Move an interaction to a Workbin
  • Reply to an interaction
  • Reply All to an interaction
  • Add Attachments to an interaction
  • Send an interaction
  • Save an interaction
  • Delete an interaction

The following are mandatory options for correct e-mail interaction handling:

You can also use the following options for e-mail interaction handling:

  • email.from-addresses — Specifies a character string that specifies the name of the Business Attribute which contains the Attribute Values that are used as available addresses. These come from the addresses of e-mail interactions.
  • interaction.disposition.is-mandatory — Specifies whether it is mandatory for the agent to set a disposition code before Marking Done an interaction. This option can be overridden by a routing strategy.
  • interaction.disposition.is-read-only-on-idle — Prevents changes to the disposition code after the interaction has been released. This option can be overridden by a routing strategy.
  • interaction.disposition.key-name — The key that is used to populate attached data or a user event when a disposition code is submitted to the back-end system, such as T-Server, Interaction Server, and Contact Server. This option can be overridden by a routing strategy.
  • interaction.disposition.use-attached-data — Enables the adding of attached data from the interaction in UserEvent. This option can be overridden by a routing strategy.
  • interaction.disposition.value-business-attribute — A character string that specifies the name of the Business Attribute that contains the Attribute Values that are used as an enumerated value for a disposition code. This option can be overridden by a routing strategy.

Signatures

Workspace enables you to assign default signature templates to outbound e-mail interactions. E-mail signatures allow the insertion of tagged-data fields with data that is related to the agent, such as name, job title, department, phone number, e-mail address, and so on. Refer to "Using UCS Data in Standard Responses: System Variables" in the "Genesys Knowledge Management: Basics" chapter of the eServices User's Guide for more information about the tagged data field. Signatures also support linked image(s) and hyperlinks.

Use the email.signature.line-<n> configuration option in the interaction-workspace section to specify the path and name of the signature file or the location of the Response in the Standard Response Library that is to be used as the default signature.

Tip
This option can be overridden by a routing strategy based on the attached data of the interaction.

Chat Interactions

Workspace supports the following functionality for Chat interactions:

  • Accept an interaction
  • Reject an interaction
  • Ignore an interaction
  • End an interaction
  • One-Step Transfer an interaction
  • Consult with another agent about an interaction
  • Set Interaction Disposition
  • Mark Done

You use the following options in the interaction-workspace section to configure Chat interactions (there are also options that you can use to control the appearance of chat interactions in the agent interface):

  • privilege.chat.can-use — Mandatory to use the chat channel. When the value is set to true, the agent is permitted to use the Chat channel.
  • chat.auto-answer — Specifies whether a chat interaction is automatically accepted and joined when a Interaction Server Invite event is received. This option can be overridden by a routing strategy as described in this Deployment Guide.
  • chat.nickname—Specifies that a nickname (pseudonym) is used in chat sessions instead of the agent's user name, and defines the nickname.
  • chat.pending-response-to-customer — Specifies two alarm thresholds, in seconds, that warn agents that they have a pending response to a chat from a customer. Three levels are displayed: before the warning time, between the warning time and the maximum time, and after the maximum time.
  • chat.typing-timeout — Specifies the duration, in seconds, that the typing notification is displayed after the last keystroke and before the agent or contact sends their message.
  • interaction.disposition.is-mandatory — Specifies whether it is mandatory for the agent to set a disposition code before Marking Done an interaction. This option can be overridden by a routing strategy.
  • interaction.disposition.is-read-only-on-idle — Prevents changes to the disposition code after the interaction has been released. This option can be overridden by a routing strategy.
  • interaction.disposition.key-name — The key that is used to populate attached data or a user event when a disposition code is submitted to the back-end system, such as T-Server, Interaction Server, and Contact Server. This option can be overridden by a routing strategy.
  • interaction.disposition.use-attached-data — Enables the adding of attached data from the interaction in UserEvent. This option can be overridden by a routing strategy.
  • interaction.disposition.value-business-attribute — A character string that specifies the name of the Business Attribute that contains the Attribute Values that are used as an enumerated value for a disposition code. This option can be overridden by a routing strategy.

Facebook Interactions

Workspace supports the following functionality for Facebook interactions:

  • Accept an interaction
  • Reject an interaction
  • Ignore an interaction
  • Mark Done an interaction
  • One-Step Transfer an interaction
  • Set Interaction Disposition

You use the following options in the interaction-workspace section to configure Facebook interactions:

  • privilege.facebook.can-use — Enables agent to use the Facebook channel.
  • facebook.auto-answer — Specifies whether a Facebook interaction is automatically accepted when an Interaction Server Invite event is received. This option can be overridden by a routing strategy as described in Deployment Guide.
  • facebook.comments-pagination-size — Specifies the number of comments are initially displayed and then added when Show More is clicked.
  • facebook.default-queue — Specifies the name of the queue in which outbound interactions are first created. This name must be identical to the the name of the default queue in the configuration layer.
  • facebook.outbound-queue — Specifies the name of the queue in which an outbound interaction is to be placed when an agent has completed editing it.
  • facebook.prompt-for-done — Specifies if the application prompts a confirmation message when the user clicks Done. This option can be overridden by a routing strategy, as described in Overriding Options by Using a Routing Strategy.
  • interaction.disposition.is-mandatory — Specifies whether it is mandatory for the agent to set a disposition code before Marking Done an interaction. This option can be overridden by a routing strategy.
  • interaction.disposition.is-read-only-on-idle — Prevents changes to the disposition code after the interaction has been released. This option can be overridden by a routing strategy.
  • interaction.disposition.key-name — The key that is used to populate attached data or a user event when a disposition code is submitted to the back-end system, such as T-Server, Interaction Server, and Contact Server. This option can be overridden by a routing strategy.
  • interaction.disposition.use-attached-data — Enables the adding of attached data from the interaction in UserEvent. This option can be overridden by a routing strategy.
  • interaction.disposition.value-business-attribute — A character string that specifies the name of the Business Attribute that contains the Attribute Values that are used as an enumerated value for a disposition code. This option can be overridden by a routing strategy.

Twitter Interactions

Workspace supports the following functionality for Twitter interactions:

  • Accept an interaction
  • Reject an interaction
  • Ignore an interaction
  • Mark Done an interaction
  • One-Step Transfer an interaction
  • Set Interaction Disposition

You use the following options in the interaction-workspace section to configure Twitter interactions:

  • privilege.twitter.can-use — Enables agent to use the Twitter channel.
  • twitter.auto-answer — Specifies whether a Twitter interaction is automatically accepted when an Interaction Server Invite event is received. This option can be overridden by a routing strategy as described in Deployment Guide.
  • interaction.disposition.is-mandatory — Specifies whether it is mandatory for the agent to set a disposition code before Marking Done an interaction. This option can be overridden by a routing strategy.
  • interaction.disposition.is-read-only-on-idle — Prevents changes to the disposition code after the interaction has been released. This option can be overridden by a routing strategy.
  • interaction.disposition.key-name — The key that is used to populate attached data or a user event when a disposition code is submitted to the back-end system, such as T-Server, Interaction Server, and Contact Server. This option can be overridden by a routing strategy.
  • interaction.disposition.use-attached-data — Enables the adding of attached data from the interaction in UserEvent. This option can be overridden by a routing strategy.
  • interaction.disposition.value-business-attribute — A character string that specifies the name of the Business Attribute that contains the Attribute Values that are used as an enumerated value for a disposition code. This option can be overridden by a routing strategy.

Workbins

A workbin is like a shared queue for Agents, Places, Agents Groups, and Places Groups, in which an agent, supervisor, or manager can store e-mail and other multimedia interactions that are to be handled later. However, unlike with a queue, interactions that are stored in a workbin can be accessed in any order; interactions can be assigned to agents, places, agent groups, or place groups. Items that are stored in a workbin are owned by the owner of the workbin. Open interactions can be added to a Workbin to be saved for future processing or collaborative processing by the agent, place, agent group, or place group.

You use the following options in the interaction-workspace section to configure Workbins:

  • workbin.email.draft — The name of the workbin to be used to store draft e-mail interactions.
  • workbin.email.in-progress — The name of the workbin that is to be used to store inbound e-mail interactions for later processing, after an agent explicitly saved the e-mail interaction or submitted an outbound reply.
  • workbin.facebook.draft — The name of the workbin to be used to store a draft Facebook post.
  • workbin.facebook.in-progress — The name of the workbin that is to be used to store inbound Facebook posts for later processing, after an agent explicitly saves the Facebook post or submits an outbound reply.
  • workbin.twitter.draft — The name of the workbin to be used to store a draft Twitter post.
  • workbin.twitter.in-progress — The name of the workbin that is to be used to store an inbound Twitter post for later processing, after an agent explicitly saves the Twitter post or submits an outbound reply.

Standard Responses Library

The Standard Responses Library (SRL) enables you to access a database of prewritten standard responses for interactions. Agents can insert these responses as replies into any e-mail or chat message.

Agents can modify the contents of a standard response after inserting it into an e-mail interaction or chat message.

To use the Standard Responses Library, you must set up the multimedia feature in HTCC, by using the features-definition.json file.

This page was last edited on March 28, 2014, at 16:11.
Comments or questions about this documentation? Contact us for support!