Revision as of 21:20, August 28, 2015 by Jumunn (talk | contribs) (Update with the copy of version: 8.5.2DRAFT)
Jump to: navigation, search

Email Quality Assurance

Workspace supports Quality Assurance (QA) review of outbound email interactions. Team Leads or other individuals can approve or reject email interactions. You can design your routing strategy to send all email interactions from an agent or agent group to a reviewer; you can design your routing strategy to enable an agent to request a review; you can direct email interactions for review to a reviewer or a group. You can design your routing strategy to send rejected email interactions back to the originating agent.

Designing a Routing Strategy for an Email Quality Assurance Review

The email QA Review process is managed by a Routing Strategy and Business Process design. You must configure specific keys that are set in the interaction by Workspace; these keys are used by the Routing Strategy to route the interaction based on its review state, as defined by the keys. In the following example, the keys prefixed by "BP_" are exclusively under the responsibility of the Routing Strategy or Business Process. The keys that do not have this prefix are keys that are defined by Workspace. The values of the keys are interpreted and/or updated by the core product implementation and can also be interpreted/edited by the Routing Strategy or Business Process.

Prerequisites to enable the "QA Review Disposition" feature:

  • Create a Business Attribute in Genesys Administrator that defines all possible QA review dispositions. The following example uses the Rejected and Accepted dispositions as samples. You should use values that suit your business purposes.
  • Assign the name of this Business Attribute as the value of the email.qa-review-dispositions-business-attribute option.
  • The QA Review disposition that is selected by a supervisor is assigned to the attached data Ixn.UserData.QAReviewDisposition, described in the following section. Your Business Process must apply rules that are based on this disposition— for example, redistributing to the writer.

The following is an example of a Strategy workflow:

  1. An inbound email is received by the Business Process
  2. The inbound email is distributed to an agent
  3. The agent writes a reply email and clicks Send
  4. Workspace makes the following updates to the attached data of the reply email
  • UCS.OwnerID is set to EMailAgent.DBID
  • IxnSvr.UserData.OriginalAgentEmployeeID is set to EMailAgent.EmployeeID
  • IxnSvr.UserData.OriginalAgentUserName is set to EMailAgent.UserName
  • The email is then directed to the Business Process, and the Business Process should make the following updates to the reply email and distribute it to the reviewer target:
    • Ixn.UserData.QAReviewFlag is set to 1
    • Ixn.UserData.QAReviewDisposition is set to Unknown
    • Ixn.UserData.BP_QAReview_Status is set to Review
    • Ixn.UserData.BP_QAReview_Cycle# is set to 1
  • The reviewer reviews the email and edits it or provides feedback. If the reviewer sets the disposition to Rejected, it is sent back to the originating agent.
  • Workspace makes the following updates to the attached data of the rejected reply email:
    • UCS.ReviewerID is set to Reviewer.DBID
    • Ixn.UserData.QAReviewerEmployeerID is set to Reviewer.EmployeeID
    • Ixn.UserData.QAReviewerUserName is set to Reviewer.UserName
    • Ixn.UserData.QAReviewDisposition is set to Rejected
  • The email is then directed to the Business Process, and the Business Process should make the following updates to the reply email and distribute it to the original agent:
    • Ixn.UserData.QAReviewFlag is set to 0
  • The agent makes the required changes and then clicks Send.
  • Workspace makes the following updates to the attached data of the reply email and directs it the the Business Process:
    • UCS.OwnerID is set to EMailAgent.DBID
    • IxnSvr.UserData.OriginalAgentEmployeeID is set to EMailAgent.EmployeeID
    • IxnSvr.UserData.OriginalAgentUserName is set to EMailAgent.UserName
  • The Business Process should make the following updates to the reply email and distribute it to the Reviewer Target:
    • Ixn.UserData.QAReviewFlag is set to 1
    • Ixn.UserData.QAReviewDisposition is set to Unknown
    • Ixn.UserData.BP_QAReview_Status is set to Review
    • Ixn.UserData.BP_QAReview_Cycle# is set to 2
  • The reviewer reviews the email reply again and sets the disposition to Accepted and clicks Send
  • Workspace makes the following updates to the attached data of the accepted reply email and directs it to the Business Process:
    • UCS.ReviewerID is set to Reviewer.DBID
    • Ixn.UserData.QAReviewerEmployeerID is set to Reviewer.EmployeeID
    • Ixn.UserData.QAReviewerUserName is set to Reviewer.UserName
    • Ixn.UserData.QAReviewDisposition is set to Accepted
  • The Business Process should make the following updates to the reply e-mail and distribute it to the Final Send E-Mail Business Process:
    • Ixn.UserData.QAReviewFlag is set to 1
    • Ixn.UserData.BP_QAReview_Status is set to Completed
  • The email reply is sent to the contact.

    • Outbound Email Quality Assurance Review

    The Workspace outbound email review feature enables you to redirect outbound email interactions to an internal target for review. The Quality Assurance Review function has the following features:

    • Outbound email interactions can be redirected to a reviewer
    • Reviewers can accept and send the outbound email to the recipient
    • Reviewers can reject the outbound email interaction and send it back to the author to be reworked

    The following is a sample of the outbound email review process workflow:

    1. Email interaction is received from a contact and is routed to an agent who, by a business process is identified as an agent whose outbound email interactions are to be sent for review before the email is sent to the contact.
    2. The agent creates a reply to the inbound email interaction, or the agent creates a new outbound email interaction, and clicks Send.
    3. Workspace tags the e-mail interaction with the EmployeeID and UserName of the agent, and stores the OwnerID of the author in the email interaction history in Universal Contact Server.
    4. The outbound business process for the agent is activated and the e-mail interaction is flagged for review. The review flag is a count of the number of review iterations which the interaction has undergone. The business process might also be configured to attach other key/value pairs to the interaction.
    5. The email interaction is redirected to the agent, agent group, or role defined by the business process as the reviewer.
    6. The email interaction reviewer can modify the interaction, add information to the Notepad, and then accept or reject the email interaction.
      • If the reviewer accepts the interaction, the email interaction is sent to the contact.
      • If the reviewer rejects the interaction, the email interaction is sent back to the agent who created the email.
    7. If the email interaction is returned to the agent, the agent can change the email according to the comments that are provided by the reviewer or view the changes that were made by the reviewer.
    8. The agent finishes updating the e-mail interaction and then clicks Send.
    9. The outbound business process for the agent is activated and the email interaction is flagged for second review.
    10. The email interaction is redirected to the agent or agent group or roles who is defined by the business process as the reviewer.
    11. The email interaction reviewer can modify the interaction, add information to the Notepad, and then accept or reject the email interaction, or apply some other disposition that is specific to the design of your business process or routing strategy. Workspace tags the email interaction with the EmployeeID and UserName of the reviewer, and stores the ReviewerID of the author in the e-mail interaction history in Universal Contact Server.
      • If the reviewer accepts the interaction, the email interaction is sent to the contact.
      • If the reviewer rejects the interaction, the email interaction is sent back to the agent who created the email and the process begins again. The review count is incremented by one.

    Displaying Review Information in the Case Information Area

    You can create Business Attributes to populate the interaction Case Information area with information about the review process that informs the reviewer and the author of the e-mail about the status of the review. For example, you could create keys for Review Status and Review Cycle Count.

    You can create an editable Case Information attribute that is displayed as a drop-down list of disposition types. Refer to the interaction.case-data.format-business-attribute option for information about creating new attributes for case data.

    Comments or questions about this documentation? Contact us for support!