To improve CSAT, identify why customers are dissatisfied with a specific experience and give the responsible team a practical way to change it. That usually involves agent knowledge and authority, a clearer support workflow, suitable technology and a feedback loop that checks what happened afterward.
CSAT is evidence from respondents, rather than a complete verdict on an agent or a forecast of business growth. This guide explains how to move from a score to a supported improvement decision, without changing survey eligibility to make the headline look better. It also covers satisfaction strategies that reach beyond a single conversation: proactive updates, fair service recovery and agreed customer goals.
Define the CSAT score before trying to improve it
Name the experience being rated: a conversation, the resolution of an issue, onboarding or a purchase. These are different scopes. A customer might appreciate the agent while remaining dissatisfied with the product failure or an unresolved problem. A relationship recommendation score answers a different question again.
For a five-point question with 1 meaning very dissatisfied and 5 meaning very satisfied, define 4 and 5 as favorable responses. Qualtrics documents this top-two-response calculation:
CSAT = favorable valid responses ÷ all valid responses to the question × 100. Keep neutral ratings in the denominator. Publish the scale, question, eligibility, trigger, reporting dates and duplicate-response rule. Another scale or favorable threshold needs its own definition.
Also report delivered invitations and valid responses. Survey response rate = valid responses ÷ delivered eligible invitations × 100 for a program that allows one response per invitation. If your system counts invitations differently, reconcile its definition before comparing reports.
Illustrative baseline: In one week, 200 eligible interactions receive delivered invitations. Eighty provide valid ratings, and 64 rate the interaction 4 or 5. CSAT is 64 ÷ 80 × 100 = 80%; the response rate is 80 ÷ 200 × 100 = 40%. The score describes the 80 respondents, rather than all 200 invited customers.
Keep the distribution and optional comments. A customer rating 3 is neutral on this scale, not necessarily an unhappy customer. Review the lower ratings directly and ask what was unresolved instead of treating every non-favorable response as the same complaint. Our satisfaction metrics guide covers complementary measures.
Find the service problem behind the rating
Review a manageable set of cases across favorable, neutral and unfavorable responses. Include the original request, attempted steps, handoffs, policy decisions, outcome and comment. Do not inspect only the shortest reply or the last agent’s message.
Separate an observation from an explanation. “The customer repeated the account details after a transfer” is observable. “The agent did not care” is an interpretation that needs investigation. The GOV.UK research analysis method distinguishes observations, grouped findings and possible actions.
| Finding to investigate | Potential improvement area | Evidence to inspect |
|---|---|---|
| Advice did not fit the customer’s setup | Agent knowledge and training | Product version, permissions, instructions and previous attempts |
| A routine remedy needed several approvals | Agent authority and policy | Approval rules, actual decision and waiting |
| The customer repeated the issue after transfer | Routing and handoff process | Information captured, receiving team’s access and ownership |
| The fix did not address the blocked task | Diagnosis and outcome verification | Expected result, attempted fix and later same-issue contact |
| A product defect or unavailable option remains | Product or policy ownership | Confirmed limitation, impact and responsible team’s next action |
| The customer could not tell what would happen next | Proactive communication | Promised updates, confirmed status and whether updates arrived as committed |
| A failure was acknowledged but its impact remains | Service recovery | Actual consequence, remedy offered and whether it was delivered |
| The customer is not reaching an intended goal over time | Customer success management | Agreed milestones, dependencies and customer-confirmed progress |
These are hypotheses for review, not automatic explanations for a low score. Serious problems deserve attention even if few respondents report them. Prioritize using impact, recurrence, confidence and the ability to act, then name an owner outside support when the cause sits elsewhere.
Empower agents with usable knowledge, practice and authority
A knowledge base should help an agent choose an accurate next action. Record the customer’s goal, environment, symptoms, resolution and important exceptions. The KCS guidance on requester context emphasizes the customer’s words and environment, which can make guidance easier to find and apply.
Assign owners and review dates to important instructions. Remove conflicting versions through the approved documentation process and let agents flag gaps. A larger article count is not proof that answers are useful.
Use written steps, screenshots or short recordings according to the task. A video is useful when a sequence is difficult to describe, but keep an accessible alternative and the prerequisites visible. Text remains appropriate for search, quick reference and actions that customers need to copy.
Fit guidance to the customer’s context
Personalization should make an answer more useful, not just more familiar. Match guidance to the customer’s role, product edition, previous attempts and stated goal. Start with data you already need for the interaction, ask for more only when it changes the next step and do not infer sensitive circumstances to make a message feel personal.
Illustrative example: A user cannot connect an integration because only an administrator can authorize it. Send that user the process for requesting access, and send the administrator the authorization steps. Sending everyone the same configuration guide misses the actual obstacle. Check whether customers in the intended role completed the task, not whether they clicked more.
Practice the situations that create dissatisfaction
Use sanitized cases to rehearse confirming the goal, explaining a limitation, giving a complete handoff and checking whether a solution worked. Combine product updates, role-playing and peer coaching. Have agents demonstrate the action rather than only mark training complete. Pair newer agents with an available mentor and revisit guidance after product or policy changes.
Review what prevented good work: missing access, unclear guidance, conflicting promises or unavailable specialist help. Coach observable behavior that the agent can change. Recognize careful diagnosis and appropriate escalation as well as friendly communication.
Give autonomy a clear decision boundary
Document which remedies and account changes agents may authorize, what evidence they need and who handles exceptions. A broad instruction to “do whatever makes the customer happy” leaves important decisions unclear and lets the customer move between people without a decision. A local budget for making things right can be useful, but its amount and eligibility should come from actual policy and financial authority.
Provide examples of allowed decisions and escalation conditions. Check whether agents have the permissions required to carry them out. Measure decision accuracy and approval delays together; expanding authority without safeguards can create a new quality problem.
Work design also matters. HSE’s Management Standards cover demands, control, support, relationships, role and change. Use discussion with staff to identify barriers; a request to “be more empathetic” cannot solve persistent overload or an unclear role.
Remove support friction without hiding unfinished work
Follow a real case from the customer’s first attempt to find help through the eventual outcome. Include forms, queues, transfers, specialist investigation, updates and reopening. A ticket marked solved is not enough to establish that the customer completed the task.
For each handoff, define required context, the next owner and the update commitment. Transfer the relevant goal, symptoms, environment, evidence and attempted steps. Check that the receiving person can access the material and understands the request.
The same applies across channels. Opening email, chat, phone and social support without connected records or dependable coverage can create more handoffs and uncertainty. Choose channels from customer needs and staffing capacity, state their availability and response windows, and test a cross-channel handoff end to end, including whether attachments and private notes reach the right audience without exposing confidential context publicly. When tools cannot connect records automatically, document a reliable manual process. A smaller set of well-supported channels may be the appropriate starting point.
Routing rules can use issue type, required expertise and availability. Test ambiguous requests and incorrect routing, and provide a reassignment route. A keyword alone may not identify the correct owner; a message mentioning billing might report a permissions problem.
Prioritize using confirmed urgency and impact under your service policy. A broad outage, an important blocked task and a routine question need different handling. Account importance can inform agreed service commitments, but should not obscure a serious safety, privacy or access issue.
Make response and update expectations explicit. When a dependency changes, communicate the new status instead of silently missing a commitment. Evaluate response and resolution time alongside accuracy, repeat contacts and the number and age of unresolved cases.
Illustrative change: For integration requests, add the product edition, user role and previous attempts to the handoff record. Pilot it with the relevant queue, review whether specialists still repeat those questions and verify that unnecessary private information is not collected. This is a proposed experiment, not a reported CSAT gain.
Communicate proactively about confirmed information
A proactive update should reduce uncertainty about something relevant: a delivery delay, known incident, changed workflow or unfinished investigation. It need not predict every future problem. Identify the affected audience and explain confirmed impact, available options and the next update. Distinguish a verified workaround from an untested suggestion, and state plainly when the cause or recovery time is unknown.
Illustrative incident message: “The export service is currently delayed for [affected scope]. Existing exports remain available. We are investigating and will post the next update by [time and time zone], even if the investigation continues.” Use only commitments and facts the owner has confirmed.
Coordinate messages across support, product and account teams, stop reminders when a task is complete and avoid turning every update into a promotion. Check whether promised updates were delivered and whether customers understood the next action. Our proactive service guide covers the broader workflow.
Recover from service failures fairly
After a failure, address both the practical consequence and the customer’s need for a clear response. Acknowledge what happened, take responsibility for the next step and offer a remedy your team is authorized to provide. Ask what is still blocked before selecting compensation: a discount does not restore a missing document or fix an incorrect configuration.
Illustrative example: A promised delivery was missed. Confirm the current status, explain an available replacement or refund route under the actual policy and set a follow-up commitment. A generic apology should not stand in for the unresolved action.
Then investigate the failure with the responsible owner and update instructions, monitoring or handoffs where the evidence supports a change. Do not assume that a strong recovery makes customers more loyal than if the failure had never happened. Review whether remedies were delivered, whether similar failures recurred and the cost and fairness of exceptions. Our complaint handling guide develops that process.
Agree on customer goals for ongoing relationships
For ongoing services or complex products, satisfaction also depends on progress toward the outcome the customer wants. Agree on that outcome, the milestones that show progress, dependencies and the people responsible. Increased product use is not always the same as greater value.
Choose a service model the team can sustain: named ownership for complex accounts, focused check-ins at important milestones, or guidance with a clear help route for simpler needs. Coordinate open support cases and product limitations so success messages do not conflict with the customer’s current experience. For example, if an account wants its first usable monthly report, the milestone is an accurate report reviewed by the relevant stakeholder, not a login to the reporting screen. Avoid treating an untested health score as a prediction that an account will renew.
Use technology to support the chosen change
Start with the capability the team needs. Templates can support common explanations, automation can route a defined request and a recording can clarify visible behavior. Check exceptions, maintenance and access before adopting a tool across every case.
Screendesk supports screen recordings and live video workflows. For a visual issue, an agent can ask for focused context or provide a walkthrough when appropriate. Give another help format when video is unsuitable and avoid capturing unrelated sensitive information. The tool does not establish the diagnosis or guarantee a better satisfaction score.
AI may help summarize cases, propose draft answers or identify themes. Verify that the content matches the current product, the customer’s context and approved policy. The NIST generative AI risk profile describes the risk of confidently false output, so review important claims and source references.
An inferred sentiment or predicted satisfaction score is different from survey CSAT. Label it separately, disclose the model and coverage, and validate it against reviewed cases. Processing every captured interaction does not mean every customer experience was captured, and automated analysis does not remove bias.
For customer-facing automation, test failure, correction and human-help routes. Keep an owner for inaccurate answers and misrouted requests. Review customer outcomes and transferred workload rather than equating more automated conversations with improvement.
Close the feedback loop on cases and recurring problems
Offer an optional reason question and a way to request follow-up. Keep wording neutral: Pew Research Center explains how question wording and order affect answers. Do not ask customers to reward the agent or imply that criticism harms someone. Our survey examples help with question design.
Group comments into useful themes, such as unclear billing, repeated explanation, delayed updates or an unsuccessful fix. Return to source records before proposing a cause, and interview relevant customers when the comments do not explain the issue. Preserve examples and allow multiple labels when a case contains several issues. Theme counts can overlap; they are not automatically percentages of all customers.
For an individual unresolved case, review the history before contacting the customer through the appropriate channel. Ask what is still blocked, explain available action and give an update the owner can deliver. Choose a response window that matches impact and capacity rather than declaring one universal deadline.
When follow-up is appropriate, tell customers what was investigated or changed. Explain a deferred decision without implying an uncommitted release.
Do not pressure customers to replace an unfavorable rating after recovery. Keep the original response as a record of that experience. If you measure the later recovery, identify it as a separate experience under a consistent rule.
The Parliamentary and Health Service Ombudsman’s improvement principles connect complaint records with learning and review. They concern public bodies; the useful general practice here is to assign the finding, review an action and communicate relevant learning. Use our feedback analysis guide for the detailed coding process.
Evaluate one improvement with stable measurement
Record the baseline before changing the service. Keep survey wording, eligibility, invitation timing and reporting window consistent. Compare similar issue types, channels and audiences, and disclose outages, staffing changes or product releases that could affect the result.
CSAT improvement record Rated experience, population and reporting dates: Question, scale, favorable threshold and invitation rule: Delivered invitations, valid responses and rating distribution: Investigated theme, evidence and uncertainty: Specific change, owner and dependencies: Pilot date, comparison group or comparison period: Customer outcome, accuracy and workload checks: Other changes and sample-composition differences: Follow-up actions and review date: Decision: keep, revise or stop:
Returning to the fictional baseline, suppose the later week has 200 delivered invitations, 100 valid responses and 85 favorable ratings. CSAT is 85%, with a 50% response rate. The score rose five percentage points, but response coverage also changed. Review case mix and comments before attributing the difference to the pilot. This example establishes arithmetic, not a guaranteed or statistically confirmed effect.
Connect findings to observed business consequences when evidence supports it. Report actual correction costs or later cohort outcomes with their definitions. A CSAT increase alone does not establish a particular revenue, retention or referral increase.
Common questions about improving CSAT
How often should we ask for feedback?
Use a trigger that suits the experience and gives the customer time to judge it. Rating a conversation soon afterward differs from assessing whether a fix worked after use. Apply a documented contact-frequency rule and avoid repeated requests about the same experience.
Where should a small team begin?
Start with one recurring, addressable problem. Review cases, correct a knowledge gap or handoff, and give the owner a review date. A shared document can hold the improvement record. Keep satisfaction and one relevant quality check together instead of pursuing speed alone.
How do we get other teams involved?
Show the problem, affected task, representative evidence and decision required from that team. Separate agent behavior from product and policy causes. Proactive communication, service recovery and customer success work usually involve other teams; the CSAT loop helps establish which of those changes the feedback supports.
