Configure the chat survey

Set up a customer-facing survey deliberately, test its timing and wording, and verify the response path before deployment.

Use the Chat Survey area to collect structured feedback or information during the Agent experience. Keep the survey short, purposeful, and aligned with how the team will use its responses.

An Agent combines instructions, customer-facing interface settings, Knowledge, catalog data, and optional tools. A reliable setup is tested with realistic customer questions before deployment. Tests should cover expected answers, missing information, product scenarios, escalation, and any optional interaction that the team has enabled.

Before you begin

Access: Open Agent configuration with permission to edit the chat survey.

  • Define the decision or follow-up the survey should support.
  • Choose the Agent and target audience.
  • Confirm who will review or act on responses.

Work in the smallest owning area described below and keep the current customer-facing state available while you prepare the change. Before clicking any final action, confirm the active company, Agent, store, language, and market shown in Humind. A missing control can indicate read-only access or a capability that is not configured for this company. In that case, record the intended task and ask an administrator to review the exact permission or dependency. Do not bypass the boundary by sharing an account, copying data into another area, or promising a capability that the workspace does not expose.

Step-by-step workflow

  1. Define one clear objective

    Write the survey objective before adding fields. A satisfaction check, qualification question, and support intake have different timing and should not be combined without a reason.

    • Name the owner of collected responses.
    • Remove any question that has no planned use.
  2. Configure concise customer wording

    Use familiar language, explain what is required, and avoid asking for information already available in the conversation. Keep answer choices distinct and complete.

    • Review wording as a first-time customer.
    • Avoid collecting sensitive data that the workflow does not require.
  3. Set the intended presentation

    Configure when the available survey should appear and how customers complete or skip it. Match the experience to the surrounding conversation rather than interrupting a critical task.

    • Check required and optional fields.
    • Confirm the completion message or next step is clear.
  4. Test before deployment

    Run the survey through the available test experience and then on the deployed channel. Verify keyboard, mobile, completion, and abandonment behavior.

    • Submit representative answers.
    • Confirm the team can find or use the resulting information as intended.

Important limits and operating notes

  • A survey should not promise a follow-up that the team cannot deliver.
  • Minimize personal information and follow company data policies.
  • Long surveys reduce completion and can obstruct the conversation.
  • A saved survey still needs channel testing in the intended Agent experience.

Verify the result

  • Every question supports the stated objective.
  • Required fields are clearly distinguishable.
  • The survey can be completed and skipped as intended.
  • The responsible team knows how responses will be handled.

Keep a short record of what you tested, which customer scenario you used, and what changed. This makes later troubleshooting more precise and helps another teammate reproduce the result without relying on memory.

Troubleshooting

The survey does not appear

Confirm it is configured for the same Agent and scenario being tested, then check the saved state and deployed channel. Retest with a new conversation to avoid prior session state.

Customers abandon the survey

Review timing, length, required fields, and unclear answer choices. Remove low-value questions and retest rather than adding more explanatory text around an overloaded form.

Related guides

Was this article helpful?