AI Qualitative Survey Analysis: 15 Starting Codes and a Reviewable Workflow

Choose a method and preserve the analysis record

A code labels something analytically relevant in a segment of text. A theme is a broader interpretation of a pattern, not simply the name of a bucket. Braun and Clarke distinguish different thematic-analysis approaches; their reflexive approach does not use coder agreement to establish one objectively correct interpretation. This page instead describes a practical codebook-based workflow for operational feedback. Thematic Analysis methods FAQ.

That choice matters. If your study uses reflexive thematic analysis, do not bolt a fixed fifteen-category checklist and an agreement target onto it and call the method unchanged. Work with the research lead to choose coherent procedures. For this guide, the initial categories may be revised after reading responses, and all substantive revisions need a record and reassessment of affected coding.

AI-assisted coding is not a new synonym for research expertise. A 2023 study by Ziang Xiao and colleagues explored GPT-3 with expert-written codebooks for a specific deductive-coding task. That provides historical research context, not evidence about today's models, every language or OpenMax's performance. Study abstract and publication details.

Keep the question beside the answers. A comment collected after asking “What frustrated you?” is not interchangeable with one collected after asking “What worked well?” Pew Research Center's analysis of open-ended questions found that question characteristics were associated with different item-nonresponse patterns in its panel. The practical lesson here is to retain wording and missingness, not borrow that study's rates as a benchmark for your survey. Pew's research on open-ended question nonresponse.

Fifteen starting entries for the codebook

Adapt these entries to the research question before a full coding pass. C01–C14 are candidate substantive codes; C15 is a review disposition. Several substantive codes may apply to one response, but only when distinct supported content warrants them. Do not increase the apparent richness by assigning every nearby label.

Each quoted snippet in this section is fictional. It demonstrates a boundary rather than documenting a customer's experience. A respondent's statement about a product remains a statement until the relevant product evidence has been checked.

1. C01 — Primary need

Use this code for the job or problem the respondent explicitly wants to address. “I need the weekly report ready for planning” identifies a reporting need; “add a blue button” only identifies a proposed interface change unless the surrounding answer explains the underlying job. Preserve the actor and situation without inventing an organizational strategy.

A useful annotation identifies the relevant words and states the need in plain language. If two needs appear, retain both rather than naming whichever aligns with the current roadmap. When the need is an analyst hypothesis, put it in a memo marked as interpretation, not in the respondent's mouth.

2. C02 — Desired outcome

Record the changed state the person asks for: less copying, a report ready earlier, fewer interrupted tasks or clearer ownership. “So I can stop copying figures” expresses an intended reduction in manual work. It does not establish how much time would be saved or that a proposed feature would deliver the result.

Keep this distinct from C05, which captures the respondent's criterion for judging success. The same passage can support both an outcome and a stated deadline, but a general wish for speed must not acquire an invented numerical target. Record achieved outcomes separately from wishes.

3. C03 — Current workaround

Include a substitute process the person says they currently use, such as copying totals into a spreadsheet. Preserve why they use it when stated. “I would build a spreadsheet if this failed” is a possible future response, not evidence that a workaround is already operating.

Do not automatically describe the workaround as waste. A manual step may support review, accessibility or a requirement outside the product. The follow-up question is what function it serves and which constraint makes it necessary. Its presence alone is not permission to remove it.

4. C04 — Trigger event

Apply this when the response explicitly connects an event to a subsequent action or reconsideration. “A failed import made me look for another tool” reports a trigger from that person's perspective. “The import failed last week” reports an event but does not establish that it caused a search or switch.

Preserve the reported sequence and attribution. Do not upgrade a self-reported explanation into a proven causal effect across customers. If an analyst thinks a launch or price change caused the feedback, test that idea separately rather than attaching it to all responses from the same month.

5. C05 — Success definition

Capture the person's own threshold or observable test for whether the task works. “Ready before Monday's planning meeting” provides a deadline; “better reports” does not define a measurable acceptance test. Keep timezones or operational context when supplied and relevant, but do not invent them.

This is a research record, not a service-level commitment. A request for a one-minute process does not mean the vendor promised one minute. Use the stated criterion to frame validation work, then check feasibility, product scope and contractual commitments through their separate owners.

6. C06 — Positive experience

Use a supported favorable experience and retain its object. “The export control is easy to find and works for me” is useful counterevidence to a claim that everyone is unable to export. It does not cancel another person's difficulty or prove that all account types have the same capability.

Avoid converting a vague “fine” into a rich success story. If the response combines praise and a problem, code the relevant parts separately. A sentiment label should not erase the concrete reason, qualification or contrast that gives the comment value.

