Design specification

Throughout the life of a conversation program, it is extremely beneficial to maintain a specification of the conversations. The spec should identify the conversations, and for each conversation, define the details of each dialog. One easy way to do this is with a shared worksheet that all team members can consult.

Discovery phase

The goal of the discovery phase is answer questions that will affect the design of the conversation. Questions you need to answer include:

• What channel will transport the conversation? Each type of channel has unique features and characteristics that determine the type of dialogs you may use. Some like Facebook can show images in a carousel where the respondent may swipe and tap on the image. SMS channels, on the other hand, should be short and concise text messages. See Channels for complete details about each.

• When may feeded invitations be sent? Do the invitations need to respect a sending window and blackout dates? Due to the more intrusive nature of direct conversations it is common to have restricted times where invitations can be delivered to respondents.

  • For example some companies only survey during business hours. Invitations sampled outside the window are queued for delivery in the next window.

  • Availability windows are based on the respondent's timezone, which is specified in the feed.

  • Blackout dates prevent sending invitations on specific dates, such as national or religious holidays.

  • How frequently may invitations be sent to the same respondent?

• What will the opt-out words or mechanism be? An opt-out is a direction from the respondent to stop all future conversations. Typically the word "STOP" is the opt-out command, but different locales have their own customs.

Design phase

Design your conversations to be simple and to keep respondents engaged. As noted earlier, it is import to maintain a Design specification that defines the conversation elements. 

In the design phase, identify the questions to ask and the options to present, and test them (on paper) by showing them to people and asking them to read the messages and ask how they would respond. Pay particular attention to the responses because they can indicate

• Confusing or ambiguous questions that need to be rewritten

• Possible alternative answers that can be caught with Response rules

• Places where the conversation should switch to a different conversation or dialog, and places where you might be able to skip a dialog

When your company has existing survey programs, either web- or conversation-based, be sure to leverage existing questions instead of creating new ones. However, web-surveys often use 10 or 11-point scales when gathering respondent ratings, while conversation-surveys often use 5-point scales. The 5-point scales can be mapped to the larger scales for reporting purposes by using calculation fields (K-Fields) in Medallia Experience Cloud. But better is to ask the question with a larger scale, such as "Please rate your experience from 0 to 10 where 10 is best."

Include a catch-all, Open Question where the respondent can tell you about the thing you didn't ask. 

Finally, clearly end the conversation so the respondent has no question it is complete. For example, say "That's all thank you for your time today. Visit our web page for additional information."

Best-practice survey conversations

As noted in Tips and considerations, a good survey is short with concise questions. Best-in-class surveys start with an overall outcome metric question that measures the respondent’s whole experience, and to capture top-of-mind feedback before additional questions introduce bias. The survey then typically includes 1-3 KPIs (Key Performance Indicators). KPIs can be included to track overall scores for a particular area of business. Ask open-ended questions after key metrics have been asked because these types of questions faces a higher drop-off rate in conversations than in traditional web-surveys.

Omit segmentation and demographic questions unless absolutely necessary.

Scales

When surveys are delivered on channels that do not present options as buttons (such as SMS), be explicit about what the scale and options are. Whenever possible it is good practice to spell out all the options available. For example, "Please answer Yes or No."

Conversation flow

One of the strengths of Medallia Conversations is the ability to branch to other conversations mid-stream, to skip dialogs, jump to another dialog in the same conversation, and to immediately respond to answers.

For detailed information about controlling conversation flow, see Condition rules.

Skip dialog

Skip-dialog actions especially useful for conditions where the dialog should be skipped. For example, you might have two dialogs, one that recognizes the respondent as a member of the loyalty program, and one for respondents who are not part of the program.

Hello Rewards Customer, thank you for visiting us today.
Hello, thank you for visiting us today.

When the respondent is not a member of the loyalty program skip the dialog that includes the reference; otherwise, skip the one without the reference.

Go to dialog

The Go to dialog action is useful for skipping several dialogs that do not need to be shown or asked. They are especially useful for "randomizing" questions to ask. For example, consider a conversation that has three questions, but for each respondent, you only want to ask one in an effort to keep the survey short. In this case, the invitation feed from Medallia Experience Cloud includes a field who value has been randomly set to 1, 2, or 3.

During the conversation, an earlier dialog can have a post-action that look at the value of the field, and then jumps to the corresponding question. After asking the question, another post-action jumps to the next dialog that is not one of the three questions.

For the example above to work, the import specification in the Medallia Experience Cloud must randomly set the value of the e_question field so the Conversation Engine can see it when showing the conversation to the respondent.

Keywords

Keywords are another way to change the conversation flow when encountered.

When a respondent replies with a keyword associated with the conversations, the keyword can stop the current conversation and jump to another conversation. For example, if the respondent sends "help" your program might have a conversation that tells the respondent how to get help, and how to opt-out of further conversations.

To opt-out and stop all future conversations, text STOPP. To talk to an agent, call ###-###-####.

In the example above STOPP is a special opt-out keyword that immediately stop the conversation and remove the respondent from all future conversation invitations. You can define the opt-out keywords for your application.

Keywords can also tell the system to skip a question when the respondent does not answer it after some time has passed.