Building a CSAT Programme That Cannot Be Gamed in Dynamics 365

A CSAT programme cannot be gamed when no individual can influence who is surveyed, whether the survey goes out or what the response says. Surveys are dispatched by a system account on a rule that fires when a case closes, with no button anyone can press. Recipients come from the transaction data, not from a person choosing them. Responses land in a store agents and supervisors cannot edit, with a scheduled copy to immutable storage. Nobody can cancel or resend a single survey, and exclusions are rules that are counted and reported. Every configuration change keeps a permanent audit history. Sample by a fixed rule, separate coaching from compensation, and give auditors a reconciliation they can test.

Why do customer satisfaction scores stop being believed?

Because at some point people learned they could influence them, and everyone else noticed. The patterns are familiar in service and sales teams alike, and each one exploits a step where a person rather than a rule decides something:

• Agents or account managers choose which customers get a survey, or press a send button only after a good interaction.
• The contact on a case is swapped to a friendlier person, or an email address is edited, before the case is resolved.
• Surveys to unhappy customers are cancelled, delayed or quietly never sent, and complaints are closed as a different case type that is not surveyed.
• Customers are told a score below the top mark counts as a failure, or asked directly for a high score.
• Responses are edited, deleted or re-requested after a poor result, or the survey is resent until a better answer arrives.
• The survey question, scale or eligibility rule is changed mid-period and nobody can say when.

Once an incident like this has reached legal, reassurance does not restore trust. A mechanism does: one where the answer to "could someone have influenced this?" is a documented no, with evidence.

What does a CSAT dispatch design that nobody can manipulate look like?

Remove every human decision from the path between a closed transaction and a sent survey.

1. Define the trigger in writing: the event that makes a transaction eligible, such as a case moving to resolved, an order being delivered or a field visit being completed.
2. Run the dispatch as an automated process owned by a dedicated system account or application user, in a managed solution, with no individual owner who could switch it off unnoticed.
3. Evaluate eligibility and exclusion rules inside that process, never in a view someone filters by hand.
4. Create a dispatch record for every eligible transaction, including those excluded, with the rule result and reason, before anything is sent.
5. Send through the survey tool from that record, and write delivery status and any bounce back to it.
6. Give no role in the organisation a manual send, resend or cancel action on dispatch records, and no ability to create them.
7. Retry failed sends by rule, a fixed number of times, and record each attempt.

In Dynamics 365 Customer Service this is usually a Power Automate flow or a plugin on case resolution writing to Dataverse tables for dispatches and responses. How cases, resolution and routing are configured in the first place is covered by our Dynamics 365 Customer Service implementation work, and the integrity design sits on top of it.

How should survey recipients be selected from transaction data?

From the record as it stood when the transaction closed, by rule, with changes near closure treated as a signal rather than ignored.

• The recipient is the customer contact on the case, order or visit at closure, and the address is the email held on that contact at that moment, copied onto the dispatch record so later edits cannot change who was asked.
• Where a case has several contacts, the rule names which one is surveyed, such as the contact who raised it.
• Audit the customer contact column on the case and the email columns on the contact. Flag dispatches where either changed within an agreed window before closure, and report the count per team.
• Exclude by rule only: internal contacts, test records, customers who have opted out of surveys, and a frequency cap so one person is not surveyed repeatedly. Store the exclusion reason on the dispatch record.
• Do not exclude by case type unless the rule was set before the period started. A complaint category that is not surveyed is the first place gaming moves.

Consent and opt-out rules come from your privacy team and the channel you use. Honour them, but make sure they are applied as data, not as a judgement by the person handling the case.

How do you make survey responses tamper-evident?

Dataverse does not have a true write-once table, so build the property from three layers and describe it honestly.

• Security: a dedicated response table where only the system account can create rows, and no business role has write, append-to or delete privilege on it. Use column security on the score and comment if supervisors need to see the record but not the raw verbatim.
• Auditing: auditing on for the response and dispatch tables and for the survey configuration, so any change a system administrator makes is recorded with old and new values.
• An external copy: a scheduled export of new responses and dispatch records, with their identifiers, to storage with an immutability policy such as time-based retention on an Azure storage container, plus a count reconciled per run. That copy is the evidence of record, and the Dataverse table is the operational view.

System administrators can still act in any environment, so name them, restrict the role, and review admin activity. The patterns for exporting history to immutable storage and documenting controls are in our guide to Dynamics 365 audit trails that survive a regulator, and this design reuses them rather than inventing new ones.

Why must selective cancel and resend be impossible?

Because they are the quietest way to game a score, and the hardest to see afterwards. A cancelled survey leaves no response, so it never appears in the average. A resend after a poor response invites a second answer. Either one done selectively, a handful of times a month, moves a team score without any single record looking wrong.