7. C07 — Negative experience

Record an explicitly described unfavorable event and its consequence. An import failure belongs here when the response reports it. A worry that an import might fail is a concern, not an observed incident. Neither statement by itself verifies a defect in the product.

Keep severity and attribution tied to the text. “It failed once” should not become “the platform is unreliable,” and a complaint should not become an allegation of negligence. Operational logs or follow-up research may help investigate the report, subject to the permitted purpose and access rules.

8. C08 — Usability friction

Code difficulty finding, understanding, navigating, learning or recovering from an interaction. “I cannot find the export control” supports discoverability friction. It does not show that export is absent. This distinction is central to the worked example below.

Separate interaction difficulty from missing access, a stated policy restriction or a reported system failure. If a participant volunteers an assistive-technology context, retain only what is necessary and authorized for the research. Never infer disability, age or ability from writing style or task difficulty.

9. C09 — Perceived missing capability

This label deliberately says perceived. Use it when the response explicitly describes an absent function or scope, such as “this account has no CSV export.” The coding records what was reported; product verification must still distinguish true absence from plan limits, permissions or configuration.

Exclude “I cannot find it” unless the response supplies a separate absence claim. A suggestion to add something also does not automatically prove that it is unavailable today. Preserve requests under C14 and identify a potential gap as an investigation question until there is sufficient evidence.

10. C10 — Support need

Capture an explicit request for explanation, training, troubleshooting or human assistance. “A walkthrough would help” states a support need; a long complaint with no request does not necessarily tell you which support channel the respondent wants. Record the point in the journey when help is needed.

This may overlap with trust or usability codes. Asking who can read uploaded files can be both a request for information and a trust concern. It does not establish a security incident or authorize a support agent to contact an anonymous respondent.

11. C11 — Trust concern

Include an explicit concern or request for evidence about reliability, privacy, security, transparency or control. “Explain who can read uploaded files before we adopt it” raises an access-related question. Do not recast it as irrational fear, a confirmed breach or a psychological diagnosis.

Separate perceived risk, reported incident and independently verified failure. That distinction changes the next step: provide documentation, investigate an incident or correct a confirmed problem. Protect sensitive details before forwarding a quote to someone outside the approved research team.

12. C12 — Price or value concern

Use this for stated concerns about affordability, billing predictability, packaging or whether the benefit justifies the cost. Preserve negation. “The price is acceptable; approval stops my rollout” does not support a price-concern label merely because the word “price” appears.

Avoid inferring budget, income or willingness to pay from tone. A statement about confusing invoices and one about an unaffordable price need different follow-up. Frequency can identify questions worth investigating; it cannot independently establish a new price or expected revenue effect.

13. C13 — Adoption barrier

Record a stated condition preventing or delaying use, such as approval, integration, migration or an unanswered review question. The wording “before we adopt it” can make a condition explicit. A general interest in documentation without a link to adoption is not automatically a rollout blocker.

Preserve whether the barrier is current or hypothetical and who is said to control it. Do not assume the respondent has purchasing authority. An organizational constraint should not be reframed as an individual's lack of motivation or technical competence.

14. C14 — Improvement suggestion

Capture a proposed change and its intended benefit when stated. “Add a CSV export option so I can stop copying figures” gives a suggestion, an outcome and evidence of an existing workaround. These can be coded separately because the text supports each distinction.

Do not treat a suggestion as a validated solution or product commitment. Keep the wording specific enough for a product owner to investigate, while recording constraints and alternatives. A frequently requested change may still be infeasible, address only a narrow segment or be less important than a rare serious failure.

15. C15 — Unclassified or awaiting review

This is a workflow state, not a substantive finding. Use it when the relevant meaning is unclear, the language cannot be reviewed, context is missing or no current code fits. Keep separate reasons: a blank answer, an off-topic answer and an ambiguous nonblank answer are not the same situation.

“Fine, I suppose” stays unresolved in the example because the team has insufficient context to assign a specific experience code. Do not force a positive label to improve the completion rate. Retain the answer in the declared nonblank denominator, record the unresolved count and revisit it when appropriate evidence or a revised definition becomes available.

Run a pilot, review disagreements and preserve changes

First, define the permitted dataset. Record who was invited, who completed the survey and who saw the open-ended item. Preserve question versions and routing. Remove fields that are not needed for the research, and use a documented duplicate rule based on available record evidence. Similar wording from two people is not itself proof of a duplicate.

