Fixa Trade Automation

AI Receptionist Transcription Accuracy: What Telnyx's October Fix Means for ServiceM8 Job Cards

Fixa Team22 Oct 202612 min read

AI receptionist transcription accuracy is the measure of whether the system answering your phone actually understood what the caller said. It has nothing to do with how natural the AI's voice sounds and everything to do with whether "34 Burleigh Heads Road" or "Daikin FDXS25" survives the trip from the caller's mouth into a job card. On 20 October 2026, Telnyx shipped a feature that lets voice AI assistants pre-load the exact names, addresses and trade terms they're likely to hear, built specifically to fix this. Telnyx is the telephony platform Fixa's voice infrastructure runs on. It's a two-paragraph release note. For a trades business whose entire job file starts with a phone call, it's one of the more consequential changes to turn up in any voice-AI vendor's changelog this year, and almost nobody selling AI receptionists to Australian trades talks about it.

Why AI receptionist transcription accuracy is a different problem than voice quality

Most of the marketing in this category sells on how the AI sounds: warm, local-accented, barely distinguishable from a person. That's a text-to-speech problem: given the words, make them sound human. Transcription accuracy sits on the other side of the call: given the sound, get the words right. An AI receptionist can sound flawless and still write "Dyken" into a job card because nobody told the speech-to-text model that "Daikin" is a brand name its callers say several times a day. Voice quality and transcription accuracy are measured by completely different parts of the stack, and a vendor can be excellent at one and mediocre at the other without a prospective customer ever noticing on a demo call, because demo calls are scripted and real calls aren't.

This matters more for trades than for most other AI-receptionist buyers. A plumber's caller says street names, suburb names, brand names, model numbers and part numbers in a single sentence, often over a bad mobile connection from a job site. General-purpose speech-to-text models are tuned on call-centre and customer-support audio, where the vocabulary is mostly common English. Trade vocabulary is not common English, and that's exactly the gap the Telnyx update targets.

What changed on 20 October 2026

Telnyx's AI Assistants already route calls through a transcription model (AssemblyAI, Deepgram and others are supported providers). The 20 October release adds two configuration options for assistants using AssemblyAI's Universal-3.5 Pro model specifically: a context prompt of up to 1,750 characters describing the call's domain, and a keyterm list of up to 100 comma-separated terms, each up to 50 characters, that the model should expect to hear. Telnyx also now automatically forwards the assistant's last spoken reply to the transcription model after every turn, so the model has the preceding question as context when it transcribes the answer. AssemblyAI's own explanation of the underlying model, in its post on contextual awareness in Universal-3.5 Pro Realtime, frames the same idea from the model side: if the agent just asked for an email address, the model should expect one next, the same way a person listening to the call would.

The release note states the reasoning plainly: "Domain vocabulary is where speech-to-text errors cost the most." A misheard product name can send the whole conversation down the wrong path, and the fix doesn't require a separate vendor or a new integration. It's a configuration change on the same pipeline an assistant is already using.

This builds on a release from eleven days earlier. On 9 October 2026, Telnyx added support for running two transcription models on one call: a fallback mode (up to three backup models, in priority order, that take over if the active one fails) and a "language booster" mode that runs two models in parallel and picks the better transcript turn by turn. Telnyx's own internal testing, cited in that release note, found pairing Deepgram's Flux and Nova-3 models dropped English word error rate from 5.7% to 4.6%, and a merge-based pairing of Basira and Cohere models dropped mixed-language error rate from 27.7% to 22.4% on calls that switch between Arabic and English mid-sentence.

Below is what those two numbers actually mean side by side.

flowchart TD A["Single model, English WER: 5.7%"] --> B["Flux + Nova-3 fallback pair, English WER: 4.6%"] C["Single model, mixed-language WER: 27.7%"] --> D["Basira + Cohere merge pair, mixed-language WER: 22.4%"] style A fill:#eb6834,stroke:#eb6834,color:#ffffff style B fill:#1baf7a,stroke:#1baf7a,color:#ffffff style C fill:#eb6834,stroke:#eb6834,color:#ffffff style D fill:#1baf7a,stroke:#1baf7a,color:#ffffff

