Coding and analysing qualitative data: from interview notes and comments to reliable themes (Research and Evidence for Better Decisions) | READOS

Interviews, focus groups, observation notes, open-ended survey answers, complaint descriptions, sales call notes and customer reviews all produce qualitative data: words rather than numbers. This data is often the richest source of insight a business has. It explains why customers leave, what frustrates staff, how processes really work and what people value. Yet it is also the data most often wasted. Transcripts sit unread in folders, hundreds of survey comments are skimmed for a few memorable quotes, and conclusions rest on whatever the most vocal participant said or whatever the researcher expected to find.

Systematic analysis turns qualitative data into evidence. The core technique is coding: labelling segments of text with short descriptive tags, then grouping and comparing those tags to find patterns, called themes. Done carefully, coding makes it possible to see what came up across many conversations, how often and in what circumstances, which views are shared and which are exceptions, and how themes relate to each other. It also makes the analysis transparent, so that others can check how conclusions were reached.

This article explains how to prepare qualitative data, build and use a codebook, combine deductive and inductive coding, develop themes, use simple tools such as spreadsheets and affinity diagrams, check reliability, look for exceptions, count appropriately, handle large volumes of short comments, use automated tools carefully and report findings. It is part of a series on research and evidence for business decisions.

Preparing the data

Analysis is easier when data is consistent:

Transcribe or summarise interviews in a standard format, with participant codes rather than names.
Remove or replace identifying details where confidentiality was promised.
Add context fields such as participant type, date, site or customer segment, so findings can be compared across groups.
Break long responses into segments, such as answers to each question.
Store files securely, with consistent names and version control.

Open-ended survey answers and complaint descriptions can be exported into a spreadsheet with one row per response and columns for context fields.

Familiarisation

Before coding, read through a good portion of the data, or all of it if feasible, noting first impressions, recurring ideas and surprises. Familiarisation helps the analyst understand the range of what was said and suggests initial codes. Impressions at this stage should be treated as hypotheses to test, not conclusions.

Codes and the codebook

A code is a short label attached to a segment of text that captures what it is about, such as “slow quote turnaround”, “unclear invoice”, “trusts technician” or “workaround with spreadsheet”. A codebook lists each code with a definition, guidance on when to use and not use it, and an example. The codebook keeps coding consistent, especially when more than one person codes or when coding happens over several weeks.

Deductive coding

Deductive codes come from the research questions or an existing framework before reading the data, such as codes for each stage of the customer journey or each category in a complaint system. Deductive coding is efficient and makes it easy to compare with other data, but it can miss issues that do not fit the predefined categories.

Inductive coding

Inductive codes emerge from the data itself, capturing ideas participants raise that the researcher did not anticipate. Inductive coding is essential for discovery but takes longer and needs discipline to keep codes consistent.

Most practical analysis combines both: starting with a few deductive codes linked to the questions, then adding inductive codes as new ideas appear, and updating the codebook as it evolves.

Coding in practice

Coding usually proceeds in cycles. In the first cycle, segments are labelled with descriptive codes, staying close to what participants said. In the second cycle, similar codes are merged, renamed or grouped into broader categories, and relationships between them are explored. Codes that appear rarely may be combined or noted as minor; codes that are too broad may be split.

Each segment can carry more than one code if it touches on several ideas. Coding the whole data set, not just the parts that seem interesting, prevents the analysis from being shaped by early impressions.

From codes to themes

A theme is a pattern of meaning across the data that answers part of the research question, such as “customers judge reliability by communication, not just speed” or “new staff learn the real process from colleagues, not procedures”. Themes are developed by grouping related codes, examining what they share and checking that the theme is supported across the data, not just by a few vivid examples.

Good themes:

are clearly defined and distinct from each other;
are supported by evidence from multiple participants or sources;
explain something relevant to the decision; and
acknowledge variation and exceptions.

Relating themes to each other

Themes rarely stand alone. Some are causes of others, some occur together and some apply only to certain groups. Exploring these relationships turns a list of themes into an explanation. A simple way is to look at which codes appear together in the same segments or the same participants, and to map themes on a diagram showing likely influences: for example, unclear job scopes leading to repeat visits, which lead to frustration about communication. Such maps should be presented as interpretations supported by evidence, and tested where possible against other data.

Documents and observation notes

The same coding approach applies to documents, such as meeting minutes, emails, incident reports and procedures, and to observation notes. Documents show what was decided, recorded or required at the time, which is valuable for comparing with what people later recall. Coding documents alongside interviews allows themes to be checked against independent sources. For incident reports and complaints, coding the stated causes and the actions taken often reveals recurring problems that individual reports treat as one-offs.

Making sense of findings as a team

Involving colleagues in reviewing themes improves both the analysis and its use. A short workshop in which the analyst presents draft themes with evidence, and colleagues challenge, refine and connect them to their own knowledge, often sharpens interpretations and builds commitment to act. The analyst should keep a clear line between what the data shows and what the team believes, recording both.

Simple tools

Qualitative analysis does not require specialised software for most business projects:

Spreadsheets work well for coding survey comments and summarised interviews, with codes in columns and filters to group segments.
Affinity diagrams, sticky notes grouped on a wall or virtual whiteboard, help teams cluster ideas into themes collaboratively.
Matrices, with participants or groups as rows and themes as columns, show which themes appeared for which participants and help compare groups.
Qualitative analysis software helps with large volumes of transcripts, complex coding and team projects.

Checking reliability

Coding involves judgement, so checks improve consistency:

