Implementing Post-Interaction CSAT Survey Delivery with Adaptive Question Branching Logic

How-To-Articles
1

Implementing Post-Interaction CSAT Survey Delivery with Adaptive Question Branching Logic

What This Guide Covers

This guide details the architectural implementation of dynamic Customer Satisfaction (CSAT) surveys within Genesys Cloud CX, utilizing Architect Flow logic to branch questions based on real-time interaction metadata. You will configure a system that delivers targeted survey content via SMS or Email, where subsequent questions adapt dynamically based on the respondent’s previous answers and historical customer data, rather than presenting a static linear form.

Prerequisites, Roles & Licensing

  • Licensing: Genesys Cloud CX 1, 2, or 3 license with Engagement add-on (for SMS/Email delivery) and Workforce Engagement Management (WEM) is recommended for downstream analytics correlation.
  • Permissions:
    • Architect > Flow > Edit
    • Survey > Survey > Edit
    • User > User > Edit (to assign permissions to the service account if using API triggers)
    • Telephony > Trunk > Edit (if using voice delivery fallback)
  • External Dependencies:
    • A configured SMS Provider (e.g., Twilio, Bandwidth) or Email Provider (e.g., SendGrid, Amazon SES) within Genesys Cloud.
    • Access to Customer Data (via CRM integration or Data Connector) for personalization.
  • OAuth Scopes: survey:read, survey:write, architect:flow:edit.

The Implementation Deep-Dive

1. Survey Design with Dynamic Question Logic

The foundation of an adaptive survey is not the delivery mechanism, but the survey definition itself. Static surveys yield high abandonment rates because they force irrelevant questions on the respondent. We utilize Genesys Cloud’s native Survey Builder to define the question pool, but the branching logic is handled in Architect to prevent the overhead of client-side evaluation in the survey widget.

The Trap: Hardcoding Branching in the Survey Builder

A common misconfiguration is attempting to handle complex branching entirely within the Survey Builder using conditional visibility rules. While Survey Builder supports simple “If Answer = A, Show Question B” logic, it lacks access to external context (e.g., CRM status, previous ticket history, or real-time sentiment scores). Relying solely on Survey Builder logic forces you to create a monolithic survey definition that becomes unmanageable as business rules evolve. Furthermore, Survey Builder conditional logic evaluates only on the client side, which can cause latency issues on low-bandwidth mobile devices.

The Architectural Solution: Decoupling Content from Logic

We separate the content (the questions) from the logic (which questions to show). The Survey Builder defines the individual questions and their types (Rating, Text, Multiple Choice). Architect Flow determines which subset of questions is included in the final survey payload sent to the respondent.

Step 1.1: Define the Question Pool
Create a survey in Admin > Survey > Surveys. Do not enable “Required” on any question at this stage; we will enforce completion logic in the delivery flow. Create the following question types:

  1. Q1_Score: Rating (1-5 stars).
  2. Q2_Detail: Text Area (Why did you give this score?).
  3. Q3_NPS: Rating (0-10 Net Promoter Score).
  4. Q4_Issues: Multiple Choice (Select issues encountered).
  5. Q5_Routing: Single Choice (Do you want to speak to a manager?).

Step 1.2: Configure Survey Metadata for API Consumption
Ensure the survey is published. Note the Survey ID. We will use this ID to instantiate the survey in Architect, but we will modify the questions array in the request body to include only the questions determined by our branching logic.

2. Architect Flow Construction for Adaptive Branching

The core intelligence resides in the Architect Flow. This flow executes immediately after the interaction ends (or via a scheduled trigger). It evaluates customer context and initial feedback to construct a personalized survey experience.

The Trap: Synchronous Blocking of Agent Wrap-Up

A critical error is triggering the survey delivery synchronously within the agent’s wrap-up flow. If the survey API call fails or times out, it blocks the agent from returning to Available status. This creates a cascading delay in workforce availability. Always offload survey delivery to an asynchronous process or use a non-blocking “Send Email/SMS” node with error handling that logs failures without halting the agent workflow.

Step 2.1: Trigger and Context Gathering

We trigger the flow via a Interaction Event (End of Interaction) or a Scheduled Event (e.g., 15 minutes post-call to allow emotion to settle).

  1. Get Interaction Details: Retrieve the interaction.id and participant.id.
  2. Get Customer Profile: Use a Data Connector or CRM Lookup node to fetch customer attributes (e.g., is_VIP, last_ticket_status, historical_csat).
  3. Evaluate Branching Criteria:
    • If is_VIP is true, skip NPS (Q3) to reduce friction; focus on resolution quality.
    • If last_ticket_status is “Escalated”, include Q5 (Routing to Manager).
    • If historical_csat < 3, include Q4 (Issues) to identify systemic problems.

Code Snippet: Architect Expression for Logic Evaluation
Use the Set Variable node to store the list of question IDs to include.

// Expression in Set Variable Node: questions_to_include
[
  "Q1_Score", // Always included
  // Conditional inclusion based on VIP status
  if(lookup_customer.is_VIP, [], ["Q3_NPS"]),
  // Conditional inclusion based on escalation history
  if(lookup_customer.last_ticket_status == "Escalated", ["Q5_Routing"], []),
  // Conditional inclusion based on low historical score
  if(lookup_customer.historical_csat < 3, ["Q4_Issues"], [])
].flatten()

Step 2.2: Dynamic Survey Payload Construction

Genesys Cloud does not have a native “Create Survey Instance with Subset of Questions” API endpoint that accepts a dynamic question list directly in the trigger. Instead, we must use the Survey API to create a survey response or utilize the Engagement API to send a message containing a survey link with query parameters that filter the questions.