• No manual cancel. A survey is suppressed only by an exclusion rule evaluated at dispatch, and the suppressed count is reported beside the score.
• No manual resend. A delivery failure is retried by the process on a fixed schedule. A customer who asks for a new link gets one through the same process, recorded as an attempt against the same dispatch.
• One response per dispatch. A second submission is stored and flagged, and the rule for which one counts is written in the specification before launch.
• Reminders, if used, go to every non-responder on the same schedule, not to the ones someone expects to be positive.

What sampling rules keep the score statistically honest?

The rule that decides who is surveyed must be fixed before anyone knows how the transaction went, and the reporting must show what the score does not cover.

• Survey every eligible transaction if volumes allow. It removes the sampling argument entirely.
• If you must sample, select by a deterministic rule on data unrelated to outcome, such as a hash of the case identifier, set before the period starts. Never sample by hand or by a view someone can edit.
• Stratify where needed, by channel, product or region, so a small segment is not drowned out, and publish the strata with the result.
• Report the response rate beside every score, by team and channel. A score with a falling response rate may be hiding non-response from unhappy customers.
• Agree in advance the minimum number of responses below which a score for an agent, team or period is shown as insufficient data rather than as a number.
• Show the uncertainty. With small counts, the range around an average is wide, and two agents with different scores may not be meaningfully different. Your analytics or statistics lead should set the thresholds for your volumes.

How do you separate coaching use from compensation use?

Treat them as two products built from the same data with different rules, because the incentive to game rises sharply the moment pay depends on the number.

• Coaching reads individual responses and verbatims, soon after the interaction, for the agent and their team lead. It is about what happened on this case, and small numbers are fine.
• Compensation, if CSAT is used at all, reads aggregated scores over a longer window, at team level or above an agreed minimum count per person, calculated by a documented query that the people being paid cannot change.
• Publish the compensation calculation in advance, version it, and freeze it for the period. A mid-period change to the question, scale or eligibility rule is a new version with a new start date.
• Keep supervisors who are themselves measured on CSAT away from the dispatch configuration and away from any role that can see which customers are due a survey.
• Never show an agent which of their customers will be surveyed before the survey is sent.

What evidence will an auditor ask for before accepting the numbers?

An auditor tests whether the mechanism works as described and whether anyone could have gone around it. Prepare these before they ask:

• The written specification: trigger, eligibility, exclusions, sampling rule, survey question and scale, response handling and the calculation used for reporting, each with a version and effective date.
• A population reconciliation for the period: eligible transactions, dispatches created, excluded with counts by reason, delivered, bounced, responded, and the score calculated from those responses.
• The security role matrix showing who can create, edit or delete dispatches, responses and configuration, and the list of named system administrators.
• The change history of the configuration, flows and solutions, with approvals. Dataverse auditing covers table and column changes, and activity in Power Automate and Dataverse can be captured in the Microsoft Purview audit log. Check current Microsoft documentation for which events are recorded under your licensing.
• The flagged-change report: dispatches where the contact or email changed shortly before closure, and what was done about them.
• The immutable export with its run log and reconciliation counts, so a sample of responses can be traced from the transaction to the stored copy.

For reviewing the history of a single record during that work, such as when a contact email or the survey configuration changed and who changed it, Solzet Easy Audit is a free PCF control that presents the existing Dataverse audit history as a readable side panel, with a sortable table, a per-field timeline, filters and CSV export. It only reads audit data that auditing has already captured, so it is a view for investigators and reviewers, not a substitute for turning auditing on or for the immutable export.

Which survey tool should run the programme in the Microsoft ecosystem?

Keep the integrity design independent of the tool, because the tool is the part most likely to change. Microsoft has announced the retirement of Dynamics 365 Customer Voice, with survey capability moving to Dynamics 365 Customer Insights - Journeys and to Copilot Studio for conversational surveys. Check current Microsoft documentation for dates, migration paths and what each replacement supports before you build.

Whichever tool sends the survey, the dispatch rule, recipient derivation, response store, exclusions and audit history should live in your own Dataverse tables or database, so a change of survey tool does not reset the evidence. Where per-user Microsoft licensing or hosting control rules the Microsoft stack out, the same mechanism can be built in a custom CRM on React, Node.js, PostgreSQL or .NET, with database permissions and an append-only response table doing the work that security roles do in Dataverse.

How does Solzet help build a CSAT programme that cannot be gamed?

We act as the party that designs the mechanism and documents it, rather than as the team whose scores it measures. That means writing the specification with your service, legal and analytics leads, building the dispatch process, response store, exclusion rules and immutable export in Dynamics 365 Customer Service and Power Platform, setting up auditing and the flagged-change report, and preparing the reconciliation an auditor will test. Statistical thresholds and legal conclusions stay with your own specialists. Our senior consultants and full-stack developers bring 8+ years of Dynamics 365 Customer Engagement, Power Platform and custom CRM delivery, working remotely from Yerevan, Armenia, directly or white-label for Microsoft partners.