Short answer: estimate audio transcription API cost from measured seconds and the service's billing unit, then add retries and CRM summarization as separate tenant-level line items.
The useful answer is a tenant-level meter, not a guessed transcription rate. For a healthtech sales-call workflow, I would estimate spend from measured audio seconds, the provider's billing unit, retries, and downstream CRM summarization separately. That produces a number we can explain when a customer asks why this month's bill changed.
I started with a much simpler plan: multiply the average call length by a published per-minute number. It looked fine in a notebook. It became a poor operating rule as soon as calls had silence, uploads were retried, and one large tenant sent a different mix of recordings. The fix is a small ledger attached to each job, plus an evaluation set that catches transcription errors before an automated CRM action is allowed through.
The example below uses a healthtech sales team that turns recorded conversations into CRM tasks. The important measurement is not a universal price. It is the cost of one accepted, traceable workflow for one tenant.
What should a per-minute estimate actually count?
Start with a unit that the system can observe: billable audio seconds. Keep that separate from wall-clock processing time and from the number of CRM actions. A five-minute file can take longer than five minutes to process, and a failed attempt can consume compute without producing an accepted result. Those are different facts.
For an initial estimate, define:
estimated_workflow_cost = transcription_cost + summary_cost + retry_cost + storage_and_transport_cost
The transcription term is the only one that should be derived from the audio rate:
transcription_cost = ceil(audio_seconds / billing_seconds) * rate_per_billing_unit
The ceil matters when a service bills partial units as whole units. If the service uses another rule, encode that rule explicitly in the adapter and test it. Do not hide it inside a spreadsheet formula that no one can review later.
Here is a deliberately vendor-neutral record for one completed attempt. The rate is configuration supplied by the account or contract, not a claim about any particular API.
from dataclasses import dataclass
from decimal import Decimal, ROUND_CEILING
@dataclass(frozen=True)
class AudioMeter:
tenant_id: str
call_id: str
audio_seconds: int
billing_seconds: int
rate_per_unit: Decimal
attempts: int
def transcription_cost(self) -> Decimal:
units = (Decimal(self.audio_seconds) / Decimal(self.billing_seconds))
billed_units = units.to_integral_value(rounding=ROUND_CEILING)
return billed_units * self.rate_per_unit
meter = AudioMeter(
tenant_id="tenant-047",
call_id="call-2026-04-1182",
audio_seconds=347,
billing_seconds=60,
rate_per_unit=Decimal("0.00"), # Inject the current contract rate.
attempts=1,
)
print(meter.transcription_cost())
The zero placeholder is intentional. A code sample should not smuggle in a stale price and make it look authoritative. In production, the rate record needs an effective date, currency, billing unit, and source reference. Store the rate used for each job so a later invoice reconciliation does not depend on today's configuration.
Why did the first estimate drift?
The common failure is averaging away the boundary that matters. If a tenant submits 100 calls, the aggregate minutes may look stable while the billed units move because each file is rounded independently. A second failure is charging a retry twice in an internal report without distinguishing a transport retry from a new transcription attempt. A third is assigning the full workflow cost to the team that clicked the CRM button instead of the tenant whose audio created the work.
I would record an immutable event for every attempt and a separate acceptance event for the transcript or CRM action. The event should include tenant ID, call ID, audio duration, billing duration, attempt number, outcome, model or engine identifier if available, and the rate version used for the estimate. It should not include the raw recording in the cost ledger.
That gives operations two useful views. The invoice view answers, “How many billable units did this tenant create?” The quality view answers, “How many accepted CRM actions came from those units?” Mixing them makes both harder to trust.
A compact aggregate can be produced from the same records:
from collections import defaultdict
from decimal import Decimal
def summarize_cost(events: list[dict]) -> dict[str, Decimal]:
totals = defaultdict(Decimal)
for event in events:
if event["kind"] != "transcription_attempt":
continue
if event["outcome"] != "accepted":
continue
totals[event["tenant_id"]] += Decimal(event["cost"])
return dict(totals)
This is notebook-sized code, which is useful at the beginning. The production boundary is the event contract, not the aggregation function. Once the contract is stable, the same fields can feed a batch report, a queue consumer, or a warehouse query without changing the billing meaning.
Which quality signals belong beside the cost?
A low-cost transcript that creates a wrong CRM task is not a successful unit of work. For sales calls in healthtech, evaluation should cover at least transcription fidelity for domain terms, extraction of the next action, and refusal to invent a commitment that was not spoken. The exact test set belongs to the business and should be versioned like code.
I keep a small, fixed evaluation slice in the deployment path: short calls, long calls, overlapping speakers, accents represented in the permitted data, and calls containing medication or product names. Each case has a reference transcript or an adjudicated action set. The gate is a joint one: quality must clear its threshold, and cost must remain inside the tenant budget envelope.
That makes the decision rule concrete:
def accept_result(
transcript_score: float,
action_score: float,
tenant_spend: Decimal,
tenant_budget: Decimal,
) -> bool:
quality_ok = transcript_score >= 0.92 and action_score >= 0.95
budget_ok = tenant_spend <= tenant_budget
return quality_ok and budget_ok
The thresholds above are example policy values, not universal facts. They must be calibrated against reviewed calls and the harm of a wrong CRM action. A cost gate without a quality gate rewards silent failure; a quality gate without a cost gate makes a good evaluation set irrelevant to account-level operations.
There is a practical privacy boundary here too. The ledger can retain duration, hashes, status, and monetary fields while the transcript and recording follow the application's retention policy. Access to debugging samples should be narrower than access to aggregate spend. Cost observability does not require copying sensitive conversation content into every dashboard.
How do I make the estimate survive deployment?
Treat rate configuration as data with a review path. A rate change should produce a visible version change, not silently rewrite historical jobs. Keep the currency explicit. Keep audio duration measured at ingestion and validate that it is non-negative, finite, and within the file's decoded duration. Rejecting a malformed measurement is cheaper than publishing a confident invoice error.
Retries deserve their own policy. A transient upload failure may be counted as transport work; a second completed transcription attempt may be billable work; a human-requested reprocess may belong to a different cost center. The adapter should emit these distinctions rather than forcing finance to infer them from log messages.
For a tenant-level estimate, report a range until the workflow has enough observed data:
def estimate_range(
observed_seconds: list[int],
rate_per_minute: Decimal,
retry_fraction: Decimal,
) -> tuple[Decimal, Decimal]:
if not observed_seconds:
raise ValueError("at least one observation is required")
base_minutes = sum(observed_seconds) / 60
base = Decimal(str(base_minutes)) * rate_per_minute
high = base * (Decimal("1") + retry_fraction)
return base, high
This is a planning range, not an invoice calculator. Once real events arrive, replace the range with the observed distribution of billed units and accepted actions. The useful dashboard shows p50 and p95 audio duration, billed units per call, retry share, accepted-action rate, and spend by tenant. A single blended average conceals the tenants that need attention.
The same design also keeps the runtime portable. The transcription adapter exposes measured duration, outcome, and billing metadata; the summarizer consumes text and a schema for CRM actions. Function calling can represent structured action arguments, while a local open-model runtime can be evaluated separately when the team chooses to run an eligible component on its own infrastructure. Neither choice changes the cost ledger's contract.
The trade-off is real. A hosted API usually reduces operational work and gives a clearer starting path, but the account still depends on its billing semantics and service availability. A self-hosted runtime can make infrastructure and data boundaries more controllable, but the team owns capacity, upgrades, and quality evaluation. A hybrid split adds routing and observability work. None is a universal winner.
| Approach | Best fit | Cost-estimation boundary | Main limitation |
|---|---|---|---|
| Hosted transcription API | Teams optimizing for fast integration | Provider billing units plus retries | External billing and availability rules |
| Self-hosted speech runtime | Teams with suitable operations capacity | Compute, storage, and utilization events | Capacity planning and model maintenance |
| Hybrid routing | Workloads with clear data or latency tiers | Per-route events joined by tenant | More routing and evaluation paths |
This ledger is a poor fit for a throwaway prototype with no tenant accounting requirement. For that case, the event contract can be excessive. It becomes worthwhile when an automated CRM action, an account budget, or a compliance review depends on the result.
The decision rule I would ship
Use per-minute estimates for planning, but bill and alert from per-attempt, per-tenant events. Attach the current rate version to every estimate. Evaluate transcript quality and CRM-action quality on a fixed set before promoting a prompt or runtime change. Then compare actual spend to accepted business output, not to audio duration alone.
That approach takes a little more bookkeeping than multiplying average minutes by a headline rate. It also survives the questions that arrive after launch: why one tenant rose, whether retries caused it, whether quality improved, and which configuration produced the number. Those are the questions a cost estimate must answer.
Sources
- OpenAI, “Function calling”: https://platform.openai.com/docs/guides/function-calling
- Ollama, local open-model runtime: https://ollama.com
- OpenTelemetry documentation: https://opentelemetry.io/docs/
- W3C Web Audio API: https://www.w3.org/TR/webaudio/
Top comments (0)