Thematic coding in practice, building a codebook from transcripts

Thematic coding is the practice of tagging passages of interview transcripts with short labels, called codes, so patterns across participants can be found and checked. A codebook defines each code and the rules for applying it, so every coder tags the same way. Themes come later, built by grouping related codes once coding is done.

What thematic coding is and where the codebook fits

Thematic coding sits between a clean transcript and a finding. Coders read each transcript and attach codes to the passages that bear on the research question. The codebook keeps those codes consistent across coders, markets and studies, and themes are drawn from the coded passages at the end. Each of the three terms has a narrow meaning.

A code is a short label attached to a passage of transcript, such as "fee surprise". A codebook is the document that defines every code, with rules for applying it and examples. A theme is a claim about the data, such as "customers start looking elsewhere when a fee arrives without warning", supported by codes from several participants.

The broader practice is qualitative coding, and thematic coding is the version aimed at themes across a set of interviews. Take an enterprise study where, say, three coders in two markets share one set of transcripts for several product teams. The codebook is what keeps "fee surprise" meaning the same thing in every file.

What every codebook entry needs

A codebook entry needs a label, a one-sentence definition, a rule for when to apply the code, a rule for when not to, a typical quote and a near-miss quote. Add the parent theme, an owner and the date added, so anyone can see where the code sits and who proposed it.

Field	What it holds
Label	Two to four words describing the passage, such as "fee surprise"
Definition	One sentence saying what the code captures
Include when	The conditions under which a passage gets this code
Exclude when	The nearby cases that belong to a different code, with that code named
Typical quote	A short passage that clearly fits
Near-miss quote	A passage that looks like a fit but belongs elsewhere, and where it goes
Parent theme	The draft theme the code feeds, once one exists
Owner and date added	Who proposed the code, and when

The exclude rule and the near-miss quote do the most work. Clear cases are easy to agree on. The hard ones sit at the edges, where one passage could take either of two codes, and writing down the edge case settles it once instead of in every transcript.

Keep labels descriptive. A label that already states a conclusion, like "pricing is unfair", pushes coders to look for unfairness. "Price complaint" describes the passage and leaves the judgment to the theme.

Build the first version from a handful of transcripts

Build version 1 from a small, varied set of transcripts before coding the rest. Start from the research question and the discussion guide, code those transcripts line by line, cluster the raw codes, and write a definition and rules for each. Then freeze the list and code the remaining interviews against it.

Pick transcripts that differ

Choose a few transcripts that span the study's segments and markets: a long-tenure customer and a new one, at least one interview from each market. A first pass on similar interviews produces a codebook that breaks the first time a different kind of customer speaks.

Open-code them line by line

Read each transcript and attach a code to every passage that bears on the research question, without fitting a list yet. This is open coding, and its output is a wide set of raw codes, many of them duplicates.

Decide what you bring in and what you let emerge

Some codes come from the brief, the guide or earlier studies before anyone reads a transcript. These are deductive codes. Others appear from the data, and those are inductive codes. Most enterprise studies use both. Seed the list with codes from earlier studies of the same customer group, so business units can compare results from one study to the next.

Cluster, merge and write the rules

Group raw codes that describe the same thing, merge the duplicates, and write the definition, include rule and exclude rule for each code that survives. Freeze the result as version 1 and code the remaining transcripts against it, logging any passage that fits no code.

A worked codebook from cancellation interviews

Here is an illustrative codebook, written for this post. An insights team at a large card issuer codes cancellation interviews from two markets for its product, servicing and pricing teams. The table shows four codes from version 2, after one split and one merge. The quotes are invented examples that show how the rules work.

Code	Definition	Include when	Exclude when	Example quote
Fee surprise	A charge the customer did not expect or understand when it appeared	The customer learned of a fee from a statement or a declined payment	The customer knew the fee and objects to its size (fee level)	"I only found the annual fee when the statement came."
Fee level	An objection to the size of a fee the customer knew about	The customer weighs the fee against the card's value or another card	The fee was unexpected (fee surprise)	"The annual fee stopped making sense once I stopped traveling."
Switching trigger	A specific event that started the search for another card	The customer names a moment: an offer, a decline, a move	General dissatisfaction with no event; code it by its cause	"A colleague showed me his cashback, and I applied that week."
Service escalation	A problem that took more than one contact with support	The customer describes repeating the issue, a transfer or a callback	One contact that resolved the issue	"Third call, third person, same story."

