Review Step

The Review Step has a special function in the Y Meadows system and has a number of unique inputs and outputs. Overall, the purpose of this step is to permit a Service Agent to interact with a Message while it is on a Journey in order to:

• Correct incorrect intents

• Update outgoing correspondence

• Route “special” messages for special handling

• And more!

The review step has two different input sections in the UI. One that looks identical to most other steps and a special “Supplemental Data” section for some data that is unique to the Review Step. Most of the inputs are used to control what information a Service Agent will see when working on a review (For more information about the service agent experience, navigate here: Reviews Overview). In the Review Step UI there are a number of pieces of information presented to the Service Agent - each must be filled in with the correct information or the Review UI will not make sense.

Inputs: Standard Section

Sender

The senders email address should be filled in here when known. This is available in the senderEmail output pill from the Journey Source Step.

Created Date

The creation date of the message should be filled in here when known. This is available as the createdDate output from the Journey Source Step.

Subject

This should contain the subject line of the original message if one exists. This is available as the subject output from the Journey Source Step.

Attachment

This is a visual indication of whether or not the original message had an attachment. For now, this should be set to (make sure that capitalization matches):

False

We will provide this information as an output of the Journey Step in the near future. Valid values are True and False.

Message

This is the original message that initiated the Journey. This is available as the body output from the Journey Source Step.

Request Format

This input controls how the message will be displayed to the user. There are two acceptable values: “HTML” and “PLAIN_TEXT” (quotes and capitalization must match what is shown). In general, users will use one of these literal values depending on the source system that messages come from. When in doubt, use “HTML” as it is most likely to be correct.

Response

The Response input is for the message that will be sent to the customer if a service agent approves the suggested action during the Review. There is an optional field to allow for a Review even in cases where no response will be sent to the customer.

Response Editable

This input is either True or False to indicate IF an agent is permitted to edit the outgoing response before sending it to the customer. Note that True and False are NOT quoted in the input editor.

Response Format

This input controls both what the service agent will see in the Review UI and the format of the message that results from editing. There are two acceptable values: “HTML” and “PLAIN_TEXT” (quotes and capitalization must match what is shown). In general, users will use one of these literal values depending on the method used to send outgoing messages. When in doubt, use “PLAIN_TEXT” as it is most likely to be correct.

When this is set to “HTML”, the agent will have a visual editor that can create bulleted lists, bold text, headlines, etc. The message will be sent as HTML. If this format is used with a message service that only supports plain text, the message will contain additional characters used by HTML for formatting (eg: "This is the MESSAGE" would look like this: "<p>This is the<b> MESSAGE</b></p>")

Proposed Outcome

The Proposed Outcome is shown in the middle of the Review UI and should contain a short message to the service agent about what actions will be taken if the Reviewer approves the case/message. This can be literal text (“The customer will get a refund”) or users can use a Template Step to generate the message dynamically (“Yvette will get a $256.38 refund for returning item #1764927”). Note that there are additional opportunities to provide specifics about the outcome in the Supplemental Data (see below) so a short, static message is often appropriate.

Intent

This is generally filled in with the effectiveIntentId output from the Junction Source Step. The intent provided here is displayed to the Service agent and should represent the prediction made by Y Meadows’ AI about the message. The primary purpose of a Review Step is for the agent to confirm that the AI has made a correct prediction or to correct the prediction when the model has miscategorized the intent.

Confidence

This input is filled in with the effectiveConfidence output from the Junction Source Step. The value provided here must be a number between 0 and 1 that represents the expected accuracy of the AI prediction. If the value is 1 (100% confidence), the intent was NOT set by Y Meadows’ AI and has been provided programmatically. The value is shown to the agent as a percentage to give them context when reviewing the AI’s choices.

Review Queue

Y Meadows supports multiple Review Queues to help organize work between different teams in an organization. The messages from this Journey are available in the Review Queue that is provided in this input. This value must be manually chosen and is not likely available as an output from a previous step.

Inputs: Supplemental Data Section

“Supplemental” data, in this case, refers to any information about the message or the proposed resolution that you want to display to the Service Agent during a review. There are two areas in the interface where this data is displayed; “Additional Information” is displayed above the original message, while “Proposed Changes” are displayed above the response. These inputs provide you with an opportunity to customize the information provided to an agent with information specific to your business processes.

The Supplemental Data Section of the Step Properties section of the UI

The Supplemental Data section of the Input Editor section of the UI:

The outcome of setting Supplemental Data is shown in the Review UI to inform the agent.

Additional Information

In this section, users can include as many lines of data as they would like. Use the “+” and “-” buttons to add and remove lines of input. Replace with "The label field(s) contain literal text that is displayed exactly how the user types it in the Review UI (no quotes needed) and the value field(s) provide users the ability to fill in variable data that changes for each message. In the above diagram, the labels were set to Current Status and Customer Name - the values “Bronze” and “Quail Coleman” were filled in using outputs from other steps.

Proposed Changes

Users can include as many lines of data in this section as they would like. Use the “+” and “-” buttons to add and remove lines of input. The label field(s) contain literal text that is displayed exactly how the user types it in the Review UI (no quotes needed) and the value field(s) provide users the ability to fill in variable data that changes for each message. In the above diagram, the label was set to Points to Award, and the value of “1400” was filled in using outputs from other steps.

Outputs

actionApproved

If the agent uses the “Go” button to approve the review this will be True. In all other cases it will be False.

editedResponseFields

This output contains information about any changes or additions made during the review. The information in this output is mainly used by the Junction to route the message correctly after a negative review. It is not commonly used as an input to other steps.

intentApproved

If the agent uses the “Go” button to approve the review this will be True. In all other cases it will be False.

responseBody

The message response that is intended for use in communication with the customer is included in this output. This can either contain the original response body, if the agent did not edit it, or it will contain the edited response that was crafted by the agent during the review.

reviewerAssignedIntentId

If the reviewer has chosen an intent for the message that is different from the one chosen by the AI then the Intent Id for that intent will be in this output. This can be used to direct the message to a better path to resolve the message. If the agent did not assign a new intent then this will have the value null when looking at the data in the Trip report or (equivalently) None when used in the expression editor.