However, the most robust method for true adaptive branching is to use the Survey API to create a Survey Template instance and then inject the questions via a custom web form hosted on your own domain, OR use Genesys Cloud’s SMS/Email Engagement with a deep link that passes a survey_id and question_set_id parameter.

Note: Genesys Cloud’s native survey builder does not support dynamic question injection via API at the time of delivery for standard surveys. To achieve true adaptive branching, we must use a hybrid approach:

  1. Option A (Native Limitation Workaround): Use multiple distinct surveys (e.g., Survey_VIP, Survey_Escalation) and route the user to the correct one. This is rigid but reliable.
  2. Option B (Advanced/Custom): Host a custom HTML/JS survey form on your own secure domain. Use Genesys Cloud to send an SMS/Email with a unique token. Your custom form calls the Genesys Cloud Survey API to submit results, but the display of questions is controlled by your frontend logic based on the token’s metadata.

For this guide, we assume Option A is the baseline for stability, but we will demonstrate Option B as the “Masterclass” implementation because it allows true adaptive logic.

Step 2.2.1: Generating the Survey Token
Use the Create Survey Token API to generate a secure, time-bound link.

HTTP Method: POST
Endpoint: /api/v2/surveys/{surveyId}/tokens

JSON Body:

{
  "expiresAt": "2023-12-31T23:59:59.000Z",
  "metadata": {
    "customerId": "{{customer.id}}",
    "interactionId": "{{interaction.id}}",
    "questionSet": "VIP_ESCALATION"
  }
}

The Trap: Token Exposure and Reuse
Storing the survey token in plain text in the interaction history or logging it in debug mode creates a security risk. An attacker could reuse the token to submit fraudulent survey responses. Always set a short expiresAt (e.g., 24-48 hours) and ensure the token is used only once by validating the customerId on the server side before accepting the submission.

Step 2.3: Delivery via Engagement (SMS/Email)

Use the Send SMS or Send Email node in Architect.

  • SMS: Include the shortened URL with the survey token.
  • Email: Embed the survey token in a personalized email template.

Code Snippet: Email Template Variable

<p>Hi {{customer.firstName}},</p>
<p>Please share your feedback here: <a href="https://your-domain.com/survey?token={{survey_token}}&set={{questionSet}}">Take Survey</a></p>

3. Handling Adaptive Responses and Closed-Loop Management

The survey is not just a data collection tool; it is a trigger for operational action. The adaptive logic must extend to the response handling.

The Trap: Ignoring Negative Feedback Latency

A common failure mode is collecting CSAT data but failing to act on negative scores in real-time. If a customer gives a 1-star rating, the ticket is often already closed. The system must re-open the ticket or create a new “Service Recovery” task for the Quality Assurance team.

Step 3.1: Real-Time Response Processing

Configure an Architect Flow triggered by Survey Response Received.

  1. Get Survey Response: Retrieve the submitted answers.
  2. Parse Adaptive Logic:
    • If Q1_Score <= 2: Trigger “Service Recovery” workflow.
    • If Q5_Routing == “Yes”: Create a case in the CRM assigned to the Team Lead.
  3. Update CRM: Push the survey response to the customer record for longitudinal analysis.

Code Snippet: API Call to Update CRM Case
HTTP Method: PATCH
Endpoint: /api/v2/cases/case/{caseId}

JSON Body:

{
  "status": {
    "id": "open",
    "name": "Open"
  },
  "priority": {
    "id": "high",
    "name": "High"
  },
  "description": "Customer submitted negative CSAT (Score: {{survey_response.Q1_Score}}). Requires immediate follow-up."
}

Validation, Edge Cases & Troubleshooting

Edge Case 1: Survey Link Expiration Before Completion

The Failure Condition: The customer receives the SMS, opens the link, but does not complete the survey within the token expiration window. They return the next day to find a “Invalid Token” error.
The Root Cause: The expiresAt timestamp in the token generation step was set too aggressively (e.g., 1 hour).
The Solution: Set expiresAt to at least 7 days for email and 24 hours for SMS. Implement a “Token Refresh” logic in your custom survey frontend: if the token is expired, call a backend API to generate a new token using the same customerId and interactionId, ensuring idempotency (only one survey submission per interaction).

Edge Case 2: Duplicate Survey Deliveries

The Failure Condition: A customer receives two survey links for the same interaction.
The Root Cause: The Architect Flow triggering the survey is not idempotent. If the interaction end event fires twice due to network retries, or if the flow is triggered by both “Interaction End” and “Wrap-Up Complete,” duplicate tokens are generated.
The Solution: Add a Data Lookup node before the “Create Survey Token” step. Check if a survey token has already been created for this interactionId in a database or Genesys Cloud Custom Attribute. If a token exists, skip creation. Alternatively, use a Set Variable node to store a flag survey_sent=true in the interaction metadata and check this flag on subsequent runs.

Edge Case 3: Mobile Device Rendering Issues

The Failure Condition: Customers on mobile devices report that the survey form is difficult to read or buttons are unclickable.
The Root Cause: The custom survey frontend is not responsive, or the Genesys Cloud native survey widget is not optimized for the specific SMS provider’s click-through behavior.
The Solution: Ensure your custom survey HTML uses viewport meta tags and responsive CSS. If using Genesys Cloud’s native survey, test the delivery on multiple mobile operating systems (iOS, Android) and SMS clients (iMessage, WhatsApp, Standard SMS). Consider using Deep Links to open the survey directly in the mobile browser rather than an in-app browser, which may have restricted JavaScript capabilities.

Official References