Importing TigerScribe transcripts into NVivo: a clean round-trip

Why NVivo's native transcription frustrates researchers

NVivo's built-in transcription engine is competent on clean two-speaker audio and degrades fast on anything else. Speaker identification is the most-cited weakness — the engine has trouble distinguishing similar voices, fragments long turns into multiple speakers, and offers no cross-recording memory. For a study with five recurring participants across twelve interviews, NVivo's native transcription becomes a relabeling project that consumes more researcher time than it saves.

That is why most researchers transcribe outside NVivo and import. The trick is making sure the imported transcript carries enough structure that NVivo's auto-coding by speaker, theme, and timestamp continues to work. A poorly-structured TXT file imports as one giant document and you lose every speaker-aware NVivo feature. A well-structured TXT file lets NVivo treat the transcript exactly as if it were natively transcribed — only with the higher accuracy of the external tool.

This guide is a practical walkthrough of that round-trip. The conventions are not unique to TigerScribe — most QDA-aware transcription tools follow them — but the example uses the TigerScribe export menu because that is what we know best.

The export formats NVivo accepts (and the one that auto-codes)

NVivo accepts several transcript formats: plain text (.txt), Word (.docx), PDF (read-only), and rich text (.rtf). The format that triggers NVivo's automatic speaker-aware coding is plain text with a specific paragraph convention: each speaker turn starts with the speaker name on its own line, followed by the spoken content. NVivo recognizes that pattern and creates auto-coded "Speaker" nodes for each name.

The verdict: export plain text from your transcription tool, with speaker names on their own line and timestamps inline. NVivo will treat it as a first-class transcript with all the auto-coding features intact.

Step-by-step: TigerScribe → NVivo

1. 01In TigerScribe, open the recording. Confirm speaker labels are correct (rename "Speaker A" to the actual name). Voice-ID-enrolled speakers should already have correct names.
2. 02Export menu → "NVivo-friendly TXT." TigerScribe formats the file with one speaker name per turn, inline timestamps, and a UTF-8 BOM that NVivo's importer prefers.
3. 03In NVivo, File → Import → Files. Select the .txt file. NVivo will offer a "Use first paragraph as document name" prompt; uncheck this if your file starts with a header line.
4. 04In the import dialog, ensure "Recognize as a transcript" is selected. NVivo will auto-detect the speaker-name pattern and prompt to confirm.
5. 05After import, check the Codes pane. NVivo will have created a Speaker node for each named speaker, auto-coded against every line they spoke. This is the foundation of speaker-aware analysis.
6. 06Optional: link the audio file (Source Properties → Media). With audio attached, NVivo can play timestamped quotes by Ctrl-clicking a timestamp in the transcript.

That is the entire round-trip. It takes about 90 seconds per recording once the export menu and NVivo import settings are tuned. The first time through is slower because of the dialog learning curve; after the third recording it becomes muscle memory.

Speaker labels that survive the round-trip

The single most common round-trip failure is speaker labels that diverge between the source transcript and the NVivo-imported version. Two common causes: extra whitespace around the speaker name (NVivo treats "Jean Luo " and "Jean Luo" as different speakers), and inconsistent capitalization (Jean Luo vs jean luo).

The fix is to normalize speaker names at export. TigerScribe's NVivo export trims whitespace, normalizes case, and uses a single canonical name for each enrolled voice ID. Other tools may not — check the exported TXT file in a text editor before import to confirm consistency. Two minutes of inspection saves an hour of post-import cleanup in NVivo's Speaker node tree.

For studies with anonymized participants ("P1," "P2," etc.), use the same convention across every recording. Mixing "Participant 1" in one transcript and "P1" in another creates two NVivo speaker nodes for the same person — the kind of silent error that survives until you wonder why your "P1 across all sessions" filter is missing data.

Timestamps that stay clickable in NVivo

Inline timestamps are how researchers verify quotes by clicking back to the source audio. NVivo supports this when the timestamp format matches one of its recognized patterns: HH:MM:SS, MM:SS, or [HH:MM:SS]. The export should bracket or paren-wrap the timestamp consistently.

If your transcription tool exports timestamps in milliseconds or as Unix offsets, NVivo will treat them as plain text and you lose the click-to-play behavior. The fix is to convert at export time — TigerScribe's NVivo export uses [HH:MM:SS] by default, which NVivo's transcript renderer treats as live. Other tools may need a manual find-replace pass before import.

Once the timestamps are recognized, NVivo's transcript view becomes the same kind of audio-linked workspace as the original transcription tool. Coders highlight a span, click the timestamp, and verify the quote against the source audio without leaving NVivo. That round-trip is the entire point of importing instead of transcribing in NVivo natively.

Common round-trip issues and fixes

Even with a well-formatted export, NVivo imports occasionally fail in subtle ways. The most common failure modes and their fixes are below. Most teams hit each of these once and then build the workaround into their import checklist.

"Recognize as transcript" does not appear

NVivo only offers the transcript-recognition option when the file structure clearly looks like a transcript. If your TXT lacks blank lines between speaker turns, NVivo treats it as prose. Fix: re-export with one blank line between speaker turns, or open the TXT in a text editor and add the blank lines manually before re-importing.

Speaker auto-coding is missing

If the Codes pane has no Speaker nodes after import, NVivo did not parse the speaker pattern. Common causes: speaker names are not on their own line (they are inline at the start of a paragraph), or the file is encoded as UTF-16 instead of UTF-8. Fix: ensure each turn starts with the speaker name on its own line, then re-save as UTF-8 (most text editors expose this in Save As).

Timestamps are not clickable

If timestamps render as plain text in NVivo, they did not match a recognized format. Verify you are using HH:MM:SS or [HH:MM:SS] (not milliseconds, Unix offsets, or "01h23m45s" formats). Fix: convert at export time, or use a find-replace pass in a text editor before importing.

Audio file fails to link

NVivo links audio by file path. If the audio file is on a network drive or has spaces in its filename, the link sometimes fails silently. Fix: copy the audio file to a local directory with a simple filename (no spaces, no special characters), and re-link from Source Properties → Media → Browse.

Imported transcript shows duplicate participants

If the same speaker appears as two NVivo nodes (e.g., "Jean Luo" and "Jean Luo "), the import detected a whitespace difference. Fix: open the TXT, find-replace double-spaces with single, trim trailing spaces from each line, re-import. Most editors have a "trim trailing whitespace on save" setting that prevents this.

One subtler failure: if you re-import the same TXT after fixing speaker labels, NVivo will create a duplicate document rather than updating the existing one. Fix: delete the original document from the project before re-importing, or use NVivo's "merge documents" workflow (Documents → Merge) to combine the new content into the existing node tree without losing any coding work that was already done. Always back up the .nvp project file before any merge — the operation is not reversible from inside NVivo.

When to leave NVivo entirely

NVivo is the right tool for many qualitative projects, but not all. If your work is collaborative across multiple coders in real time, NVivo's licensing and per-seat model gets expensive fast and the cloud collaboration story is uneven. If you need AI-assisted thematic analysis or auto-codebook generation, NVivo's native AI features are limited compared to the dedicated coding-AI products.

Honest alternatives: ATLAS.ti for cross-platform team coding, MAXQDA for mixed-methods work that needs strong quantitative integration, Dovetail for industry UX-research repositories, and Delve or Taguette for budget-constrained or open-source workflows. The TigerScribe export menu supports each of these — the round-trip mechanics are similar to NVivo's.