Second, read before labeling at scale. Read a varied set of complete responses, including short, long, mixed, rare and non-English answers. Write a brief memo about the analyst's assumptions and what would challenge them. Revise the starting codebook to fit the actual question; do not make the data conform to a marketing list.

Third, pilot the coding task. For this operational codebook approach, have reviewers apply the draft definitions to an approved sample, compare decisions and record why they differ. If measuring agreement, specify the unit, sample, statistic, treatment of multiple labels and unresolved cases. There is no universal pass percentage supplied by this guide, and agreement does not establish that an interpretation is true.

Fourth, constrain AI output. Request response IDs, supporting excerpts, proposed codes and a concise evidence-based rationale. Allow an explicit unresolved state. Keep model and prompt versions with the run. A rationale is another generated claim to inspect, not an audit trail by itself. Reject invented IDs, altered quotations and codes outside the approved set.

Fifth, reconcile and recode affected records. Suppose a pilot conflates discoverability with absence. Clarify C08 and C09, record the change and reassess all potentially affected responses, not just the ones a reviewer happened to notice. Preserve the prior assignment and the reason for replacement. Do not silently mix results from two codebook versions.

Finally, write an interpretation with counterevidence. Group and interpret relevant coded material in light of the research question. Show where accounts differ and what alternative explanations remain. A table of code counts can support an operational summary, but it is not automatically a fully developed thematic analysis. Use the AI research report template to keep findings, calculations and recommendations distinct.

Worked example: nineteen code assignments are not nineteen people

The fictional survey asks: “Thinking about your recent reporting workflow, what worked, what got in the way, and what would you change?” Twenty eligible people are invited; twelve complete the survey and reach this item. Ten provide nonblank text and two leave it blank. A duplicate export of S03 creates thirteen file rows but still only twelve unique completed-survey records.

The example excludes that duplicate using its repeated record ID and identical content. It does not delete similar comments from different IDs. The main coding denominator is the ten nonblank answers, including S09, which remains unresolved. The reviewed assignments below are editorial examples under the stated codebook, not objectively unique interpretations or results from an AI product run.

The survey-completion proportion is 12 ÷ 20 × 100 = 60%. Among completed surveys, the open-ended item's nonblank proportion is 10 ÷ 12 × 100 ≈ 83.3%. These are distinct descriptions of this invented flow, not standardized survey-response-rate estimates or evidence of representativeness.

The coding file contains nineteen substantive assignments across nine answers. S09 contributes no substantive assignment but remains in the ten-answer denominator. Accordingly, the sum of code percentages is 19 ÷ 10 × 100 = 190%. That is valid for this multi-label counting rule, not a claim that 190% of people responded. It would be misleading to present these overlapping percentages as slices of a mutually exclusive pie chart.

C08 appears in S01 and S08: 2 ÷ 10 × 100 = 20% of nonblank answers. C09 appears only in S03: 1 ÷ 10 × 100 = 10%. A flawed interpretation that also marks S01 and S08 as missing capability would report 3 ÷ 10 × 100 = 30%. The correction changes the interpretation from three absence claims to two discoverability reports and one explicit perceived-absence claim. It still does not establish whether the feature actually exists for that account.

S02 must remain visible as a contrasting experience. S04's acceptance of price is not a price complaint. S10 proposes an option but does not explicitly establish its current availability. S09 makes the substantive-coded proportion 9 ÷ 10 × 100 = 90%; that is processing coverage under this example's rules, not 90% model accuracy.

A defensible summary is: “Of ten nonblank answers, two describe export discoverability friction and one explicitly reports missing export capability. One answer describes a positive export experience. Investigate interface, account and access differences before selecting a fix; one ambiguous answer remains unresolved.” Do not generalize these ten invented comments to the customer population, promise a roadmap change or infer a cause that the data do not establish.

Select tools according to the research bottleneck

Manual analysis is often appropriate for a manageable set of responses and nuanced interpretation. A controlled spreadsheet can hold IDs, excerpts, codes and decisions. Its main weakness is maintaining consistent versions and traceability as more people or waves are added, not an inherent inability to support good research.

Native survey or research tools may already meet the need. Qualtrics documents topic assignment and response review in Text iQ, including multiple topic tags. Its documentation distinguishes feature access and language support across analysis functions. Verify the exact licensed workflow instead of assuming every feature works equally in English, Chinese and Japanese. Qualtrics Text iQ functionality.

Deterministic automation is useful for validated record deduplication, allowed-code checks and denominator calculations. It can detect that a code references a nonexistent response. It cannot decide from arithmetic alone whether “I cannot find it” means a feature is absent. Keep that interpretation in the review process.

