How to Analyse Open-Ended Employee Survey Comments

Split each comment into what people see, what they blame and what they suggest. Then mark the gaps comments cannot fill and ask again.

Spradley Research

Research team

Nov 10, 2026

To analyse open-ended employee survey comments, give every comment three cells on a coding sheet: what the person noticed, the reason they give for it, and the change they suggest. Count the cells, not the comments. Then mark each topic where a cell stays empty or the causes disagree. Those marks are where the comments run out, and where you need to go back and ask people, usually in a short follow-up interview.

Key takeaways

A comment usually holds up to three different things. Code them separately or they blur into one “theme”.
Most comments describe a problem. Far fewer say why it happens, and the why is what you can act on.
The people who write comments are not a fair sample of your workforce. Treat the comment pile as a set of leads.
An empty cause cell or two rival causes is a gap. Turn each gap into one question and put it to the people who know.

Why is a list of themes not enough?

Most guides stop at grouping comments into topics and tagging the mood. You end up knowing that “workload” came up a lot and sounded unhappy. You still do not know whether people blame staffing, a new system or one manager, and each of those needs a different fix.

There is a second problem: who wrote in. Ingwer Borg and Cornelia Zuell studied about 75,000 comments from some 24,000 employees of a multinational IT company in a 2004 online survey. Around 40% of respondents wrote a comment. Most comments had a negative tone, and negative ones were longer. People with lower job satisfaction and commitment were more likely to comment. It is one company, more than twenty years ago, so treat it as a warning. The comments tell you what the vocal part of your workforce thinks, and little about the rest.

What does the coding sheet look like?

One row per comment, with these columns. The rows below come from a council library service invented for this article. Fill a cell only from the words on the page. If the person did not say why, the cause cell stays blank, however obvious the reason seems to you.

Comment	Topic	Observes	Cause, in their words	Proposes	Gap
“The kiosks jam every Saturday and there’s nobody to help.”	Self-service kiosks	Kiosks jam on Saturdays, no staff nearby			No cause
“The kiosks would be fine if the older stock had tags. Half of it doesn’t.”	Self-service kiosks		Older books lack tags	Tag the older stock	Rival cause
“Since the evening shift went I’m alone on the desk after five. Put one person back on Thursdays.”	Staffed hours	Alone on the desk after five	Evening shift was cut	One extra person on Thursdays
“Morale is awful.”	Morale	Low morale			No cause, no proposal

The library service’s nine branches have just lost their staffed evening hours and gained self-service kiosks, and the head of libraries has 300 comments in a spreadsheet and a meeting with the council on Wednesday. The kiosk rows carry one cause, untagged books. Further down, other rows blame the kiosk software instead, so the topic has two rival causes and needs two different fixes.

How does Spradley split a finding the same way?

Worked example. The same three columns are how Spradley writes up a finding. Each area of a Spradley report gets one finding, broken into what people observe, what they believe is behind it and what they suggest.

The difference is where the cause comes from. A comment box gets a reason only when someone volunteers one. Spradley collects answers through one-to-one interviews, typed or spoken, with an AI interviewer that asks each person a further question about their answer, to get at the reason. So the cause cell has a much better chance of being filled before anyone starts coding.

The coding itself is done the way a qualitative researcher would, but several times over, and only the groupings the separate passes agree on survive. Topics come out of what people said instead of a list fixed in advance. How far a finding reaches and how serious it is are stated in plain words, which avoids a precise-looking percentage from twelve people. Each finding is checked against the answers, and any wording that overreaches is corrected before it is published.

If you are coding by hand from a survey tool, the steps below get you the same structure.

Step 1: Clean the file before anyone reads it

Take out names, phone numbers and anything else that identifies a person, and remove the department column for groups too small to hide in. Comments are the easiest part of a survey to trace back to their author, because people write the way they talk. Our piece on anonymity thresholds covers where the lines usually sit. Agree who will read the raw file, and keep that list short.

Step 2: Read a sample before you name any topics

Read 30 or 40 comments at random with no categories in mind. Write down the topics you see, then code the full set against them and add new ones as they appear. Starting from the survey’s own sections (“manager”, “pay”, “wellbeing”) hides anything that does not fit them, such as kiosks that jam on Saturdays.

Step 3: Split every comment into the three cells

Three rules keep the sheet honest.

Their words, not yours. “Older books lack tags” goes in the cause cell because the person said it. Your own theory goes in a separate notes column, marked as yours.
One comment, several rows if needed. A comment about kiosks and about the evening shift is two rows.
Blank is data. An empty cell is the first sign of a gap.

