30-Day Conversation Intelligence Pilot on your own calls

A short, fixed-scope build that runs transcription and language-model processing over a slice of your real calls or meetings and produces one agreed structured output. Elsewhere the same thing is sold as a proof of concept, or POC.

A useful one ends in three things:

• the pilot itself, running on your own data
• an honest accuracy read against examples you can check
• a scoped, costed plan for the production build

Ours takes 30 days.

Fixed scope and fixed price, both agreed in writing before we start. That is the fixed-price model rather than time and materials.

Scope is what moves it. A pilot on a thousand support tickets and a pilot on regulated advice calls are not the same engagement, so we quote once we know which conversations are in and which output you want proven.

Four to ten hours of your team's time in total, depending on the offer, is what our fixed-scope engagements ask as a set.

On this one that is:

• a technical contact to arrange access
• someone who knows the domain vocabulary well enough to tell us when the output is wrong
• a few hours of real use in week four
• a working session at the readout

Transcription, processing and the security setup around your data are ours.

NDA before any access. For the assessments and audits we work from read-only, least-privilege access, agreed with your technical contact before anything starts. A pilot runs on the same terms: read-only access to the sample in scope, nothing granted before the NDA.

Where transcription and processing run, what is retained, and what happens to the sample after day 30 are settled before any audio moves, under our ISO 27001:2022 certified practices. Prompt injection, data leakage and model access are part of the setup rather than a review afterwards.

No model is trained on your recordings as part of the pilot. Producing the agreed output takes transcription plus prompting on existing models, so nothing in the 30 days requires it.

That leaves the providers in the pipeline, which we settle at scoping rather than afterwards: which service transcribes, which model processes, what each retains, and what its terms say about customer data. You see that list before any audio moves.

You do, and it stays yours: under GDPR the recording notice and lawful basis sit with you as controller.

So we pilot on what you already hold lawfully and scope around the rest:

• a sample your existing recording notice covers
• redaction before anything leaves your systems, where the sample is sensitive
• a freshly consented set, where the archive will not carry it

Our project managers and engineers work from Ukraine, Poland, Estonia and the UK, four of the six countries the team spans, so GDPR is our own regime too.

Then that is the finding, and 30 days is a cheap way to reach it.

The accuracy read is written to be usable either way: where the pattern holds on your audio, where it breaks, and whether the gap closes with better prompting, a different model, cleaner source audio, or not at all. Some conversation data is too noisy or too thin for the output someone hoped for, and a month is the right amount to spend finding that out.

Usually not, and that is deliberate. Integration is the expensive half and it proves nothing about whether the output is any good, so the 30 days go into the part that is actually in question.

What you get instead is the output in the shape your system would consume, plus the integration points named and costed in the build plan. If a specific integration is the thing you need to see working, say so at scoping and we build the pilot around it.

If it proves the value, the pilot becomes the brief for a production build inside your systems, and nothing is thrown away: the pipeline, the prompts and the evaluation set all carry forward.

If it does not, you have an evidence-backed reason not to spend further, which is a good outcome for a month. Either way the output is yours and the decision is yours, including if the production build never comes to us.