Speech Data RFP Template: What to Ask Vendors Before You Buy

A speech data RFP (request for proposal) is a short document that asks several vendors the same questions in the same order, so you can compare their answers line by line. Without one you get a spec sheet from one vendor, a price list from another and a sales deck from a third, and none of them line up.

This page goes one level deeper than our guide on how to buy speech data, which covers scoping, sample audits and contract basics. Here the focus is the RFP itself: what goes in each section, a template you can paste into an email or a procurement portal, a rubric for scoring the answers, and a way to compare off-the-shelf and custom quotes on the same footing.

We sell speech data ourselves, so we've kept the template vendor-neutral. It works the same whoever you send it to, us included. The structure also works as an AI training data RFP template for text or image data, but the spec and consent questions here are written for speech.

When to send an RFP, and when to just ask for samples

An RFP costs time on both sides. Vendors need a week or two to answer properly, and you need time to score the answers. It pays off when the purchase is complex, and it's overkill when it isn't.

Skip the RFP and request samples directly when:

• You need one language, and a catalog dataset already lists the spec you need.
• The vendor's standard commercial license fits your use.
• The budget sits below the level that triggers your procurement process.

Send an RFP when:

• You need several languages or dialects and want one comparable price table.
• Some or all of the data has to be collected to spec.
• You need exclusivity, voice generation rights or unusual delivery terms.
• Your procurement policy requires competing bids.

Either way, audit a sample before you sign. An RFP that doesn't ask for one is a price survey.

What to ask vendors in a speech data RFP

Five sections cover it. Keep the whole document to two or three pages. Short RFPs get faster and more careful answers than long ones.

1. Project background

Say what you're building and where it will run: a contact center ASR model on 8 kHz phone audio, a multilingual voice agent, a TTS voice or an evaluation set. Add what data you already have and when you'll decide. Vendors propose better data when they know the use, and a clear background lets them flag a mismatch early. Keep confidential details for a call under NDA.

2. Data specification

This is where most RFPs are too vague. Mark each requirement as a must-have or a preference, so a vendor that misses a preference can still propose.

• Languages, dialects and regions. Name the variety and where speakers should live. "Brazilian Portuguese, speakers living in Brazil" gets you comparable quotes. "Portuguese" could mean Lisbon, São Paulo or Luanda.
• Hours per language. Say whether you mean total audio or speech-only hours, and list the volumes you want priced. Our article on how much audio data you need to train ASR helps set the number.
• Speech type. Spontaneous conversation, read prompts, role-played calls or short commands. They train different behavior, so ask vendors to state exactly which one they're offering, and to confirm that every recording is a real speaker, not synthetic audio.
• Speakers and demographics. A minimum number of unique speakers per language, a cap on hours per speaker, and quotas for gender, age band and region.
• Recording conditions. Devices, environments, channel layout (mono, or one speaker per channel), sample rate, bit depth and codec. If you need both telephony at 8 kHz and wideband at 16 kHz or above, ask for them as separately priced options. Our guide to choosing a sample rate for speech data covers which rate, bit depth and channel layout fits each use.
• Transcription convention and accuracy target. Verbatim or clean, how fillers, overlaps, numbers and non-speech events are tagged, timestamp granularity, and an accuracy target with the method behind it, such as word error rate on a random subset re-transcribed by a second annotator. Ask vendors to attach their transcription guideline and say what share of files gets a second pass.
• Metadata schema. The fields you need per speaker and per recording. Ask vendors to attach their actual schema rather than describe it.
• Delivery format. Audio and transcript formats, folder structure, the delivery method and the batch schedule, plus a manifest that lists every file with its duration, speaker ID and checksum. The manifest is how you check delivered hours and file integrity at acceptance.

3. Legal terms

Ask the legal questions in the RFP, not after you've picked a winner. A vendor whose license doesn't fit is out, whatever the price.

• License scope. Training, evaluation and commercial deployment, including any models you ship to your own customers, and confirmation that you own the trained weights.
• Voice generation rights. If you're building TTS or voice cloning, consent to train a recognizer may not cover synthesizing a speaker's voice. Ask about it as a separate question.
• Exclusivity. Whether the data is also sold to others, and what an exclusive or time-limited license would cost.
• Consent documentation. The wording speakers signed, how consent records map to recordings, how withdrawals are handled, and whether the vendor recorded the data itself or sourced it from a partner.
• Data protection and security. Where speakers live, which law applies, how personal details spoken during conversations are handled, and how the data is stored and transferred. If the vendor will record or process audio on your behalf, ask for a data processing agreement (DPA). Our primer on voice data privacy and compliance covers consent, personal details in audio and redaction.
• Retention and deletion. What happens to the data, and to models trained on it, when the agreement ends.

Have counsel review the license and data terms before you sign. The RFP's job is to get those documents on the table early, while you still have alternatives.

4. Commercial terms

• Price per hour for each language at three volumes, such as 100, 500 and 1,000 hours, with what the price includes.
• Minimum order, plus volume and multi-language discounts.
• Timeline to the first batch and to full delivery.
• Sample terms: size, cost, and whether you choose the files.
• Acceptance criteria and remedies: the acceptance window, the quality thresholds, and what the vendor does when a batch fails.

You can fill in part of this before you write to anyone. SpeechData.ai, for example, lists the per-hour price and the spec on every page of its dataset catalog and sends free samples on request. Published numbers set expectations, but still ask every vendor for a written quote against your own spec.

5. Evaluation

Tell vendors how you'll score their responses and when you'll decide. Publishing the weights gets you structured answers instead of brochures, and it makes the final decision easier to defend inside your company. Ask for answers in the order of the questions, with prices in a fixed table.

The speech data RFP template

