Customer Effort Score

When companies started surveying customers, the questions nearly all pointed the same way: were you satisfied, would you recommend us, how good did the experience feel. And yet in quarters where the score went up, the customers who were going to leave left anyway. The score and the cancellations barely tracked each other.

Pagedeck ran into this. The quarterly survey average came in higher than the quarter before, while the number of teams cancelling stayed flat. Mia pulled the records for twelve teams that had cancelled and found the thing they shared was not anger but repetition. They had bounced between three different settings screens trying to change a document permission, given up and filed a support ticket, waited for a reply, and tried again. None of them had written in a survey that the product was bad; they just quietly declined to renew.

Customer Effort Score (CES) is the same question turned around. Instead of asking how good something was, it asks how hard it was. When you want to know whether someone will use a product again, the memory of struggling predicts it better than the memory of being pleased. A good experience fades with time; a screen you once got lost on comes back the moment you open it again.

Put one statement in front of the user, collect agreement on a scale from 1 to 7, add the responses up and divide by the number of responses.

The calculation has three steps.

1. Pick the moment to ask. It has to be right after the user finishes one task — the screen at the end of a support conversation, the screen after a payment goes through, or the moment a new user creates a first document during onboarding, the stretch where someone is still finding their footing in a product. Ask a week later and they've forgotten the struggle.
2. Show the statement and collect the rating. The wording is usually something like "handling my request today was easy." A 1 means strong disagreement and a 7 means strong agreement.
3. Average the ratings. If 120 people answer and the ratings sum to 618, the score is 5.15.

The thing that most often goes wrong here is the direction of the scale. If you ask for agreement with "this was easy," higher is better; if you ask for agreement with "this took a lot of effort," higher is worse. In an organization running both versions, a 5.2 requires asking which direction it points before anyone can react to it. Some teams use a 5-point scale instead, so the score is written down next to the exact wording and the scale it used.

Three more things belong next to the number: when it was asked, whom, and how many answered. A score collected in the first week after signup and a score collected after six months of use are different numbers. Without those three, this quarter's value can't be set beside last quarter's.

On a 7-point scale, an average above 5 generally counts as easy going. It's useful for placing your own number roughly, not as a pass mark. The industry averages that circulate come with no record of when, whom, or what exactly was asked, so comparing against them sets two differently worded surveys side by side.

Build the standard from three things instead: your own value last quarter measured with the same question, the spread between values broken out by screen, and how the value connects to real behavior. The third is the most useful. At Pagedeck, people who scored 3 or below right after opening a document from an invite link came back within the week 34 percent of the time; people who scored 6 or above came back 79 percent of the time. Once that link to retention — how reliably existing users keep coming back — was established, a 4.1 stopped being a number to interpret and became a signal that the screen needed work.

An average on its own also hides things. A 5.2 can mean almost everyone picked 5 or 6, or it can mean half the respondents picked 7 while a fifth picked 1 or 2. The first calls for small refinements across the board; the second means some group is getting stuck outright under specific conditions. So the share of responses at 3 or below gets read alongside the average.

"Opening a document from an invite link scores 4.1 on effort. That's below the checkout flow."

Two flows inside the product were measured with the same question to see which path is rougher.

"Let's ask whether it was easy this time, not whether they were satisfied. Easy is what we want to know."

A customer satisfaction score (CSAT), which asks how satisfying one specific experience was, doesn't show where people got stuck, so the proposal is to change the question.

"The score went up 0.4 but we got half as many responses. We can't read those as the same number."

When the makeup of respondents changes, you can't tell whether the movement came from the fix or from who answered.

After reworking document permission settings, Pagedeck attached a single question to the end of that screen. Theo built it as a small card that appears right after saving, and Mia brought 340 responses from two weeks to a review. The average was 4.6, but 21 percent of responses were a 1 or a 2, and the comments attached to those kept repeating that people couldn't find where to make the change. Noa read thirty of those comments and pulled the scattered settings into one screen. A month later the same question averaged 5.8 and the share of 1s and 2s had dropped to 6 percent.

The number tells you where to dig; what to fix comes from the comments sitting next to the low scores. That's why the question ends with an open text box.

The most frequent mistake is reading a low score as missing features, which comes easily because the score looks like a verdict on the product. But what the score measures is not whether a capability exists — it's how rough the path to the goal is. Every feature can be there and the score still drops if the buttons are spread across three screens. Read it as missing features and the work drifts toward rebuilding things that already exist while the rough path stays as it was.

Treating it as a target is just as common. "Let's raise our effort score by 0.5 this quarter" sounds reasonable enough. But this value moves easily depending on when and whom you ask. A team handed that target tends to show the question only where the flow went smoothly, or pull the survey off screens where people get stuck. Next quarter's report then shows 5.9 while the support volume coming from that screen is unchanged. What's worth improving is the roughness of the path, and that gets checked against records like ticket counts and drop-off points.