Send your recordings and get back two-sided transcripts with timestamps: agent on one side, customer on the other, every line searchable. The reviewing is still yours — this is the layer that makes it possible at volume.
speaker labels · timestamps throughout · 100+ languages · your recordings are never used to train a model
A reviewer can listen to maybe six calls an hour, so a queue of two hundred gets sampled — usually the shortest ones, or whichever came in last. The calls that actually matter are the 40-minute ones nobody has time for. Read instead of listen and the sample stops being the constraint.
Upload files, paste a public URL, or submit from wherever your recordings already land — POST /api/v1/transcribe for a file, POST /api/v1/transcribe/url for a link. The Chrome extension records the audio of a call playing in a browser tab, or your own mic, when there's no file to hand.
Speaker diarization splits the call into labelled turns, so the agent's words and the customer's words are visibly separate and you can follow who escalated first. Timestamps run the whole way through.
A summary and chapters turn a 40-minute call into something you can triage in a minute — then jump to the part that decides whether it needs a full review.
Type a phrase and get every line in the call that contains it, each with its timestamp. Competitor names, "refund", "cancel", a policy phrase your team is supposed to use — find it instead of hoping you hear it.
“Where in this call did we promise a refund?”Ask a question about the call and the answer cites timestamps you can click — the transcript jumps there and the audio plays from that line, so a reviewer verifies the quote before it goes in a coaching note.
Labelled turns, clickable timestamps, and the search term highlighted where it occurs.
Illustrative example. Diarization separates voices as SPEAKER_00 and SPEAKER_01; which one is your agent is a mapping you make once per call, not something the model is told.
The calls that ended badly are the long ones. Read the transcript, find the minute where it turned, and quote it exactly in the write-up.
Search a call for the disclosure your team is required to read, or for the promise it isn't allowed to make. One search per call beats one listen.
Find every call where a competitor came up and read the objection in the prospect's own words rather than a rep's paraphrase in the CRM.
A coaching note built on a quoted line with a clickable timestamp lands differently from one built on "I felt like you rushed her".
Over 100 languages, and the transcript stays in the language the call was in — so a reviewer who speaks it can read it, and search ignores accents.
Pull each transcript as JSON with per-segment speaker and timing and write it into the tool your scores already live in.
This is the transcript, search and summary layer. It does not score calls, rate agents, compute a sentiment number, fill a QA scorecard, or push into a CRM — there is no such feature, and a page that implied otherwise would waste your evaluation. Your rubric, your spreadsheet, your BI tool.
It also doesn't join calls. No bot dials into a meeting and nothing is transcribed live: you send recordings and get transcripts back asynchronously. Transcription is machine-generated and weakest on names, figures and product jargon — listen to the line before you quote it in anything that affects someone's job.
If recordings land in a bucket or a telephony provider's storage, submitting them is one call per recording. Poll, then pull the transcript.
# submit a recording that's already reachable by URL
curl https://whipscribe.com/api/v1/transcribe/url \
-H "X-API-Key: $WHIPSCRIBE_KEY" \
-H "Idempotency-Key: call-88213" \
-H "Content-Type: application/json" \
-d '{"url":"https://recordings.example.com/call-88213.mp3","diarize":true,"source":"api"}'
# then poll GET /api/v1/jobs/{job_id} until status is "done", and read
# GET /api/v1/jobs/{job_id}/result?format=json → text, language, segments[]
diarize is what gives you the two-sided transcript. Idempotency-Key keeps a retried submit from creating a second job for the same call. Full reference in the API docs; keys are issued from /keys, and an agent can query transcripts directly through the MCP server.
Priced per minute of audio, so the bill tracks the queue rather than the headcount. Credits don't expire.
| Plan | Price | Minutes | Roughly |
|---|---|---|---|
| Starter | $4 | 300 | 5 hours — a spot-check habit |
| Pro | $12 | 2,000 | 33 hours — one reviewer's month |
| Team | $24 | 5,000 | 83 hours — a small support floor |
Worked example: 25 calls a day averaging 8 minutes is 200 minutes a day, 1,000 minutes across a five-day week, about 4,000 minutes a month — inside Team's 5,000 minutes at $24. A queue half that size fits Pro's 2,000 minutes at $12. Full pricing →
Take the longest recording in the queue, put it through, and see whether reading it beats listening to it. That's the whole evaluation.
Transcribe a call →No — no scorecard, no sentiment score, no agent-performance dashboard. It produces the diarized, timestamped, searchable transcript those workflows read from. If someone tells you a transcription engine is measuring empathy, ask to see the rubric.
No. No bot dials in, nothing is transcribed while it's happening. You send recordings — upload, URL, or API — and get transcripts back asynchronously.
It separates the voices and labels the turns. It doesn't know which voice is your employee, so you map speaker to role once per call — usually obvious from the first line.
No packaged app. There is a REST API, so writing transcripts back into your own system is a short integration rather than a purchase. See /docs.
They're transcribed on our own GPUs running open-source Whisper — not handed to a third-party transcription vendor, and never used to train a model. Audio is deleted after the retention window for your plan; the transcript stays until you delete it. Details on /security.
Up to 10 hours per file, which is longer than any call anyone wants to review. Timestamps and speaker labels run the whole way through.