[VENDOR_NAME] Vendor Evaluation¶
Status: Evaluation for potential [ASR/TTS] backend
Date: TBD
Context: [Brief statement of decision being made. Example: "Evaluate as third cloud ASR backend following Deepgram and AssemblyAI," or "Evaluate as alternative TTS to ElevenLabs."]
1. Pricing¶
[Vendor name] uses a [pricing model description] — [one-sentence explanation of billing mechanics].
Reference: [URL to pricing page] (verified [DATE])
Rate structure¶
| [Dimension] | [Rate/Unit] |
|---|---|
| [Feature/Mode] | [TBD: $X.XX/min or equivalent] |
| [Feature/Mode] | [TBD: $X.XX/min or equivalent] |
[One or two sentences explaining how rates compound, gotchas (separately-metered features, rounding, minimum charges), and free tier or trial availability.]
Effective per-minute cost (baseline scenario)¶
| Mode | Cost per minute | Cost per hour |
|---|---|---|
| [Primary mode] | ~[TBD: $X.XXX] | ~[TBD: $X.XX] |
| [Secondary mode] | ~[TBD: $X.XXX] | ~[TBD: $X.XX] |
[Reference the vendor's own stated equivalents or your calculation method. Example: "Vendor's stated equivalent: '$X/hour for [mode]' (https://..., [DATE])."]
Vendor cost comparison¶
| Vendor | $/min [primary] | $/min [secondary] | Diarization |
|---|---|---|---|
| [Incumbent 1] | [TBD] | [TBD] | [TBD] |
| [Incumbent 2] | [TBD] | [TBD] | [TBD] |
| [New vendor] | [TBD] | [TBD] | [TBD] |
[One sentence comparing: cheaper/parity/more expensive, and relative scale of difference if material.]
2. Accuracy¶
[Vendor name]'s published benchmarks or positioning on accuracy.
Reference: [URL to benchmarks or benchmark discussion] ([DATE])
Positioning¶
[One paragraph: what dataset or scenario the vendor claims strength in (e.g., clean English, multilingual, accented speech). Include WER or CER numbers if published. Note whether benchmarks are vendor-self-conducted, third-party, or both.]
Caveat: [If self-conducted: "This is vendor-self-conducted."] [Note any limitations: "Independent third-party replication [has/has not] been confirmed."]
3. Features¶
Feature table¶
| Feature | Available | Notes |
|---|---|---|
| [Feature 1 — e.g., Diarization] | Yes/No | [Pricing or availability notes] |
| [Feature 2] | Yes/No | [Pricing or availability notes] |
| [Feature 3] | Yes/No | [Pricing or availability notes] |
| [Feature 4] | Yes/No | [Pricing or availability notes] |
Reference: [URL to feature docs or API reference] ([DATE])
[One or two sentences highlighting what is bundled vs. separately metered, and how the feature set compares to incumbents.]
4. Compliance and SLAs¶
Reference: [URL to security/compliance docs] (verified [DATE])
| Standard | Status | Notes |
|---|---|---|
| SOC 2 Type 2 | [Yes/No/In Progress] | [Certification date or link if available] |
| ISO/IEC 27001 | [Yes/No/In Progress] | [Year if available] |
| GDPR | [Compliant/Not stated] | [Notes on data residency endpoints if relevant] |
| HIPAA | [Compliant/BAA availability/Not stated] | [Conditions if any] |
| [Data residency] | [Regions available] | [Endpoint URLs if applicable] |
[One paragraph on: data handling commitments (e.g., "Audio is never used to train models"), data retention, SLA terms (uptime %, incident response). Note if SLA terms require sales contact.]
5. API Surface and SDK¶
Reference: [URL to API docs or GitHub SDK org] ([DATE])
Endpoints and auth¶
| Mode | Endpoint | Auth method |
|---|---|---|
| [Batch/Streaming/etc.] | [URL pattern] | [Bearer token/API key/etc.] |
| [Mode 2] | [URL pattern] | [Bearer token/API key/etc.] |
[One or two sentences on: request shape, sample rates, max concurrent streams (if documented), max audio length per request.]
SDK availability¶
| Language | Available | Quality/Notes |
|---|---|---|
| Python | [Yes/No] | [Link, stars, active?] |
| JavaScript/TypeScript | [Yes/No] | [Link if available] |
| Go | [Yes/No] | [Link if available; note if no official SDK] |
| [Other language] | [Yes/No] | [Link if available] |
[One sentence noting gaps and implications — e.g., "No official Go SDK exists; integration would require REST client only."]
6. Integration Effort¶
[Describe the integration path as it relates to Vox's existing adapter pattern (internal/asr/ or internal/tts/).]
Estimated effort:
| Scope | Days |
|---|---|
| [Component 1 — e.g., Batch adapter] | [TBD: 0.5–2] |
| [Component 2 — e.g., Streaming adapter] | [TBD: 0.5–2] |
| Tests (unit + integration scaffolding) | [TBD: 0.5–1.5] |
| [Specific integration — e.g., Billing meter wiring] | [TBD: 0.25–0.5] |
| Docs | [TBD: 0.25–0.5] |
| Total | [TBD: 2–5] |
[One paragraph: reusable patterns from existing adapters, new dependencies required, and any surprises.]
7. Recommendation¶
[Ship / Defer / Pass] — [priority if shipping, or reason if deferring/passing].
Rationale:
- [Point 1 — e.g., price advantage, compliance strength, feature differentiation]
- [Point 2]
- [Point 3 — if relevant, note risks or gaps]
[Optional: recommended priority relative to other backlog items or incumbent vendors.]
8. Open Questions for Sales Conversation¶
- [Question 1 — e.g., "Is HIPAA BAA available on self-service plans, or enterprise-only?"]
- [Question 2 — e.g., "What is the rate floor at [projected volume]?"]
- [Question 3]
- [Question 4]
- [Question 5]
Notes¶
- Author: [Name]
- Operators: For numeric claims, always cite the source URL and verification date. Do not leave TBD placeholders in a shipped evaluation.
- Assumption: This template assumes a single-vendor deep-dive. For multi-vendor comparisons, see
asr-vendor-landscape-2026-05.md.