Customer effort is not the length of a conversation. It is the work a customer had to do before the business finally understood and resolved the need.
That work is often visible in support history. The customer contacts you again, changes channel, repeats account details, waits while ownership moves, or reopens an issue that looked closed. You can measure those signals without pretending they are a standard Customer Effort Score.
The useful approach is to keep two measures separate. Use a short survey for reported effort. Use conversation records for an observed effort indicator that your team defines and can audit.
Keep reported effort and observed effort separate
Customer Effort Score normally comes from asking how easy or difficult a particular task felt. The scale and calculation must stay consistent if you want to compare results over time. There is no universal benchmark that makes one company's score directly comparable with another.
Conversation data answers a different question. It shows what happened during the service process. It can reveal that a customer made three contacts, crossed from Instagram to WhatsApp, repeated an order number, waited for two transfers and then returned the next day.
Call this an observed effort indicator, friction rate or another plain internal name. Do not label a machine-generated number as CES unless it actually comes from the defined customer survey.
Define effort before counting it
Start with six signals that a reviewer can recognize without guessing the customer's mood:
- another contact about the same need within a defined period
- a transfer that makes the customer repeat information
- a channel change caused by the business rather than customer preference
- a reopened conversation because the promised outcome did not happen
- a request for information the customer already supplied
- an avoidable wait for ownership, approval or system access
Write a precise rule for each signal. "Repeat contact" might mean the same customer, same reason and same order within seven days. A transfer should count only when responsibility actually moves, not when a specialist quietly helps the owner.
Avoid using message length, angry words or the number of agent replies as shortcuts. A detailed customer may write one long message and receive an excellent answer. A polite customer can work very hard without expressing frustration.
Build a small evidence table
Use one row per resolved need, not one row per message. Keep the fields simple:
- Need identifier — Which contacts belong to the same task
- First contact time — When the effort began
- Resolution evidence — What proves the requested outcome happened
- Contact count — How often the customer returned
- Transfer count — How often responsibility moved
- Repeated information — Whether the customer had to restate known facts
- Channel changes — Whether the process forced another channel
- Reported effort — The customer's survey answer when available
Do not require a survey response before including a resolved need. Survey respondents are a subset. Keep response rate beside the result so nobody mistakes the survey average for the experience of every customer.
Use an indicator your team can explain
A simple observed effort indicator can be more useful than an opaque prediction. For example, give one point for repeat contact, repeated information, avoidable transfer, forced channel change and reopening. Report the share of resolved needs with zero signals, one signal and two or more signals.
Suppose a team reviews 200 resolved needs. This is a hypothetical example. If 128 have no observed signal, 48 have one and 24 have two or more, the first question is not whether the average is good. The useful question is why those 24 required several kinds of work.
Break the result down by contact reason, workflow, channel and owner team. Do not rank individual agents until you know whether the friction came from policy, missing knowledge, routing or a broken product step. Otherwise the measure punishes the person who inherited the hardest work.
Calibrate any AI analysis with people
AI can help group contact reasons or flag phrases such as "I already sent this," but it should not become an unreviewable judge of customer emotion. The NIST AI Risk Management Framework recommends monitoring deployed AI in its real context, documenting metrics and interpreting output with appropriate human review.
Build a review set from real, permitted conversations. Have two experienced reviewers apply the rules independently, discuss disagreements, then test the automated classifier against the agreed labels. Recheck it when channels, policies or customer language change. Record false positives and false negatives, not just overall accuracy.
Conversation text can contain personal data. Collect only what the analysis genuinely needs, restrict access and apply a retention rule. The ICO data minimisation guidance describes the basic discipline well: data should be adequate, relevant and limited to what is necessary for the stated purpose.
Turn the signal into a repair queue
An effort measure matters only when it changes work. Review the highest-friction needs each week and assign one cause that a team can act on. Common causes include unclear policy, missing knowledge, failed automation, incorrect routing, a product defect or a promise with no owner.
Then choose a repair and a verification date. Update the answer, change the routing rule, remove the unnecessary field or fix the broken step. Watch whether the same effort signal falls without damaging resolution quality.
This works best beside first contact resolution and root cause analysis. One measure shows whether the need stayed solved. The other explains why customers had to work for it.
If conversations are split across personal inboxes, you will struggle to connect repeat contacts and channel changes reliably. A shared conversation record can make the evidence easier to follow, but the definition and review discipline still belong to the operating team.
Frequently Asked Questions
Can conversation data replace a Customer Effort Score survey
No. Conversation data shows observed friction, while a CES survey records how the customer says the task felt. Use both and keep their names, methods and limitations clear.
What is the best first effort signal to track
Start with repeat contact about the same need. It is usually easier to define and audit than sentiment, and it points directly to work that appeared resolved but was not.
Should transfers always count as customer effort
No. Count a transfer when it creates delay, lost context or repeated explanation. Quiet collaboration behind one accountable owner may reduce effort even when several specialists contribute.
How often should the rules be reviewed
Review examples monthly at first and whenever a channel, policy, automation or routing model changes. Stable rules can move to a quarterly check, with exceptions reviewed sooner.
DripTell Editorial
Practical guidance reviewed by the DripTell product and customer workflow team.
See how DripTell checks product claims, uses primary sources and handles corrections.
Editorial and source policy