Version 1 had a single code, "fees". In the first test between coders, one coder put known but disliked fees under it. The other coded them as price complaints, so the team split the code in two. Version 2 also merged "retention call" and "save offer" into one code, "retention offer", because coders were applying both to the same passages. The change log records both:

v2 | Split "fees" into "fee surprise" and "fee level" | Coders disagreed on known fees | Fee passages recoded
v2 | Merged "retention call" and "save offer" into "retention offer" | Applied to the same passages | Retention passages recoded

Test the codebook between coders before you trust it

Test the codebook by having two coders code the same few transcripts independently, then compare their work. Every disagreement points at a definition or rule that needs rewriting. Cohen's kappa gives one agreement figure that corrects for chance, and it is most useful as a prompt for that conversation, reported with the number of passages compared.

Cohen's kappa compares how often two coders applied the same code with how often they would have agreed by chance. Report it with the number of passages compared, because a figure from a few passages swings with each disagreement. The page on inter-rater reliability covers the measure itself.

Read the disagreements before the number. Low agreement on one code often points to a missing exclude rule. Disagreement spread across every code can mean the coders read the research question differently, which a definition rewrite will not fix.

The same check works on AI-assisted coding. A December 2025 arXiv preprint ran three large language models six times each on one interview transcript and reported agreement, measured with Cohen's kappa, of 0.907, 0.853 and 0.842. One transcript in one preprint sets no general accuracy level for AI coding. It does show that a team can hold an AI's coding to the same agreement measure it uses for human coders.

Whoever does the first pass, a person or a model, the research team decides what each disagreement means for the definition.

Keep the codebook stable through a study and into the next one

A codebook stays stable when nobody can change a definition silently. Give every change a version number, a reason and a recode of the passages it affects. Retire codes nobody uses, merge codes coders keep confusing, and name one owner who approves changes, so coders in every market work from the same version.

A definition changed halfway through without a recode leaves early transcripts coded to the old meaning and later ones to the new, and no one can tell which is which.

Retire a code nobody has applied after several transcripts, since it only lengthens the list coders scan. Merge two codes when coders keep applying them to the same passages. Route every proposed change through the owner, who updates the version number and tells every coder before the next transcript is opened.

A codebook also carries value between studies. Pulse groups interview responses into themes with quotes traced back to transcripts and stores every study in a searchable insight repository, so the next study's codebook can start from what earlier studies found.

From codes to themes without losing the evidence

A code labels a passage. A theme is a claim about the data that groups several codes and rests on quotes from more than one participant and segment. Keep every theme linked to its coded passages, so a stakeholder can open the quotes behind it, and treat theme building as the next stage of analysis.

In the card example, "fee surprise" and "switching trigger" passages might combine into a theme such as "an unexpected fee starts the search for a new card". That theme holds only if passages from both markets and several participants support it.

The link from theme to passage lets a product lead in another business unit check a finding without asking the research team. The post on auditing interview themes back to the exact quote covers that check.

Questions readers ask

Why is coding used in qualitative research?

Coding turns hours of interview text into labeled passages that can be compared across participants, segments and markets. It keeps the analysis tied to what people said, and it lets a second coder or a reviewer see how a conclusion was reached, so the finding rests on more than one analyst's reading.

Can AI do qualitative coding?

Language models can apply codes to transcripts, and a team can check that work with the same agreement measures used between human coders, such as Cohen's kappa. The research team still writes the codebook, reads the disagreements and decides what the codes mean for the business question.

What is the best way to start coding interview transcripts?

Start with the research question and the discussion guide, then open-code a few transcripts that differ by segment and market, line by line. Cluster the raw codes, write a definition, include rule and exclude rule for each, and freeze that list as version 1 before coding the remaining interviews.

What are common mistakes when coding transcripts?

Watch for labels that state a conclusion, codes with no exclude rule, definitions changed midway without a recode, and skipping the test between coders. Each lets the same passage be coded differently by different people, which breaks comparisons across markets and leaves themes hard to defend in a readout.