Nemotron 3.5: From Client Calls to CRM Drafts

By Lazar Milicevic · Published October 29, 2026 · 9 min read

You finish a client call, and the real work starts: someone replays the audio, copies notes into the CRM, and drafts the follow-up email, while the revised quote and the "delivery by Friday" promise sit in a transcript nobody reads again. Nvidia just released an open model that covers transcription, translation, and speaker labeling in one checkpoint. Whether it belongs in your call-to-CRM workflow comes down to a test you can run this week.

What Nvidia actually shipped

Nemotron 3.5 Transcribe is an open-weight, offline speech model released on 10/28/2026 (Hugging Face, Build.Nvidia.com, GitHub and NGC all list that date). According to the model card, it has 34B total parameters with about 4.3B active, built as a Mamba-2–Transformer hybrid mixture-of-experts, under the OpenMDW-1.1 license, which Nvidia says allows commercial or non-commercial use.

The capabilities, per Nvidia's launch post:

• One checkpoint transcribes 40 languages
• It translates 31 of them to or from English
• It attributes speakers in 13 languages
• It handles recordings up to one hour and labels up to eight speakers

Two constraints matter immediately for a call workflow. First, it's an offline model: you feed it recorded files, not a live stream. The Decoder's report confirms real-time processing isn't supported. Second, language support differs by task. Don't assume that because a language transcribes, it also gets speaker labels or translation.

You steer the output with a text instruction on each request: verbatim, written form, contextual, or speaker-attributed, with word-level timestamps on request (Nvidia research page). Nvidia also released a speech dataset (Granary v2) and fine-tuning tools. Its launch post puts the public manifest at 463,062 hours across 48 languages, while some outlets quote different figures, so check the launch post for exactly what the dataset release covers.

Reading the benchmark headlines without over-reading them

The headline claim is that the model leads several benchmarks while using a fraction of the active parameters of its strongest open rival. That is a statement about model size, not about your hardware bill. Fewer active parameters doesn't automatically mean one-sixth of the cost, six times the speed, or that it runs on the machine you already own.

Here is what the primary sources say:

Some figures are shakier. Other outlets quote different English WER numbers across different dataset sets, so always name the benchmark when you cite a number. And some secondary sources claim parity with commercial cloud transcription while others say paid APIs still lead. I'm not claiming either, because the evidence in front of me doesn't settle it.

The takeaway: these are vendor-reported numbers on benchmark audio. Your recordings have crosstalk, speakerphones, and client names the benchmark never saw. The long-form figure (10.98%) is arguably closer to a real one-hour client call than the headline English number, and it's noticeably worse.

Where the model stops and your workflow starts

A transcript is an intermediate file. The business problem is that the customer asked for a revised quote, someone promised Friday delivery, and neither detail reached the system where work gets assigned. The model's job ends at text; four more jobs follow.

The handoff, stage by stage:

1. Speech stage. Nemotron produces a transcript with timestamps and speaker tags.
2. Extraction stage. An LLM proposes the customer request, the promised action, the owner, and the deadline.
3. Integration stage. Your code validates those fields against the CRM and writes a draft task.
4. Review stage. A person resolves anything ambiguous before an external message goes out.

Nvidia says the same recording can become a labeled transcript, an English translation, or a summary of decisions depending on the prompt. That summary step is closest to CRM notes, but it's audio question answering, and Nvidia's launch post says that capability is trained in English. For a non-English call, plan on transcribe-then-extract with a separate step rather than assuming the summary prompt carries over.

Here's the shape of the extraction contract I'd put between the transcript and the CRM:

from dataclasses import dataclass
from typing import Optional

@dataclass
class Commitment:
    customer_request: str
    next_action: str
    owner: Optional[str]        # None if unclear: do NOT guess
    deadline: Optional[str]     # None if unclear: do NOT invent
    evidence_ts: tuple[float, float]  # start/end seconds in the audio
    speaker_label: str          # as emitted by the model, unverified

def to_crm_draft(c: Commitment) -> dict:
    needs_review = c.owner is None or c.deadline is None
    return {
        "status": "DRAFT",
        "needs_review": needs_review,
        "task": c.next_action,
        "owner": c.owner,
        "due": c.deadline,
        "evidence": f"{c.evidence_ts[0]:.1f}s-{c.evidence_ts[1]:.1f}s",
    }

Two design choices carry the weight. Unknown owner and unknown deadline stay None rather than getting a plausible default. And every field carries a timestamp pointing back to the passage that supports it, so the reviewer can verify in seconds instead of re-listening to the call.

The failure modes you need to design around

Nvidia is unusually direct about where this model can go wrong, and three of those warnings land squarely on CRM logging.

Speaker tags can be wrong. The model card warns that speaker tags may not always attribute statements to the correct person. In a CRM workflow, "who promised Friday" is exactly the question the tag answers. A wrong attribution turns into a wrong owner on a task. Treat speaker labels as a hint to be confirmed, not a fact, especially on calls with overlapping talk.