If two people code, have both do the same 50 comments first and compare. Where they disagree about what counts as a cause, write the rule down before going on.

Step 4: Count the cells, topic by topic

For each topic, tally three things: how many rows observe something, how many name a cause (and which causes), and how many propose something (and what). A topic with 80 observations and 6 causes looks loud, and you still know very little about it. A topic with 15 rows that mostly agree on one cause and one fix may be the one you can act on this month.

Describe size in words when you report it: “raised widely”, “a few people, strongly”. With a few hundred comments from a self-selected group, a percentage suggests a precision you do not have.

Step 5: Mark where the comments run out

This is the step most analyses skip. Go through each topic and mark it if any of these is true.

No cause. Plenty of people observe it and hardly anyone says why.
Rival causes. People name causes that need different fixes, like jamming software against untagged books.
Proposal without a problem. A suggestion repeated many times with no observation behind it. Find out what it is meant to solve.
One corner only. Everything comes from one site or role, and you cannot tell whether it is local.
Loud few. A topic that matters to everyone, raised by a handful. Borg and Zuell found commenters were less satisfied than those who stayed quiet, so the quiet majority may see it differently.

Write each mark as one question whose answer would change what you do. For the library: “When the kiosks fail on a Saturday, what is actually going wrong?” If every possible answer leads to the same decision, drop the mark and act.

Step 6: Hand the gaps to a follow-up interview

A marked topic will not fill itself by reading the comments again. You have to ask, and ask in a way that gets the reason, which a second survey rarely does.

In Spradley, a leader can first put the question to an existing report. The engine goes back over the raw answers and, within minutes, returns only claims that have been checked and passed by the privacy judge, without the leader ever seeing the raw text. When the answers simply are not there, Personal Agent writes a draft follow-up interview aimed at the gap: a brief, an intro and no more than three themes. You adjust it in plain language or bin it, and it goes nowhere until you confirm. It needs at least five people, so it cannot be aimed at one small desk. What comes back is a new report.

If your comments come from a survey tool, describe the open question to Spradley’s study assistant and it sets up the interview and writes the themes. The background on the research behind AI-moderated interviews explains why a conversation that follows up tends to get further than a box.

Topics with all three cells filled and causes that agree are ready for a decision. Our guide on taking action on employee survey results picks up from there.

What can a coding sheet not do?

It cannot speak for people who did not write. Borg and Zuell’s data suggests they are not a random slice.
It cannot tell you whether a stated cause is right. It tells you what people believe. That counts as evidence, and it can still be wrong.
It cannot protect a person who described their own situation in detail. Cleaning helps. Judgement about what to quote still matters.
It takes time. Coding 300 comments into three cells is an afternoon or more, and that is before the gaps.

Spradley’s rules of use set out what its AI will and will not do with what people say. To see the gap column turned into questions, see how a gap in your survey comments becomes a follow-up interview.

Frequently asked questions

What is the best way to analyse open-ended survey comments?

Read a random sample first, let the topics come from the comments, then code each comment into three cells: what the person saw, why they believe it happens, and what they would change. Count those cells by topic. Mark any topic with no cause or with rival causes as a gap to follow up.

How many survey comments do you need to read by hand?

Read 30 to 40 at random before naming topics, and have a second coder do the same 50 to agree the rules. After that, with a few hundred comments, coding the full set by hand is realistic. With thousands, software can do the first pass, but someone should still check a sample.

Are employee survey comments representative?

Usually not. In a large study by Borg and Zuell, around 40% of respondents wrote comments, most comments were negative, and less satisfied employees were more likely to write. Treat comments as leads to follow up. They do not measure the whole workforce.

Should you use sentiment analysis on employee comments?

It can tell you which topics sound unhappy, but not why. A negative tag on a comment about workload does not say whether staffing, a system or a manager is behind it. Use sentiment as a filter at most, and code causes separately.

What do you do when comments do not explain a problem?

Write one question whose answer would change your decision, then put it to the people affected. A short follow-up interview with that group usually gets the reason faster than a second survey, because it can ask why after each answer.

Key terms

Coding sheet: A table with one row per comment, splitting each one into what the person observes, the cause they give and what they propose.
Gap: A topic where the comments do not say why, disagree about why, or come from too narrow a group to decide on.
Follow-up interview: A further round of one-to-one interviews on a question an earlier set of answers could not settle.