What is CSAT survey software?
CSAT survey software collects and reports customer satisfaction responses. It commonly asks about a specific experience, such as a support interaction, delivery or onboarding step. A useful buying decision looks beyond the rating widget to the context, analysis and follow-up your team needs.
For a service business with recurring relationships, the central question is whether staff can move from a reported problem to a reviewed action and a later check. That may require connecting survey responses with permitted customer and service records. It does not mean every response must identify a person, or that a low rating establishes why a customer will leave.
This guide helps customer success, service operations and research teams evaluate a CSAT workflow. Use the requirements and worked example to test a product with your own service process rather than relying on a generic dashboard demonstration.
Define the satisfaction measure first
Decide what experience the question refers to. “How satisfied were you with the support you received today?” is different from “How satisfied are you with our service overall?” Both can be useful, but their results should not be combined as if they measure the same thing.
Write down the question, response options and calculation rule. For a five-point scale from very dissatisfied to very satisfied, one common CSAT calculation is the number selecting satisfied or very satisfied divided by the number of valid satisfaction responses, multiplied by 100. Some systems use different scales or summary calculations, so check the actual rule before comparing results.
Keep neutral answers distinct from missing answers. If your rule uses the top two categories, a neutral answer is a valid response that is not counted as satisfied. Someone who did not answer the question is not a neutral respondent. Report the number of valid answers alongside the score.
Add a focused optional question such as “What most influenced your rating?” or “What could we improve about this interaction?” The response may explain a specific experience, but it remains the respondent's account. Investigate it alongside appropriate service evidence before making a claim about a root cause.
What features should CSAT software include?
Scroll horizontally to see all columns →
| Requirement | Why it matters | Demonstration test |
|---|---|---|
| Relevant distribution | Only people who experienced the touchpoint should be asked to rate it. | Show eligibility, delivery channel, timing and how duplicate invitations are controlled. |
| Clear question and scale management | Changed wording or scales can break a trend. | Change a question and show how the earlier version remains identifiable. |
| Interaction context | A rating needs a clear service event, date and channel. | Use one customer with two different interactions and keep the responses distinguishable. |
| Comment analysis | The team needs to understand reported experiences without losing source evidence. | Review positive, critical, mixed and ambiguous comments against defined themes. |
| Coverage and exclusions | The score represents respondents, not everyone served. | Show eligible interactions, invitations, valid answers and excluded records. |
| Follow-up ownership | A finding needs a response process beyond appearing in a chart. | Record a reviewed issue, responsible person and next review. |
| Access and portability | Survey and service evidence may have different permissions. | Test viewer roles and export a useful dataset with its definitions. |
Prioritize these requirements according to your workflow. A simple post-delivery survey does not necessarily need the same configuration as a multi-location service program. Ask which features are standard, which require another system and which need implementation work.
Choose the trigger and timing deliberately
Ask when the customer can reasonably assess the experience. A support interaction may be assessed soon after resolution. A delivery may need confirmation that the customer received it. An onboarding step may need enough time for the customer to try what was introduced.
“Immediately” is not a universal answer. A survey triggered before an issue is resolved can measure frustration at the timing rather than the completed experience. A much later invitation may make it harder to remember which interaction is being rated. Define and test the intended window.
Check what happens when an interaction reopens, is canceled or is transferred. Does the workflow send another invitation? Does a corrected status change the reporting period? Keep the invitation date, interaction date and response date available for analysis.
Control the burden on repeat customers. Someone contacting support several times in a short period may receive too many requests if every event triggers a survey. Decide how frequency limits affect sampling and reporting. Do not describe a sampled set of invitations as the complete customer population.
Connect records without mixing people and interactions
Use a stable interaction identifier where available. If the design permits identified feedback, connect it to the appropriate contact or account identifier. These are different entities: one account may have multiple contacts, and one contact may have many service interactions.
A customer who submits three CSAT ratings contributes three interaction responses, not three distinct customers. Decide whether a report measures satisfaction per interaction, per responding customer or another defined unit. The choice affects the result when some customers contact the service much more often than others.
Keep anonymous feedback separate from identified follow-up. If you promise anonymity, do not quietly attach the response to an account through hidden fields. If a participant requests contact, explain how their information will be used and who will receive it.
Useful context may include service type, channel, location and time. Collect only what the analysis and response process need. Keep sensitive support notes or documents under their appropriate access rules rather than copying them into every survey report.
Worked example: calculate the score and its coverage
Consider a fictional month with 500 eligible service interactions. The team sends 400 survey invitations and receives 100 valid satisfaction answers. Seventy-five respondents choose satisfied or very satisfied on the agreed five-point scale.
- CSAT is 75 divided by 100, multiplied by 100: 75%.
- The response rate among invited interactions is 100 out of 400: 25%.
- The invitation coverage is 400 out of 500 eligible interactions: 80%.
These measures answer different questions. “75% CSAT among 100 respondents” does not establish that 75% of all customers were satisfied. Investigate why 100 eligible interactions were not invited and whether responders differ from the people who did not respond.
Suppose 60 respondents also leave comments, and 18 mention billing confusion. That is 18 of 60 commenters, or 30% of commenters. It is not 30% of all eligible interactions. If the coding allows several themes per comment, theme percentages may sum to more than 100%; explain that rather than forcing each response into one topic.
A useful report shows the score, the relevant counts, the theme evidence and the proposed next step together. It should let a reviewer reproduce the figure and understand what the evidence does not establish.
Analyze comments as evidence, not automatic diagnoses
Define a small set of themes that help the team make service decisions. Distinguish the topic from the sentiment: “billing” might describe either a clear invoice or a confusing correction. A topic count alone does not tell you which experience occurred.
Retain the source passage behind a coded theme for authorized review. Include mixed and contradictory evidence. A response can praise an agent while criticizing the time it took to resolve the issue; forcing it into a single positive or negative label loses that distinction.
AI can assist with proposed themes and summaries, but evaluate it on the range of language your customers use. Test spelling variations, short answers, ambiguous references and relevant languages. Keep an option for an unclear or unclassified response and a reviewer who can correct the interpretation.
Rank issues using frequency, seriousness, evidence and the ability to act. A frequent inconvenience and a less frequent service failure may need different responses. Do not infer that the theme most common among low ratings is necessarily the cause of the low score or the largest commercial risk.
Compare periods and locations fairly
Before comparing CSAT, check the question, scale, eligibility rule, invitation timing and channel. A location surveying only completed cases is not directly comparable with one surveying all contacts. A new invitation method may change who responds even if service quality is unchanged.
Use the same definitions for shared reporting while allowing local teams to ask additional questions. Record the common fields and calculations in a data dictionary. If local measures cannot be mapped without changing their meaning, report them separately.
Show response counts with percentages and avoid ranking small groups as if their results were precise. Examine whether changes in service mix explain part of a trend. A month with more complex issues may differ from one dominated by routine requests.
For ongoing customer relationships, later feedback can provide useful context after a response or intervention. Keep the sequence clear, but avoid saying the intervention caused the change merely because a later rating improved. Other events and differences in who answered may matter.
Design the response process before launching
Decide which submissions require individual review, which contribute to a periodic theme review and which need another established service process. Assign ownership and realistic review expectations. A collection tool does not become an operational response system simply because it can display a low score.
For identified feedback with appropriate permission, an owner may contact the customer to understand the issue. Keep the service response distinct from trying to change a rating. For anonymous feedback, act on the process finding and communicate the change through an appropriate group channel.
Record the issue, evidence, action, responsible person and review date. If the team changes an invoice explanation, for example, decide how it will check that the change was implemented and whether later comments still describe the same confusion.
Close the internal review even when no immediate change is made. A documented decision and reason help the next team understand the history. Leave unresolved findings visible instead of marking every generated summary as an action completed.
Evaluate configuration, integrations and total effort
Map the handoffs before selecting software. Which system owns the customer identifier? Which event triggers the invitation? Where does a reviewed issue go? How does the outcome of the service response return to the evidence workflow?
Ask suppliers to demonstrate those connections rather than relying on an integration logo. Check the fields exchanged, update timing, error handling and correction process. A manual import can be appropriate for a pilot if it is clear who owns it and what ongoing work it creates.
Include setup, maintenance, reviewer time and support in the cost comparison. Check which changes your team can make itself and which require specialist help. Review the proposed plan limits for responses, analysis and integrations rather than assuming every feature shown is included.
Test an export with the information needed to reproduce a report: question version, score, reporting period, relevant identifiers, exclusions and theme definitions. Verify access to source evidence as well as the ability to download a chart.
Where Sopact fits in a CSAT workflow
Sopact is worth evaluating when recurring feedback needs to be reviewed alongside customer history, service context and other evidence. The practical fit is a collection, analysis and governance workflow that your team can maintain, with findings connected to a responsible follow-up.
Keep the support or customer system that already runs the service well. Test how the proposed Sopact setup receives permitted data, supports reviewed analysis and returns useful findings. Confirm the actual integration and access configuration; do not assume a native trigger, automated case routing or a particular support-system connection is included.
Explore the customer experience workflow →
Build the complete customer feedback process in the Academy →
Read the wider customer feedback management guide →
Frequently asked questions
How do you calculate CSAT?
Define the satisfied response categories, divide those responses by all valid satisfaction answers and multiply by 100. For a common five-point scale, the top two categories count as satisfied. Verify the rule in the specific survey and software.
Is CSAT the same as NPS?
No. CSAT asks about satisfaction with a defined experience or service. NPS uses a recommendation question and its own scoring rule. Neither measure alone establishes loyalty, churn or the cause of a customer's experience.
Does every response need a customer identity?
No. Identified feedback can support permitted follow-up and history, while anonymous feedback can inform process improvement. Choose the design deliberately and make the participant explanation accurate.
When should a CSAT survey be sent?
When the customer can reasonably assess the specified experience. Test the trigger and timing for the service, including reopened or canceled interactions. Keep the invitation window consistent enough for the comparisons you intend to make.
What should a pilot demonstrate?
One complete cycle: eligible interaction, invitation, rating and comment, reviewed finding, responsible action and later review. Include a missing response, repeated customer and corrected record.
Choose your next step
King Center
Related practice: bringing open feedback into a reviewed program view. The story is about participant feedback, rather than CSAT scoring.
Read the customer story →