Telnyx's own reported internal benchmarks: pairing transcription models cut word error rate by roughly a fifth in both tests, measured on its own test calls, not on Fixa or trade-specific audio.

Why AI receptionist transcription accuracy matters for your ServiceM8 job card

Every downstream feature a vendor advertises (instant booking, automatic job creation, SMS confirmations) is built on top of the transcript. If the transcript is wrong, the feature built on it is wrong too, no matter how polished the workflow looks in a sales demo.

ServiceM8's own Phone Agent documentation makes this dependency explicit without meaning to. Its help centre page on introducing the ServiceM8 Phone Agent states: "Every call is logged in ServiceM8 with a summary, transcript, and recording." That's a genuinely useful feature. It's also an admission that the summary is only as trustworthy as the transcript underneath it. If the model mishears the caller's suburb, the summary inherits that error, and so does anything a human or an automation later does with it.

The same logic applies on other platforms. simPRO's app marketplace listing for Supportiyo's AI Receptionist says each call "creates real data inside Simpro — customers, service jobs, activity logs, and notes." That's a stronger integration than most ServiceM8 add-ons offer today. It still depends on the same upstream fact: structured data is only as good as the speech recognition that produced it. A tighter integration with worse transcription still writes bad data faster.

Here's a mechanism walkthrough to make this concrete. It's illustrative, not a measured result. Fixa is pre-revenue and hasn't published call-accuracy data, so treat the numbers as a worked example rather than a claim about any vendor's actual performance.

Picture a caller on a Gold Coast air-conditioning business's line: "I'm at 34 Burleigh Heads Road, the condenser's dead on my Daikin FDXS25 split system." Without the brand name and model number loaded as keyterms, a general-purpose model has to guess at unfamiliar sound patterns against its default vocabulary, which skews toward common words. "Daikin" can come out as "Dyken" or "Dyke in." "FDXS25" (five characters and two digits spoken quickly) is exactly the kind of string general transcription models get wrong, because nothing in ordinary English conversation sounds like it. With the brand and model fed in as a keyterm list ahead of time, the model has something concrete to match the sound against instead of guessing.

flowchart TD Call["Caller states address, brand and model number"] --> Check{"Domain vocabulary pre-loaded via keyterm boost + context prompt?"} Check -->|No| Guess["Model guesses nearest common word or string"] Guess --> Bad["Job card drafted with wrong model/address, needs manual fix before dispatch"] Check -->|Yes| Match["Model matches caller's actual brand, model and street terms"] Match --> Good["Job card drafted correctly on the first pass"] style Call fill:#2a78d6,stroke:#2a78d6,color:#ffffff style Check fill:#4a3aa7,stroke:#4a3aa7,color:#ffffff style Guess fill:#e34948,stroke:#e34948,color:#ffffff style Bad fill:#e34948,stroke:#e34948,color:#ffffff style Match fill:#1baf7a,stroke:#1baf7a,color:#ffffff style Good fill:#1baf7a,stroke:#1baf7a,color:#ffffff

An illustrative mechanism, not a measured Fixa result: whether a keyterm list exists determines if a brand name or model number reaches the job card correctly or has to be fixed by hand later.

Fixa runs on Telnyx's voice infrastructure, which is why this specific release matters to us directly rather than as general industry news. Feeding a trade business's actual brand list, suburb names and job-type vocabulary into that keyterm layer is a design target we're building toward, not a shipped benchmark. We're pre-revenue, we don't have call-volume accuracy data to publish yet, and anyone who tells you their AI receptionist is "99% accurate" without a methodology attached is giving you a marketing number, not a measured one. Treat any accuracy figure from any vendor, including a future one from us, as a claim to ask about rather than a fact to accept.

A checklist: domain vocabulary to load before go-live

