Twenty Minutes, Not Two Quarters: The Integration Gap That Kills QA Deals

The objection that is never about money

Ask why a call-QA evaluation stalled and the stated reason is usually budget. It usually is not.

The realistic blocker is that adopting the tool looks like a project:

• a dialler integration, which needs the telephony vendor,
• an IT ticket, which joins a queue,
• agent accounts provisioned, which needs HR data,
• change management, because agents are being told about a new system,
• and an evaluation phase that slips two quarters because the telephony vendor’s API needs a contract amendment before anyone can test anything.

None of those steps is unreasonable. Together they mean the earliest possible date on which anyone sees a single insight is five months out.

And the compliance risk the tool was bought to address does not pause for the integration. It accrues daily, throughout, at exactly the rate it did before the purchase order was signed.

The project was approved to reduce a risk, and the shape of the project guaranteed the risk would run unmitigated for two more quarters.

Why the category is built this way

Because vendors integrate where the value is highest for them.

The dialler is the most valuable place to sit. Real-time access, agent-desktop presence, the ability to intervene mid-call, and a genuinely defensible position once you are there. It is also the hardest place to reach — every dialler is different, most APIs are contractually gated, and the telephony team is not the buyer and has no reason to prioritise you.

The result is a category whose time-to-first-insight is measured in months, and whose evaluations die of attrition rather than rejection.

What we changed: ingest from where the recordings already are

The dialler is already writing recordings somewhere. That location is the integration.

Point the platform at the bucket or folder and it takes over from the next scan. No dialler API, no agent logins, no change management, because nothing about the agent’s day changes.

Six connectors: Google Drive, Amazon S3, Dropbox, Box, GCP Bucket and Wasabi. OAuth pop-up for the first three; bucket policy, service-account key or access-key pair for the rest.

Scheduled scans: none, 4h, 8h, 12h or 24h, with the last-run time always visible and a Run Now button to force a scan when you do not want to wait for the schedule.

Setup time: about twenty minutes, once.

Four further paths on top of that, because storage is not the only way calls arrive:

• browser drag-and-drop — MP3, WAV, WEBM, MP4, M4A, OPUS,
• a bulk API endpoint for CRM or dialler integration, which takes a list of audio URLs and fetches each one itself,
• a public quick-trial funnel for a single file,
• agent self-upload, where the workflow calls for it.

The part worth stealing: read the filename

Call metadata — agent name, call direction, call time — is parsed out of the filename, using a pattern configured per workspace.

Diallers already encode this. A file named OUT-4004-20240624-945FE09735344905AB7153A8D414F371.wav is telling you the direction, the extension, and the date, and it has been telling you since before anyone considered buying QA software.

The alternative designs are both worse. Demanding the customer change their naming convention puts the telephony team back in the critical path — the exact thing this was meant to avoid. Demanding a metadata feed means building an integration, which is the other thing. Reading what is already there costs a configuration field.

For richer metadata there is an export–annotate–re-upload loop: export the call list with IDs, join your CRM’s campaign, queue and disposition fields to it in a spreadsheet, upload it back, and those fields become filterable. Campaign-, queue- or disposition-aware QA without writing an integration.

What we do not claim

We do not claim real-time. This is batch. Recordings are picked up on a schedule and analysis follows overnight; the weekly report is the deliverable. If your requirement is agent-desktop intervention mid-call, this is the wrong architecture and you should evaluate a dialler-embedded product.

We do not claim every storage provider. Six are wired and listed above. If your recordings live somewhere else, the honest answer is the bulk API endpoint or a sync into one of the six — not a roadmap promise.

We do not claim zero IT involvement. Somebody with permission to grant access to a bucket has to grant it. That is one person, once, for about twenty minutes — but it is not nobody.

Where to start

The diagnostic question for your own environment: where does your dialler write recordings today, and who has read access to it?

If you can answer that in a sentence, most of the integration work is already done. If you cannot, that answer is worth having regardless of what you buy.

Book a demo and we will walk you through the connector setup and the filename pattern on a real folder layout.

---

Related: Mono, Stereo and the Honest Answer on what those recordings need to contain, and Software That Needs a Team You Do Not Have on what happens after they arrive.