BYOK cloud transcription for consultants - different provider per client, all under your control
Consulting engagements rarely have one cloud-provider policy. Some clients mandate Azure OpenAI under their tenant; others insist on Anthropic on Bedrock; a few have no preference. You can configure a different provider and key per engagement, so each client's audio only touches the provider their contract permits.
When a cloud provider is the right call
When a client's data-processing agreement names a specific provider, your transcription workflow needs to match. Most generic tools force you into one vendor for every client. With BYOK, the provider and key are per-engagement settings: swap them between calls if you have to.
We don't hold or provision the API keys. You supply each one: your own BYOK key, the client's issued key, or an org-provisioned key your IT shares with the team. We route the call to that provider under that provider's terms. Org-provisioned keys are supported too; IT can issue a shared OpenAI, Google, or other key and the team uses it where the contract allows.
Transcripts always write to local DuckDB on your device. The audio processing happens at the provider you configured; the transcript comes back and writes locally, scoped to the session or folder structure you set up for that engagement.
How it works
- Before the engagement, identify the provider and API key the contract requires: your BYOK key, a client-issued key, or an org-provisioned key.
- Configure that provider and key for that engagement.
- Swap the provider and key between engagements, or between calls in the same session, to match each client's contract.
- Record the client call. We route the audio to the configured provider; transcription and summary happen under that provider's terms.
- The transcript writes locally to DuckDB, scoped to whatever session or folder structure you maintain for that client.
How it compares
| Aspect | On-device transcription | Generic cloud transcription, fixed provider | jotty.pro cloud BYOK, per-engagement |
|---|---|---|---|
| Per-client provider flexibility | No, transcription is always on-device | No, one vendor for every client | Yes, different provider and key per engagement |
| Contract alignment | N/A; no external provider involved | Hard; one provider must satisfy every client | Matches each client's contract; swap as required |
| Transcript residency | Local DuckDB on your device | Varies by vendor; often retained in vendor systems | Local DuckDB on your device |
| Key custody | No API key needed | Vendor holds credentials; you have none | You hold the key (personal, client-issued, or org-provisioned) |
Honest answers
Can I switch providers between client calls?
Yes. You can change the provider and API key at any time. Configure one provider for the 9am call and a different one for the 2pm call if the contracts demand it. No restart required.
What if a client mandates we use their own cloud tenant?
If they hand you an API key for their Azure OpenAI deployment, Anthropic Bedrock setup, or another endpoint we support, paste it in and we route to that tenant. We don't provision or intermediate the key; it goes straight to the provider endpoint the client's key authorizes.
How do we keep client transcripts separated?
Transcripts live in local DuckDB. Today, separation is at the session and folder level inside DuckDB. We don't yet have dedicated client-workspace isolation beyond what you organize yourself, so use distinct folders or naming conventions per engagement to keep client A's transcripts apart from client B's.
If a particular client doesn't allow any external processing, keep client calls on-device. Pair it with the cloud-provider path for the clients that explicitly approve a provider.