Copy this into an email or a procurement document, replace everything in square brackets, and delete what doesn't apply.

SUBJECT: RFP for [conversational speech data], [project name]
Responses due: [date]
Questions to: [email], by [date]

1. ABOUT US AND THE PROJECT
Company: [name, country]
Contact: [name, role, email]
We are building: [e.g. ASR for customer service calls]
Production audio: [e.g. 8 kHz phone calls, mobile app, in-car]
Data we already have: [none / X hours of language Y]
Decision date: [date]
Target first delivery: [date]

2. DATA SPECIFICATION ([M] = must-have, [P] = preference)
[M] Languages and dialects: [list, with regions where speakers live]
[M] Hours per language: [X], counted as [total audio / speech-only]
[M] Speech type: [spontaneous conversation / read / role-played calls]
[M] Real speakers only, no synthetic audio
[P] Topics or domain: [general / banking / healthcare / other]
[M] Unique speakers per language: at least [N]
[P] Max hours per speaker: [X]
[P] Demographics: [gender split, age bands, regional quotas]
[M] Recording: [devices], [environments]
[M] Channels: [mono / one speaker per channel]
[M] Audio format: [WAV], [8 / 16 / 48] kHz, [16]-bit
[M] Transcription: [verbatim / clean], tags for [fillers, overlaps, noise]
[P] Timestamps: [utterance / word] level
[M] Accuracy target: [e.g. WER under X% on an audited subset]
[M] QA: attach your transcription guideline; state the share of
    files that get a second pass and what triggers rework
[M] Metadata per speaker: [age band, gender, region, device]
[M] Manifest: every file with its duration, speaker ID, checksum
[P] Delivery: [formats], [method], [batch schedule]
Please list every point where your offer differs from this spec.

3. LEGAL
a) Does the license cover training, evaluation and commercial
   deployment of our models, including models we ship to our
   customers? Do we own the trained weights?
b) [If TTS or voice cloning] Does consent cover synthesizing
   the speakers' voices?
c) Is the data sold to others? Price for exclusivity, if offered.
d) Attach the consent wording speakers signed. How do consent
   records map to recordings, and how are withdrawals handled?
   Did you record the data yourselves or source it from others?
e) Where do speakers live, and which data protection law applies?
   Will you sign a DPA if you process data on our behalf?
   How is the data secured in storage and delivery?
f) What happens to the data and to our models when the
   agreement ends?
g) Attach your standard license agreement.

4. COMMERCIAL
a) Price per hour, per language, at 100, 500 and 1,000 hours.
   What does the price include?
b) Minimum order, volume and multi-language discounts.
c) Off-the-shelf or collected to order? Dates for first batch
   and full delivery.
d) Sample: size, cost, and can we choose the files?
e) Acceptance window, quality thresholds, remedies for a
   failed batch.
f) Payment terms and how long the quote is valid.
g) References from comparable projects, if you can share them.

5. HOW WE WILL EVALUATE
Spec fit 25%, sample audit 20%, consent and license 20%,
price per accepted hour 15%, transcription QA 10%,
timeline 5%, metadata and delivery 5%.
A failed consent or license check ends the evaluation.

Please answer in the order above by [date], with prices as:
Language | Hours | Price per hour | Total |
Off-the-shelf or custom | Delivery date

How to score vendor responses

Score each criterion from 1 to 5, multiply by its weight, and compare totals only among vendors that passed the consent and license check. Have two people score independently, then reconcile the differences.

Red flags in vendor responses

• The price question is answered and the license question isn't. A per-hour price with no license draft attached can't be compared with anything.
• "Hours" with no unit. If a quote doesn't say audio hours or speech hours, ask. For conversational recordings the gap can be large.
• Accuracy without a method. "99% accurate" means little until the vendor says what was measured, on which subset, and who checked it.
• A showcase sample. The vendor won't let you choose files, or the sample comes from a different corpus than the one quoted.
• Consent described as "publicly available" data or a terms-of-service checkbox. Neither is a speaker explicitly agreeing to have their voice used to train commercial models.
• A total that won't break down by language. A blended price can hide a thin language behind a strong one.
• Instant availability for a language the vendor doesn't list. If it really is on the shelf, ask when, where and how it was recorded.
• No remedy for a failed batch. "We'll look into it" is not an acceptance clause.

Comparing off-the-shelf and custom quotes on cost per accepted hour

Price per hour on its own is the wrong number to compare, because quotes include different things and you won't accept every hour delivered. Compare cost per accepted hour instead: the quoted price plus extras plus your own QA time, divided by the hours that pass your acceptance criteria.

Normalize first. Put every quote in the same unit (audio or speech hours) and the same license scope. A lower price for an evaluation-only license, or for audio without transcripts, is not a lower price.

Here is the calculation for two hypothetical quotes of 500 hours in one language:

The table assumes you pay for every hour delivered. If the contract makes the vendor replace rejected hours at its own cost, accepted hours climb back toward 500 and you lose only your QA time. That is why the remedy clause in the commercial section is worth negotiating.

The custom quote costs more per accepted hour, and that's normal. The question is whether the fit is worth the difference. If no catalog has your dialect, devices or acoustic conditions, the cheaper hours may train the wrong thing.

Two differences don't show up in the table. Off-the-shelf acceptance can be measured before you buy, by auditing a sample drawn from the actual corpus. Custom acceptance is a forecast, so ask for a paid pilot batch under the same acceptance criteria before you commit to the full volume. And custom collection takes weeks, so if a launch depends on the data, put the delay into the comparison too.

For custom quotes, ask each vendor to break the price down by recruitment, recording, transcription and QA. Our speech data pricing page lists the factors that usually move a custom price.