The error types are real. Nvidia lists substitutions, deletions, hallucinated speech, and speaker attribution errors, and recommends targeted testing for long recordings, overlapping speakers, noise, names, and code-switching. A deleted sentence can be the one containing the commitment.

Prompt injection. Because the model is instruction-tuned, Nvidia warns it's more susceptible to prompt injection. Think about what that means when audio is the input: someone on a call (or audio playing in the background) can speak text that reads like an instruction. If the output feeds an agentic or CRM-writing system, Nvidia says to pair it with additional rails or filtering. In practice that means:

• The speech model's output is treated as untrusted data, never as commands
• The writer step can only create drafts, never send emails or change deal stages
• Extraction output is schema-validated before anything touches the CRM

# Guardrail policy for the call-to-CRM pipeline
transcript_handling:
  treat_as: untrusted_data
  strip_instruction_like_phrases: true   # flag, don't silently drop
crm_writer:
  allowed_actions: [create_draft_task, attach_evidence]
  forbidden_actions: [send_email, change_deal_stage, delete_record]
review:
  required_when: [owner_missing, deadline_missing, speaker_conflict]

One more note on data handling: the training mixture includes a small amount of PII tagging and redaction tasks, but Nvidia doesn't document that as a compliance feature. Running a model locally gives you control over where audio goes. It doesn't by itself make a workflow compliant with any particular privacy regime. Check your own obligations.

The ten-call evaluation pack

Before changing your stack, build a small test that answers one question: does this model plus your extraction step get commitments into the right CRM record with less total human time?

1. Pick ten recordings you're authorized to process. Mix clean audio, interruptions, background noise, and the accents your business actually encounters. Include other languages only if they're part of your workflow and supported for that task.

2. Write the reference answers by hand. For each call, record four fields: customer request, next action, owner, deadline. Note the timestamp of the passage supporting each answer.

3. Run the pipeline and score it. Your results sheet needs these columns:

4. Test the hard cases on purpose. Nvidia recommends targeted testing for long recordings, overlapping speakers, noise, names, and code-switching. Include at least one call over 30 minutes and one with a speakerphone. If your clients have unusual company or product names, try supplying them as a term list: Nvidia reports named-entity errors fall substantially on ContextASR-Bench when expected entities are provided. That's their own benchmark claim, so verify it on your names.

5. Measure the baseline too. Time your existing process end to end. Then time the assisted process including corrections. If a ten-second transcription creates five minutes of cleanup, that belongs in the result. I haven't run this model through that test, so I'm not attaching a savings claim to the release.

Decision rule: if reviewers spend less time correcting drafts than they spent writing notes from scratch, and zero invented deadlines reach the CRM unflagged, it's worth building around. If wrong owners show up on more than a few calls, fix the speaker problem (or require review on every multi-speaker call) before going further.

Cost, hardware, and licensing: what's free and what isn't

"Open" removes the license fee for the weights. It doesn't remove the compute. The model card's reference deployment is a single H100 80 GB, with weights released in BF16 plus FP8 and NVFP4 variants. Nvidia's launch post, however, calls the quantized versions "coming soon," so check the Hugging Face page for what's actually downloadable before you plan around a smaller footprint.

That leaves the practical options:

• Your own GPU. Free weights, but you need hardware in the class of what the model card describes, or a quantized build when it's available.
• A paid host. Neither the launch post nor the model card gives an official Nvidia price per minute, and pricing depends on the host you choose (for example, third-party inference providers). Get a current quote from whichever host you consider.
• Wait and watch. The headline throughput figure comes from the NVFP4 build on a workstation-class server GPU, and Nvidia's model card says some of those optimizations aren't yet in the open-source release. Don't use it to estimate your own speed.

For a business doing a handful of calls a day, offline batch processing after the call is a natural fit: the transcript doesn't need to exist in real time, it needs to exist before the follow-up email goes out. That favors renting GPU time or running overnight batches over buying hardware outright. Run your ten-call pack on a rented GPU first, and only then decide whether owning hardware pays off.

On licensing, OpenMDW-1.1 is what the model card lists, and Nvidia says commercial use is fine. Read the license text yourself against your use case; I'm not giving legal advice, and "open weights" has meant different things under different licenses.

Where I fit in

The hard part of a call-to-CRM workflow is rarely the speech model; it's the plumbing around it, where Gmail, the CRM, accounting, chat, and documents don't talk to each other. I build AI automations for solopreneurs and small teams, and this kind of glue work is where I spend my time. The speech model is one swappable stage in that chain, which is why testing it on your own recordings first is the right order of operations.

Want more like this?

I publish practical AI automation and GenAI engineering content every week.

Planning an AI automation project or need a second opinion on your architecture?

Connect with me on LinkedIn — Lazar Milićević, senior engineer building practical AI automation for solopreneurs and small teams.

Visit bizflowai.io for services and AI consulting.