Use cases

Voice data designed around real AI workflows.

NaraDatum helps AI teams obtain human data for training, fine-tuning, evaluation and benchmarking across voice and conversational AI. Every use case below follows the same order: check suitable existing supply, locate and review potential suppliers if needed, and scope buyer-funded collection only where existing data cannot meet the brief.

How NaraDatum supports AI teams

Speaker structure comes before format

One-speaker and two-speaker audio are NaraDatum’s current speech focus. The required structure is matched to the model and deployment scenario rather than treated as interchangeable: a set that suits a single-speaker recogniser is often the wrong shape for a two-party voice agent, and the difference is structural, not acoustic.

  • One speaker: isolated prompts, intent phrases, read speech where the use case needs it, spontaneous monologue, and speaker-specific pronunciation or acoustic evaluation.
  • Two speakers: natural dialogue, customer and support interaction, interviewer and respondent flows, voice-agent evaluation, turn-taking, interruptions, corrections, code-switching, short answers and context changes.

For three-or-more-speaker requirements, NaraDatum can assess existing supply, sourcing or buyer-funded collection feasibility where the deployment need and demand justify the additional participant, diarisation and QA complexity.

  1. Voice agents

    Voice agent evaluation, support and onboarding flows

    Two-speaker. This use case may require behaviour that scripted evaluation sets do not represent.

    The problem
    In deployed voice-agent workflows, buyers may need to evaluate behaviour such as barge-in, self-correction, short replies, intent changes, entity spelling, code-switching, recovery and call noise. Whether those conditions occur, and how frequently, must be established against the buyer’s traffic and evaluation brief rather than assumed from a general claim.
    A fitting dataset needs
    Two-speaker scenario conversations scoped to include relevant behaviours such as barge-in, interruption, self-correction, short replies, intent changes, entity spelling, recovery, code-switching, turn-taking and call noise, with the turn structure and speaker attribution needed for the agreed evaluation.

  2. ASR

    ASR training and evaluation

    One-speaker and two-speaker are different briefs and should be evaluated separately where turn boundaries, overlap or channel structure matter.

    The problem
    ASR performance can vary across accents, noise, code-switching and informal speech. Evaluation based only on clean or isolated utterances may not represent the buyer’s deployment conditions. Two-party audio also introduces turn boundaries, overlap and channel structure that should be tested separately where relevant.
    A fitting dataset needs
    One-speaker recognition and evaluation: isolated utterances and monologue across your accent range, with language tags, transcripts to the required convention, and stated recording conditions.Two-speaker conversational ASR: the same, plus speaker attribution, turn structure, whether overlap occurs and is marked, and the channel structure of the delivered files, mixed or separated, stated rather than assumed.

  3. Conversational AI

    Conversational AI, sales and product discovery

    The problem
    Conversational systems may need to handle ambiguity, incomplete information and changing context. Sales and product-discovery workflows can include comparison, exploration, unclear questions, intent changes and challenge. The relevant behaviours and evaluation criteria should be defined against the buyer brief rather than assumed to be present in a standard set.
    A fitting dataset needs
    Multi-turn conversations scoped around the behaviours named in the buyer brief, which may include topic shifts, partial information and correction loops across relevant personas and product-comparison scenarios.

  4. TTS

    TTS and voice synthesis

    Usually one-speaker, and the requirements are tighter than for recognition.

    The problem
    Conversational speech collected for recognition is not automatically suitable for synthesis. Properties such as overlap, variable distance, background noise, mixed channels and multiple voices can make material unsuitable for building a voice.
    A fitting dataset needs
    Tighter speaker identity, consent that explicitly covers voice synthesis, consistent recording conditions across sessions, clean signal quality, deliberate phonetic coverage, and controlled style or delivery. Suitability for synthesis is assessed separately from suitability for recognition and should not be inherited from it.

  5. Evaluation

    Targeted evaluation and multilingual benchmarks

    Built around buyer-observed or hypothesised risks, using the speaker and channel structure relevant to the evaluation.

    The problem
    A general benchmark can summarise average performance but may not diagnose buyer-specific issues such as a mid-sentence language switch or a misheard reference number on a noisy line. Code-switching and local speech behaviour may be absent or under-represented in a standard set, so the evaluation set should be checked against named deployment risks.
    A fitting dataset needs
    Evaluation sets scoped around named deployment risks rather than broad coverage: the accents, code-switch points, environments and speaker structures where performance needs to be measured, sized for repeatable comparison and held stable so a later run can be compared with an earlier one.

Deliveries can include structured metadata, QA records, consent references and delivery in agreed formats, depending on the agreed scope and on which route meets the requirement. Scope is confirmed with the buyer before any work begins.

Discuss your use case.

Tell us what you are building and what data the requirement calls for. We check existing supply first, then managed sourcing, and scope funded collection only where existing data cannot meet the requirement.

Submit a requirement