Survey templates serve to standardize the process of a campaign. Answers collected from surveys can be stored for later use, helping to build a profile on prospective clients.

Dashboard users can add survey templates for their agents by navigating to the Dialer tab and clicking Surveys from the dropdown options. Click the blue button in the righthand corner of the Surveys page to +Add Survey, or edit an existing template by clicking the blue pencil icon next to an item on the list.

Survey Answers

For each question added to the template, the user will select an answer type. This answer type dictates the choices available for the prospect to respond with, as well as if the answer is a free response or something with limited response options.

Short text (max 255 characters)

Enter a short answer

Long text (max 65535 characters)

Enter a longer answer

Checkbox

A box to check or leave unchecked, as for a "yes/no" answer.

Radio Options

Series of answer options where you can click the accompanying button to choose one. Better for limited answer options, as this type can take up vertical space on a phone screen.

Select

Series of options which can be expanded from a dropdown list, or searched for by typing into the box. Better to use when a question will have more options to choose from, as it is space saving.


Storing Survey Answers

One template can be used for multiple campaigns. Within each campaign, contact answers to survey questions for that campaign will be stored with other aggregated data, like the campaign statistics. This data can be logged for internal tracking purposes, or sent to a third party, like a CRM, using CloudTalk's Workflow Automation feature.

Automation Setup

Example Goal:

  • Forward survey responses from an ongoing campaign to a separate CRM or management system account.

Steps:

  1. For this example, we should set up the automation before the start of our campaign, so that it can run in real time as the campaign is taking place. Start by defining a trigger. Our trigger will be a call ending. Under Object, we select call. For Action, we select ended.

  2. This automation will require us to set up some conditions. The first condition will ensure that dropped calls will not be counted as a triggering event. Click into the box labeled Property and refer to the sidebar box labeled Useful data for your Workflow. From the options in this sidebar, choose talking_time. You should see the Property box autofill with the dynamic value event.properties.talking_time. Select the Operand is greater than. For Value, enter 10. We have just established a logical statement which requires our automation to only trigger when an ended call had a talk time greater than ten seconds, allowing some buffer time for connection lag.

  3. It will be necessary to make another condition, to require that the automation only enacts for the specific campaign we want. For Property, click the + icon next to dialer_data, which may appear near the bottom of the Useful data for your Workflow box.

    This will expand campaign-related keyword options. Next to the value campaign, there is another + icon to expand further options.

    From these, choose the the dynamic value name. You should see the Property box autofill with event.properties.dialer_data.campaign.name . Operand -> is equal to. Clicking into the Value box, enter the name of the campaign you wish to source from, including proper caps or lowercase and any spaces. In the picture below, our campaign's name was "My Campaign October".

  4. The next step is to choose an action which will happen at the end of any call from "My Campaign October" with a talk time greater than ten seconds. As an Action type, we choose to make an API request. For this kind of action, some information will be needed from the CRM system we want to send this information to. The first piece of info necessary is the Endpoint, which will look something like the fake example in the picture below. It will be an API or token URL. As a Method, we choose POST for our example, as we will be sending or "posting" new data to the desired endpoint.

  5. There are two subsections: one named Headers, representing metadata of the request and one named Values, representing the request body. You can learn more about these subsections by reading about Workflow Action types. Within the Headers and Values subsections, there can be multiple [Key, Value] pairs. In our example, we want to keep things a bit simple. Under the Values subsection, we will enter a Key>survey_answers and choose the dynamic value survey_answers under dialer...+ from the Useful data for your Workflow box. Our Value box should autofill with

    {{ event.properties.dialer_data.survey_answers[0] }}.

  6. From this point, we will need to make a small edit to the dynamic value which has populated. The [0] at the end of event.properties.dialer_data.survey_answers[0] represents an index of the first or "0" item in our survey. We could change the 0 to a different index value which corresponds to the question in the survey we would like to send, if there is only one desired. Or, in the case we would like to return all answers in the field, we would use the following: {{ event.properties.dialer_data.survey_answers | dump }}. This represents the parent object containing all answers, which will be transformed into readable format. Refer to the Jinja templating language docs for more info on using filters like these.

    Note:  Additional entries in the Headers or Values subsections will
    vary depending on the requirements expected on the side of the
    receiving API. For example, there are usually API Keys or other
    tokens expected for authorization in the Headers subsection, as well as a Header for content type.

Once we save and set our Workflow to active, we will have accomplished our goal of forwarding survey answers to another system automatically, a process which we can later edit and toggle off or on at our choosing.


Related Links

What is a Trigger

Did this answer your question?