Beneficiary insight

Most charities collect far more feedback than anyone ever reads. Surveys, complaints, exit interviews, helpline notes, consultation responses - it arrives faster than a person can work through it, so a sample gets read and written up as "the findings", and the rest sits in a spreadsheet nobody opens again. The point of beneficiary insight isn't a tidier dataset: it's understanding the people you're there for well enough to serve them better, and to show honestly that you did.

Most of what people told you, no one ever read.

Three tasks we see here - a team usually has one of them live, not all three, and yours may be something this list doesn't name.

Read all of it, not a sample

You sent the survey, two thousand people answered the free-text question, and one person read two hundred of the answers and wrote up the themes. Everything in the other eighteen hundred - the thing said quietly, the complaint that didn't fit the boxes, the praise for the one member of staff about to leave - never got read at all. The work is reading all of it for what's genuinely in it, every theme tracing back to the people who said it. It works best as a hybrid - cheap, deterministic tools narrow the mountain; a tightly-controlled model is held back for the judgement of what a response actually means - and the hard part isn't the reading, it's trusting the input enough to publish from it. That's the part we've proven: AIDA at Breast Cancer Now turns 20-plus NHS survey formats into structured data accurate enough that researchers sign off on it and use it in their published reports.

Find what you didn't know to look for

A keyword search only finds what you already thought to look for - and the findings that change a service are usually the ones nobody knew were there: the need no question asked about, the same problem surfacing in three unconnected responses, the single disclosure buried on page two hundred of a consultation nobody finished. Finding those takes reading for meaning. And the risk runs the opposite way to what people expect - the danger isn't the model missing a real signal, it's the model inventing one, handing you a tidy, plausible theme that five responses sort-of-support and the other nine hundred don't. So the real skill is restraint: nothing gets reported as a pattern unless it traces back to enough real responses to be one, and every finding carries the receipts that let a sceptical research lead check it.

Notice who's missing

The voices you have are not the voices you serve. The people in the data are the ones well enough, settled enough, or trusting enough to answer a survey - and the charity often exists for the ones who aren't. You can't read absence directly, so the work is triangulation: who's in this feedback, set against who the service actually reached, set against who's out there in the community it serves. The gaps between those three are the finding. It's uncomfortable work, because it tends to show the service landing least well for the people it exists most to help - and it's the question the model is kept on the tightest rein for, reporting only what the comparison data supports and never speculating about people who aren't there to speak for themselves.

Hearing isn't the point

Listening is the easy half. What changes anything is acting on what you heard, and being able to show the people who told you - and the funder who paid for it - that you did. "You said, we did" isn't a poster; it's the evidence that you ran the service on what people actually told you, traceable back to the responses behind each decision.

So a first conversation isn't "let us analyse your feedback". It's working out which of these is your real problem - the volume you can't read, the signal you're missing, or the people you're not hearing - and whether there's something here worth building, or whether your team is already doing it well enough by hand. We'd rather tell you that than sell you a dashboard.