Why it matters
Every call your recorder exports is transcribed and scored against your rubric. That changes what you can ask of the record: whether the disclosure was read on all of a campaign's calls, which of them a reviewer should hear, and how a new agent's third week compares to their first. Calls that arrive truncated or unreadable are named on the coverage screen, so the number you report is the number that ran.
Getting calls in is an export setting. Call1 runs an S3-compatible endpoint on the box, your recorder writes post-call audio to it, and transcription starts on the audio alone. Most recorders already have that export configured for some other destination.
Your recorder already holds the master recording for the legal retention window. Call1 needs the audio long enough to transcribe it, score it, and let a reviewer play back the moment a check fired on. The transcript, the scores, the evidence spans and every adjudication stay; the working copy leaves on the schedule you set.
How it works
- 01
Your recorder writes the file
Post-call audio lands in an S3-compatible bucket that runs on the box, reachable on your network or over the remote path you operate when the recorder sits elsewhere. The object key carries the call ID, and often the date, agent and direction with it. The same file dropped twice is deduplicated on object identity and content, so a recorder retry or a corrected re-export does not score the call again.
- 02
The session opens on the audio alone
Audio is enough to create a partial canonical session record and enter transcription. Metadata can arrive before it, after it, or never.
- 03
The pipeline runs on the box
Transcode to Opus, split the speakers (by channel when the export is dual channel, by diarization when it is mono), transcribe with timestamps, then scan the transcript for PII and card numbers, mute those spans in the audio and tokenize them in the text. Your rubric runs against the result.
- 04
Metadata arrives on your schedule
A filename convention covers call ID, agent and direction with no integration at all. A per-call sidecar or a scheduled CDR export from a report your platform already produces adds team, campaign, disposition and customer reference. You map your columns once; the accepted mapping template is versioned, and every session record carries the version that populated it. Columns the template does not map are kept raw, so re-mapping later is a reprocessing job rather than a fresh request to whoever ran the export.
- 05
The working audio leaves
Processed audio is encrypted with your keys and routed to the destination you picked: your bucket, your NAS, or local disk. A hot cache on the box keeps the calls currently in the review queue so playback is instant, and the rest expires on your retention number. Transcripts, scores, evidence spans, embeddings and adjudications remain.
Technical shape
Inputs
Post-call audio through the S3-compatible endpoint on the box. WAV is the baseline; format normalization happens downstream. Dual-channel export puts the agent on one side and the caller on the other, which makes speaker attribution a channel read. Mono is supported through diarization.
Correlation
The call ID appears in the object key and in the metadata source, and either half can land first. A bulk export re-delivers rows you have already seen, so correlation is a row-level upsert on call ID. A metadata row with no audio behind it is held as a partial record and reported with the join match rate in the import report.
Canonical session record
Timestamp, direction, agent, queue or campaign, hashed caller numbers, duration, disposition, customer reference, channel layout, the unmapped columns, and the provenance of every enriched field. Scoring, the workbench and exports all read this record, so none of them carry your platform's schema.
Outputs
A speaker-aligned transcript with word and chunk timestamps, check results with the evidence span behind each verdict, affect signals, audio events, and the routing status of the working audio. You decide which audio artifact is retained and where it lives.
Data boundary and privacy
Call1 processes a working copy inside your boundary. Your recorder stays the system of record for the recordings themselves.
The ingest endpoint, the transcription engine, the models, the database and the working object store run inside the boundary you choose. No recording and no transcript needs to reach a Call1-operated service to be processed, and we hold no standing access to any of it.
The archive destination is your account, under your encryption keys. Playback for your reviewers needs decryption capability on the box or in your KMS; it never sits with us.
Keeping the transcript, the scores and the evidence while the working audio expires cuts how much sensitive material sits on the appliance, and a reviewer opening a three-month-old adjudication still sees the words the check fired on.
Performance
Capacity is quoted in call-hours a day
We size against your hardware, your audio mix, your rubric and the analysis modules you switch on. The commitment is call-hours a day and a maximum processing lag. Expedited calls score in minutes; everything else is there by morning.
Audio does not wait for metadata
A sidecar that lands late, or a CDR export that runs overnight, holds nothing up. The expensive audio work starts when the recording lands and enrichment catches up on its own.
Dual-channel export is one setting on the recorder
Flipping it removes the diarization work on every call after it, which buys throughput and cleaner speaker attribution in the evidence a reviewer reads. We ask about it in the first onboarding call.
Storage tracks the flagged slice
Transcoded audio is several times smaller than the WAV your recorder handed over, and audio is held through the appeal window only for calls that were flagged, overridden or disputed. Your storage footprint stops following call volume.
What it doesn't do
- Coverage is post-call. Call1 scores a recording after the call ends. Nothing here listens to a call in progress or prompts an agent mid-call.
- Call1 is not your telephony recorder and does not replace your legal system of record. Your platform keeps the master recording and the multi-year obligation attached to it.
- Long-term recording retention is sized and paid for on your side. The appliance holds the working copy and the hot cache.
- Redaction is post-call. A card number spoken aloud is muted in the audio Call1 routes and tokenized in the transcript it keeps. The copy your recorder already wrote upstream is untouched, so this does not reduce that recorder's PCI scope.
- Platform adapters are built one at a time, for a deployment that needs one. Until yours exists, metadata comes from the object key, a sidecar, or a scheduled export.
What to validate before deployment
- 01
How many call-hours a day, and what does the busiest arrival window look like?
- 02
Which formats and sample rates does your recorder export, and can it be switched to dual channel?
- 03
Which metadata fields have to be on the record at score time, and which can arrive with the overnight export?
- 04
Where should processed audio land, whose keys encrypt it, and how many days should the working copy stay on the box?
- 05
Who reads the coverage exceptions and the import report, and what happens when a bulk export joins to only a fraction of the landed audio?