What is qualitative and quantitative analysis?
Quantitative analysis examines numerical measurements and counts. Qualitative analysis interprets material such as comments, interviews and observations. Using them together means examining how their findings relate to the same question, with a clear explanation of what each source supports.
A practical example is reviewing service ratings alongside open-ended feedback. The numbers describe the submitted ratings; the comments provide accounts of experience. Comparing them can help the team investigate a pattern, but the comments do not automatically prove what caused the ratings.
You can start this work with a small team and a clear review process. A service business comparing customer ratings, a training provider following up with learners and an association reading member feedback face the same basic task: connect the numbers to the relevant comments, check the interpretation and decide what to do next. One person prepares the records; a second checks categories and conclusions. AI can assist the review, but does not remove responsibility for the evidence.
This guide focuses on that applied task: preparing ratings and comments, reviewing categories, building a cross-tabulation and interpreting the result. For broader study integration, read mixed-methods data analysis.
What each analysis contributes
Scroll horizontally to see all columns →
| Part of the review | Example | What it supports | What it does not establish alone |
|---|---|---|---|
| Quantitative summary | The distribution of satisfaction ratings | A description of responses under the defined measure and coverage | The cause of each rating or the views of people who did not respond |
| Qualitative review | Accounts of reaching support after onboarding | An interpretation of experience in the reviewed material | A population-wide prevalence estimate from a selected set of comments |
| Combined review | Examining ratings alongside reviewed issue categories | A more specific investigation of how the sources relate | A causal conclusion merely because a category and rating occur together |
Both strands need sound analysis. Do not reduce the qualitative work to selecting a quotation that agrees with the chart, or reduce the numerical work to an average with no denominator.
Start with a question the data can address
“Why are customers unhappy?” is broad and assumes a conclusion. A more useful starting question is: “What do the submitted ratings and comments tell us about the support handoff during the first month?”
Define the period, eligible accounts and response channels. Check whether the comment question directly asked about the handoff or invited feedback on anything. If the rating refers to the whole service and the comment refers to a single contact, record that difference.
Decide whether the aim is an exploratory review, a recurring monitoring summary or a formal research analysis. A quick operational cross-tab should not be described as a complete explanation of customer behavior.
Prepare a reviewable dataset
Keep each rating linked to the comment submitted with it when that relationship is known. A response reference can be enough; you do not always need the person's name. If multiple submissions can belong to one account, retain that structure so counts are not mistaken for unique customers.
Scroll horizontally to see all columns →
| Field | Why it matters |
|---|---|
| Response reference | Keeps the rating and its accompanying comment together |
| Question and version | Shows what the respondent was asked |
| Date and service stage | Defines when and where the experience belongs |
| Rating and scale | Preserves the measure and its possible values |
| Original comment | Allows the interpretation to be checked in context |
| Reviewed categories and status | Distinguishes draft classification from an accepted review |
| Relevant grouping context | Supports an appropriate site, account or cohort comparison |
Do not invent record-level links when the sources were collected separately. Separate interview and survey samples can still contribute to a broader integrated interpretation, but they do not support a respondent-level cross-tab unless the relationship is known and appropriate.
Mixed-methods integration is broader than putting fields on one record. Fetters, Curry and Creswell describe integration at design, methods, interpretation and reporting levels in their integration guidance.
Review the comments before counting categories
Read the material to understand its range. In a structured issue review, define categories around the purpose, allow for unexpected material and record inclusion guidance. A category such as “handoff uncertainty” should mean something specific enough for the team to discuss.
Distinguish a topic from sentiment. A comment can praise an individual staff member while criticizing the process. It can mention a delay without expressing dissatisfaction. One comment may receive several categories; preserve that possibility rather than forcing every account into one box.
Review ambiguous classifications and keep extracts connected to the original comment. If AI suggests labels, verify them. A category definition supports consistency but does not guarantee identical model output or remove interpretation.
Worked example: ratings by a reviewed issue category
This fictional example contains 100 submitted ratings. Sixty include a substantive comment. Reviewers categorize 18 of those comments as mentioning uncertainty about the support handoff. “Lower” and “higher” below are predefined rating groups for the illustration, not a universal satisfaction standard.
Scroll horizontally to see all columns →
| Reviewed comment group | Lower rating | Higher rating | Total comments |
|---|---|---|---|
| Mentions handoff uncertainty | 12 | 6 | 18 |
| Does not mention handoff uncertainty | 8 | 34 | 42 |
| All reviewed comments | 20 | 40 | 60 |
Among comments mentioning handoff uncertainty, 12 of 18 accompany a lower rating, or about 67%. Among other reviewed comments, 8 of 42 accompany a lower rating, or about 19%. That is an observed association in the commented subset.
It does not show that uncertainty caused the lower rating. It also does not establish that the 42 other commenters experienced no uncertainty: they may have discussed something else. The 40 ratings without a substantive comment need to remain visible rather than being silently removed from the overall review.
Keep the denominator beside each number. Eighteen of 60 commented responses mentioned the category, or 30% of that subset. Eighteen of 100 total ratings had an accompanying comment mentioning it, or 18% of all submitted ratings. Those statements answer different questions; neither is automatically the prevalence of the issue among all customers.
Interpret the pattern with the full accounts
Read examples from both rating groups, including accounts that do not fit the first explanation. Perhaps a higher-rated customer mentions a confusing handoff but also describes a helpful resolution. That could change the team's understanding of what needs investigation.
Check the surrounding conditions. Different channels, service stages, account needs or response timing may affect both ratings and comments. A category comparison does not automatically control those differences.
A useful provisional conclusion might be: “Handoff uncertainty appears more often alongside lower ratings in the reviewed commented responses. We should examine the contact instructions and the experiences of customers whose issues were resolved successfully.”
A poor conclusion would be: “Handoff uncertainty causes low satisfaction in 30% of customers.” That claim changes the denominator, asserts causation and generalizes beyond the available material.
What if the numbers and comments disagree?
First check whether they address the same question, period and people. A rating may assess the entire relationship while a comment concerns one frustrating episode. A change in who responds can also change the apparent picture.
Then consider what the disagreement adds. Positive overall ratings can coexist with a specific issue worth addressing. Critical comments do not automatically invalidate the rating, and a strong average does not make the criticism irrelevant.
Document the unresolved interpretation and choose a focused follow-up. That may be a better collection question, a review of operational records or an interview with an appropriately selected group.
Run the review across locations and repeated cycles
Agree on the small shared core needed for comparison: scale, period, service stage, category meaning and any essential context. Local teams can retain additional questions. Do not combine categories simply because they have similar names.
Changes in wording can change what respondents mention. Asking directly about handoffs in one cycle and inviting general feedback in another makes a category trend difficult to interpret. Record question and category revisions and explain their effect on comparability.
For repeated observations, distinguish a continuing account from a new response. If you cannot match people across cycles, describe changes in the responding groups instead of an individual trajectory.
How Sopact reduces coding and reporting work
The expensive part is often what happens after the first analysis: a better definition, another collection cycle or a new question that requires the numbers and coded text to meet again.
A workflow with repeated manual work
- Define from an initial sampleRead material and agree on the codebook.
- Apply it across the datasetCode responses and check the result.
- Revise a definitionReturn to affected material and recode it.
- Reconnect the numbersReconcile coded results with ratings and context, then rebuild the view.
The Sopact workflow
- Your team owns the definitionsDecide what each code means and improve it as you learn.
- Apply coding across the eligible dataAutomate application; people review quality and exceptions.
- Reprocess after a definition changesReapply the revised definition across the configured scope instead of recoding each response by hand.
- Ask across coded text and numbersKeep the response, rating and relevant record context connected; inspect the evidence behind the result.
This compares workflow patterns, not a claim that every research tool requires manual coding or separate files. Some already automate parts of this work; compare the complete cycle.
The codebook can improve without another manual coding project
A sample helps a team develop its first definitions. It should not become an unspoken limit on what the final analysis considers. When thousands of later responses introduce something new, the team needs a practical way to improve the codebook and revisit earlier material.
Sopact's approach keeps that judgment with the team and automates application and reapplication across the configured data. The saving is the repetitive coding and reconnection work. Definition design, quality review, exceptions and interpretation still take time; processing and review are not free or instantaneous.
This applies to a codebook-based operational workflow. It is not a claim that every qualitative research method should use a fixed codebook or that all responses must identify a person. Use the appropriate response, account or participant relationship and respect access restrictions.
Reliable agentic analysis needs a route back to the data
An assistant should turn a question into a checkable operation on the data: apply the intended filters, calculate over the selected records, and return evidence that the reviewer can inspect. It should not invent a count from a generated summary.
The reliability test is specific: can you reproduce the calculation on the same data and definitions, and inspect why a record was included? That does not mean an AI interpretation is infallible or that a codebook guarantees identical model output.
Try a definition change · fictional records
Same question. A sharper definition.
Query: ratings of 1–2, with a comment coded for a support delay. The denominator is six submitted responses.
V1 includes delays in either replying or resolving the issue.
3 of 6 responses match
Illustrative workflow, not a live Sopact session. These six synthetic records have predefined coding under each version. In real work, reprocessing and review must finish before the revised result is treated as ready.
The ownership cost is the recurring work
Include implementation and staff time, repeated coding, revision checks, data joins, reporting, platform and processing costs. A low license cost does not tell you how much capacity the workflow consumes.
Illustrative labor model—not a measured customer result or a guaranteed saving. The example below processes the same volume in both workflows. It does not claim that a manual team actually read only a sample, and it includes continuing human review in the Sopact scenario.
Estimate the annual staff hours
Adjust setup, review and reporting assumptions
Manual other work: 6 review + 6 join/reconciliation + 4 reporting hours. Sopact human work: 12 review/exception + 4 revision validation + 1 integration check + 4 reporting hours. Setup includes initial configuration and definition work. Replace these assumptions with observed effort. The reread share can exceed 100% if several revisions require repeat passes.
Scroll horizontally to see all columns →
| Annual labor | Manual workflow | Sopact scenario |
|---|---|---|
| Setup | 16 h | 24 h |
| Initial manual application | 200 h | Automated; processing costs separate |
| Manual reapplication | 100 h | Automated; validation included below |
| Other human work | 64 h | 84 h |
| Total staff hours | 380 h | 108 h |
In this illustrative annual scenario. Your result may be smaller, larger or negative.
See the calculation and excluded costs
Manual hours = setup + cycles × [(responses × minutes ÷ 60) × (1 + reread share ÷ 100) + other manual hours]. Sopact scenario = setup + cycles × human-work hours.
This estimates staff time only. Complete ownership cost also includes your actual platform, processing, storage, integration, procurement and training costs where not already counted. Translate hours into labor cost using your own rates. Measure processing delay separately. Do not add the same expense twice.
If another tool already automates coding, revisions or joins, reduce the manual baseline accordingly. Long interviews, complex codes or intensive review need different inputs. Comparable quality and coverage are conditions of a useful comparison.
Compare the complete cycle on your own data
Use a representative dataset, agree the coding definitions, introduce a meaningful revision and ask a question that combines a code with a rating or outcome measure. Record the staff hours required to get a reviewed answer, including corrections and rework. That test makes the ownership argument concrete.
The operational benefit is capacity: the team can revisit a better definition and ask another question without automatically starting another coding-and-joining project. Faster processing is valuable only if the evidence and review remain trustworthy.
Evaluate the workflow, not just the chart
The practical burden often lies in repeated preparation: locating source comments, checking which version of a question was used and rebuilding the same link between files. Existing spreadsheets and research tools can support analysis, but the team should assess the recurring maintenance involved.
When evaluating Sopact, test collection, record context, reviewed classifications, source access and sharing with a representative sample. Include duplicate submissions, missing comments, category revisions and an exception that requires a human decision.
Check whether the resulting counts can be reproduced and whether a reviewer can inspect the relevant evidence. Verify the controls and analytical features you need. Do not infer that a platform replaces every specialist statistical or qualitative method.
Write the combined finding clearly
Use a short sequence: the question, coverage of each source, separate results, what their relationship suggests, what remains uncertain and the action to test. Include the category definition and the calculation basis when reporting a cross-tab.
Share excerpts only when appropriate for the audience. A removed name may not prevent identification from a distinctive account. Use a summary when that is the safer and more useful way to communicate the finding.
For the wider report, use How to Write an Impact Report and browse report examples. For the individual strands, see qualitative analysis and quantitative data analysis.
Watch: a combined evidence workflow
This video explains the cost of repeated coding and reconnection, and the workflow illustrated above. Apply the denominator, context and review checks when building your own combined view.
Why Qualitative Analysis Stays Small — And How to Scale It
Frequently asked questions
Can qualitative and quantitative data be analyzed together?
Yes. Analyze each appropriately and explain how the findings relate to the same question. Integration can happen at different levels; it is not limited to one respondent record.
What does a rating-by-category table show?
It describes how ratings and reviewed categories occur together in the included records. It does not automatically establish causation or population prevalence.
What should I do with ratings that have no comment?
Keep them visible in the overall coverage. A commented subset may differ from all respondents, so report the denominator for each analysis.
Does no mention mean no problem?
No. A person may not mention an issue because the question invited a different topic, they chose to discuss something else or the comment was brief.
Must all sources identify the same people?
No. A broader mixed-methods interpretation can use different samples. A respondent-level cross-tab, however, requires a known and appropriate link between the records.
Does AI make the combined analysis reliable?
AI may assist with preparation and draft classification, but reliability depends on the collection, definitions, review and analysis. Verify the source evidence and calculations.
