The constraint that changes this choice is provider portability. A sales-call transcript is an intermediate artifact, not the product: the useful output is a small set of CRM actions that can survive a transcription provider change. For a Node.js application accepting MP3 and WAV uploads in the US and EU, the fastest integration is the one with a narrow adapter, an explicit regional policy, and an eval set that includes the awkward recordings.

Short answer: use a simple speech-to-text API behind a provider-neutral upload interface, persist the original audio and normalized transcript separately, and choose the US or EU processing path only after checking the provider's current data-location terms. A five-minute demo is not evidence of a portable integration.

This is the notebook-to-prod boundary I care about: the first transcript should be easy to obtain, but the second provider should also be easy to plug in.

Why does a sales-call transcript need more than a working upload?

The tempting implementation sends a file to an API, reads a text field, and immediately asks another model to write a CRM note. It looks fast. It also hides where the system made an irreversible decision.