Two coders independently code a sample, compare results and discuss differences, refining the codebook until agreement is good.
Codebook definitions are updated when ambiguities appear, and earlier coding is revisited.
An audit trail records decisions about codes and themes.

For small projects with a single analyst, having a colleague review a sample of coded data and the main themes provides a useful check.

Looking for exceptions

Negative cases, participants or responses that do not fit a theme, are valuable. They may reveal a different group with different needs, a condition under which the pattern does not hold or a flaw in the theme. Actively searching for disconfirming evidence is the best protection against confirmation bias.

Counting with care

Counting how many participants mentioned a theme helps convey its strength in the sample, for example “eight of twelve customers interviewed raised communication”. But in small, purposive qualitative samples, counts describe the sample, not the population; they cannot be turned into reliable percentages for all customers. Counting participants is more meaningful than counting mentions, because one talkative participant can mention the same issue many times.

For large volumes of open-ended survey comments, coding into categories and counting is appropriate and produces data that can be analysed like other categorical data. The analysing counts and categories in business data article explains how to analyse the results.

Coding large volumes of comments

Customer feedback programs can produce thousands of short comments. A practical approach is to code a random sample first to build the codebook, then code the full set, adding codes only when clearly needed. Pairing each comment with its rating or score shows which themes drive dissatisfaction and which drive praise. The customer feedback and net promoter score article explains how such analysis fits into feedback programs. Ranking themes by frequency in a Pareto chart, as described in the the seven basic quality tools article, highlights the few issues that account for most complaints.

Automated and AI-assisted coding

Text analysis software and AI tools can suggest codes, group comments and summarise themes quickly, which is helpful for large volumes. Their output must be checked: they can misread context, sarcasm and industry terms, merge distinct issues, invent themes not supported by the data and produce plausible but inaccurate summaries. A sensible approach is to use automated suggestions as a first pass, review a sample manually, refine the categories and keep human judgement over the final themes. Before loading customer or staff comments into external tools, check privacy obligations and the tool’s data handling.

Reporting qualitative findings

A good qualitative report:

states the question, the data sources and how participants were selected;
describes the analysis method briefly;
presents each theme with a clear explanation, supporting evidence and representative quotes;
notes how widespread each theme was in the sample and any differences between groups;
reports exceptions and uncertainties; and
draws out implications for the decision.

Quotes should illustrate themes rather than replace analysis, and they should be representative rather than the most dramatic. Participant confidentiality must be protected in quotes, particularly in small organisations where details can identify people.

A worked example

This is an illustrative example. The business and figures are hypothetical.

An equipment service company receives 200 open-ended answers to the survey question “What is the main reason for your score?” The customer service manager first reads a random 50 comments and drafts a codebook with eight codes, including response time, technician skill, communication during jobs, first-time fix, invoicing accuracy, price, booking process and parts availability.

Coding all 200 comments, with a colleague double-coding 40 to check consistency, gives these counts: communication during jobs 68, technician skill 52, response time 41, first-time fix 37, invoicing accuracy 24, booking process 19, parts availability 15 and price 12. Many comments carried more than one code. Linking codes to scores shows that communication problems appear most often among low scores, while technician skill appears most often among high scores.

A negative case stands out: several large customers praised communication but criticised invoicing accuracy, which turns out to stem from a separate contract billing process used only for them. The company prioritises job-status updates for all customers and fixes contract invoicing for its largest accounts.

How this applies to a small Australian business

Prepare qualitative data consistently, with context fields and confidentiality protected.
Build a codebook with definitions and examples.
Combine deductive and inductive codes.
Code all the data, not just memorable parts.
Check coding with a second person.
Search for exceptions to each theme.
Count participants, not mentions, and keep counts in context.
Code documents and incident reports alongside interviews.
Review draft themes with colleagues before finalising them.
Check automated coding before relying on it.

Common mistakes

Analysing by memory instead of systematically.
Choosing dramatic quotes that misrepresent the data.
Codes so broad they hide important differences.
Turning small-sample counts into population percentages.
Ignoring negative cases.
Presenting themes as a list without explaining how they relate.
Treating incident reports as one-offs instead of coding them for recurring causes.
Uploading confidential comments to tools without checking privacy.

Frequently asked questions

How many codes should a codebook have? Enough to capture meaningful distinctions without becoming unwieldy. For many business projects, a few dozen codes grouped into a handful of themes is workable.

Can qualitative analysis be done by one person? Yes, but a second person reviewing a sample of coding and the main themes improves reliability.

What is the difference between a code and a theme? A code labels what a segment of text is about; a theme is a broader pattern of meaning built from related codes that answers the research question.

How should contradictory views be reported? As part of the findings: describe the different views, who held them and possible reasons, rather than averaging them away.

When is a theme strong enough to act on? When it is supported across several participants or sources, holds up after looking for exceptions and is consistent with other evidence such as records or survey results.

Questions to ask

Do we analyse all of our qualitative data, or only the parts we remember?
Is our codebook written down with definitions and examples?
Has a second person checked our coding?
Which participants or comments do not fit our themes, and what do they tell us?
How do our themes relate to each other, and what explanation do they add up to?
How do we protect confidentiality when quoting people?

Bringing it together

Qualitative data explains the why behind numbers, but only systematic analysis turns it into evidence. Prepare data consistently, familiarise yourself with it, build a codebook, code all the data with deductive and inductive codes, develop well-supported themes, check reliability, seek exceptions, count carefully and report themes with representative quotes and honest limits. Simple tools suffice for most business projects, and automated tools are useful helpers when their output is checked.

Source: KEVOS editorial notes. Examples and figures in this article are illustrations.