Whichever AI receptionist a trade business ends up using, keyterm boosting is only useful if someone actually feeds it the right vocabulary. This is the list we'd work through with a new customer, and it's a reasonable checklist for evaluating any vendor's onboarding process:

Brand and model names you service regularly: not just "Daikin" but the specific model ranges you quote most (FDXS, FTXM, Cora), since those are the strings generic models mangle worst.
Local street and suburb names that don't read as English words: the keyterm list exists precisely for place names a general model has never been trained on.
Trade-specific nouns: condenser, isolator, DB board, backflow valve, whatever your trade's working vocabulary actually is, as opposed to how a customer describes the same thing in plain language.
Number strings that sound alike: model and serial numbers spoken aloud are where digit confusion is most expensive, because a wrong digit points a technician at the wrong part.
Words that must never be misheard: "gas leak," "no power," "flooding." These are the words where a transcription error isn't an inconvenience, it's a safety issue, and they deserve to sit at the top of any context prompt regardless of what else is on it.

A five-minute setup conversation covering this list is a fair question to ask any AI-receptionist vendor, including us, before signing up.

Where the rest of the category stands

Chime Labs, the Sydney AI-receptionist startup founded by former Google staff Alexis Griveau and Mathew Pretel, raised $900,000 in pre-seed funding in April 2026, per Forbes Australia's reporting. Their pitch, as described in that piece, is answering, qualifying and booking jobs into a tradie's calendar. The article says nothing about how the product handles brand names, addresses or trade jargon, which isn't a criticism of Chime Labs specifically. It's a fair description of the entire category's marketing. Speed and warmth sell. "We tuned our transcription model's vocabulary for your trade" doesn't photograph well on a landing page, so almost nobody says it, even when it's the thing most likely to determine whether a job card is usable without a human fixing it first.

FAQ: AI receptionist transcription accuracy for trades

What does "transcription accuracy" actually mean for an AI receptionist?

It means whether the text the system produces from a phone call matches what the caller actually said. It's a separate question from whether the AI's own spoken replies sound natural: one is about listening correctly, the other is about speaking naturally, and a vendor can be strong at one while weak at the other.

Is this the same thing as the AI sounding more human?

No. A voice can sound completely natural while still mishearing a brand name or a street, because text-to-speech and speech-to-text are different models solving different problems. Judge them separately when you're comparing vendors.

Does setting up keyterm boosting cost extra or take long?

On Telnyx's side, no: the context prompt and keyterm list are configuration fields on an existing assistant, not an add-on product. How long it takes in practice depends on how organised a business's product and vocabulary list already is, which is usually the bigger time cost than the setup itself.

Will AI receptionist transcription ever be fully accurate for Australian addresses and accents?

Realistically, no system will hit zero errors, and any vendor promising perfect accuracy without a methodology behind the claim should be treated with suspicion. The honest goal is fewer errors on the specific vocabulary a business actually hears, which is exactly what keyterm boosting targets, and a sensible fallback (flagging low-confidence fields for a quick SMS confirmation rather than silently guessing) matters more than chasing a perfect number.

How is this different from what ServiceM8's Phone Agent already logs?

ServiceM8's Phone Agent already saves a transcript, summary and recording for every call, which is useful on its own. The point of this piece is that the summary's usefulness is capped by the transcript's accuracy: a good logging feature built on a mediocre transcript still hands you a mediocre summary, on ServiceM8 or on any other platform.

The practical takeaway

If you're evaluating AI receptionists for a trades business, ask a less comfortable question than "does it sound good on the phone." Ask what happens when a caller says a brand name, a model number or a street name the system has never heard before, and ask whether there's a mechanism for teaching it those terms ahead of time, not promised but demonstrated.

That question didn't have much of an answer in this category until a few weeks ago. It still won't be answered by taking a vendor's word for it. Ask to hear what a job card looks like after a call with real trade vocabulary in it, not after a scripted demo, and judge the answer on that.