A feedback theme can have several correct counts. The useful number depends on the question being asked and the unit being counted. Write both down before comparing one theme with another.

This example uses six invented source records. The accounts, people and events are fictional teaching data. No real customer evidence or measured product result is represented.

The six source records

R1 | Aster | Person A | Call       | Explicit CSV request
R2 | Aster | Person A | Ticket     | Follow-up to R1
R3 | Aster | Person B | Call       | Explicit CSV request
R4 | Birch | Person C | Call       | Explicit CSV request
R5 | Cedar | Person D | Email      | Reporting task; format unclear
R6 | Cedar | Person D | Follow-up  | More detail about R5

The source identifiers are labels for this exercise, not links to existing recordings or tickets. In a real review, keep a traceable reference for every included passage.

First pass: count the unit

Six records. There are six rows, each preserving a separate source item. This count describes the material available to review. A follow-up is still a source record even when it concerns the same earlier episode.

Four people. Person A appears twice and Person D appears twice. Counting each person once produces A, B, C and D. The two people at Aster remain two people, because the unit in this pass is a person.

Three accounts. Aster, Birch and Cedar each count once. Two people speaking for Aster do not create two customer accounts. The extra source records remain attached to the account and can still explain urgency or provide context.

The compact audit is: 6 source records → 4 distinct people → 3 distinct accounts. The arrows change the counting unit. They do not describe a drop-off, a funnel or a conversion rate.

Second pass: apply an inclusion rule

Now ask a narrower question: how many accounts explicitly requested CSV?

R1 to R4 support an explicit CSV request in this invented dataset. They involve three people across two accounts: Aster and Birch. R5 and R6 describe a reporting task, but the required format is unclear. Keep those two records in an unresolved group until more context is available.

The result is four supporting records, three people and two accounts for the explicit CSV question. Removing repeated account mentions changes the reach count without deleting any evidence. Treating Cedar as a CSV request would require an extra interpretation that the supplied records do not support.

Third pass: name the denominator

Two of the three accounts represented in this fixture have an explicit CSV request. That statement describes this selected set of records. It does not establish the share of all customers who need CSV.

The fixture says nothing about how accounts were selected, who did not provide feedback, which sources are missing, or how many accounts could reasonably have been observed. Dividing by every account in a CRM would introduce a different population without establishing that its members had an equal opportunity to appear.

If the intended denominator is unknown, keep the account count and label the broader share as unknown. A precisely written limitation is more useful than a percentage with an unstated base.

A short review note

Before sharing a count, record the question, time window, counting unit, inclusion rule and deduplication key. List unresolved rows separately and preserve the source references. Another reader should be able to reproduce the numerator and understand which population it describes.

For the wider workflow, this guide to analysing customer feedback covers preserving source material, grouping needs and distinguishing repeated mentions from distinct customers. The worked example here isolates the counting step so its assumptions remain visible.