Agent-assisted work may help coordinate source-linked drafts and review queues when the underlying tools and permissions support it. At scale, test language failures, changed codebooks, quote leakage and conflicting source versions. Measure actual reviewer effort only if the team records it consistently; do not promise savings based on generated word count.

For employee research, the pulse-survey analysis guide adds population and workforce-reporting considerations. Do not transfer a customer-feedback workflow unchanged into employment decisions.

Evaluate OpenMax with a bounded coding exercise

OpenMax publicly describes a human–agent collaboration platform. That is a reason to discuss a coordination use case, not proof that it provides a validated qualitative-research method, a dedicated survey connector or every review and privacy control described here. OpenMax product overview.

Begin with the fictional packet, a small agreed codebook and explicit expected outputs. Ask whether the proposed workflow preserves the duplicate rule, distinguishes C08 from C09, retains S02's contrary evidence and leaves S09 unresolved. Review the evidence for each assignment before examining the summary.

Verify actual access boundaries, supported languages, quote fidelity, version records, export behavior and retention in the intended environment. Keep respondent contact details out of a coding-only task. Do not use an attractive output as proof that restricted responses cannot be retrieved or that small-group details will be suppressed.

If your existing research tool already handles these needs, keep it. If evidence handoffs remain fragmented, bring the sanitized exercise and acceptance criteria to a scoped OpenMax workflow discussion. The next step is to assess a limited task, not upload an entire confidential survey or delegate publication.

Protect participants and avoid overclaiming

Preserve the original language beside an approved translation. Negation, idioms and a mixed-language answer may change the coding decision. Have someone competent in the language and research context review consequential interpretations; model confidence alone is not evidence of translation equivalence. Never infer identity, protected traits or mental state from a response.

Names are not the only identifying details. UK Data Service's text guidance discusses how combinations of narrative details can reveal people and why both excessive removal and insufficient protection can cause problems. Its guidance also calls for human review of automated processing. Anonymisation for text data.

Choose quotations for analytic relevance and variation, not just impact. Mark paraphrases as paraphrases and do not put invented wording in quotation marks as if it were verbatim. Check the permitted audience, re-identification risk and whether another person is described in the answer. A minimum group-size rule alone cannot make a distinctive story anonymous.

Before processing, confirm the permitted purpose, relevant participant notices, applicable legal basis, access and retention with the responsible owners. Treat answer text as data, not instructions to retrieve other records or publish findings. Do not attempt to identify anonymous respondents or bypass controls to obtain additional context. Sensitive workforce, health, legal or other high-impact uses need qualified review beyond this operational guide.

Frequently asked questions

Can one answer have more than one code?

Yes, if the codebook permits it and different supported content warrants each code. Count each response once per code for respondent-level summaries, distinguish assignments from people and explain why percentages may add to more than 100%.

Are the fifteen starting entries the final themes?

No. They are candidate codes plus a review state for this operational workflow. Develop the analysis from the actual research question and data. A theme requires interpretation of a pattern; a list of categories should not be presented as a completed reflexive thematic analysis.

Should we remove ambiguous answers to improve accuracy?

No. Keep ambiguity visible and report the inclusion rule. Removing hard answers can change the denominator and hide the very material needing review. In the example, S09 remains in the nonblank base but contributes no substantive code; processing coverage is not accuracy.

Does frequent mention make an issue the highest priority?

Not by itself. Consider sample coverage, severity, context, counterexamples, feasibility and evidence outside the survey. A rare but consequential problem can deserve attention, while repeated comments may reflect question wording or a narrow group.

Can AI identify the author of an anonymous response?

Do not assume identification is impossible. Context and linked information may create re-identification risk. This workflow prohibits attempting it and limits unnecessary joins, access and disclosure. Naming a dataset anonymous does not establish that its contents are safe to share.

Sources, authorship and revision scope

Prepared by the OpenMax content team for OpenMax's own website. The publisher has a commercial interest in the product discussed. Sources were checked on September 4, 2026 and support only the statements beside their links; no cited organization is claimed to endorse this article.

The starting entries and coding exercise are editorial teaching materials. They do not represent a customer survey, an empirical study by OpenMax, a model benchmark or approval by a named qualitative-methods specialist. The worked calculations can be reproduced from the downloadable files, but arithmetic consistency does not establish research validity.

This revision replaces the earlier outline with code boundaries, method distinctions, a transparent counting exercise, downloadable records and explicit product-verification limits. The original publication date remains September 2, 2026; the content revision is September 4, 2026. Send corrections with the page URL and non-sensitive supporting information to contact@openmax.com, without including confidential respondent material.