Overview

Speech recognition is very good at everyday language and much weaker at the words that matter most to your business: your company name, your product names, the names of your agents. A call that opens with "Dzień dobry, Adam Gajewski, Uniqa" can easily be transcribed as "dam gajewski unika" — and from that point on the transcript says something the agent never said.

That has real consequences. Reviewers read and score the wrong words, greeting compliance fails on a greeting that was actually correct, topic detection misses a product that was clearly mentioned, and searching for the agent or the product name doesn't return the call.

Speech Recognition Quality is where you fix this. You build a list of auto-corrections: for each correct phrase, you list the mishearings that should be replaced with it. As long as corrections are switched On, every call transcribed by Ender Turing after that gets the correction applied automatically, before any analytics run. The switch is on the same page and governs the whole list at once, so if a saved correction never seems to take effect, check the switch first.

Auto-corrections fix speech recognition, so they apply to conversations whose transcript Ender Turing produced itself from audio. Conversations that arrive with a transcript already written — chats and emails, and calls synced from an external provider that supplies its own transcript — are never passed through the correction step, even when the call's audio is available for playback in Ender Turing.

How It Works

Finding Speech Recognition Quality

Open Settings from the main navigation.
Select System.
On the System page, select the Speech Recognition Quality tab.

You land on the list of auto-corrections currently configured for your organization.

Who Can Use It

Action	What you need
Open the Speech Recognition Quality tab and view the list	The system management permission
Add, edit or delete an auto-correction	The system management permission
Turn corrections on or off	The system management permission
Upload or edit the list as JSON	The system management permission
Create an auto-correction from selected text in a transcript	Both the analytics management and the system management permissions

Without the system management permission, the System entry does not appear under Settings and the list of auto-corrections cannot be loaded.

The two selection shortcuts need both permissions: the analytics management permission controls whether the menu items appear at all, while saving goes through the same auto-corrections service as the settings page and so also needs the system management permission. A reviewer who has only the analytics management permission will see the menu items and be able to open the dialog, but saving is refused with an error notification reading "The user doesn't have enough privileges". For Add phrase to existing auto-correction that notification comes even earlier: the existing corrections are fetched as soon as the conversation or Discovery page loads, so the message appears on page load, before anything is selected, and the dialog then opens with an empty list. If you are granting access so that reviewers can fix mishearings as they find them, grant both.

Turning Corrections On and Off

At the top right of the page there is an On / Off switch. It controls whether auto-corrections are applied at all.

Switching it off does not delete anything — your list stays exactly as it is, and conversations simply stop being corrected. Switching it back on resumes correction for conversations processed from that point onward. Transcripts that were already corrected keep their corrected text either way.

Reading the List

The list has two columns:

Phrase — the correct form. This is what the text will be replaced with. You can sort the list by this column.
Incorrect Phrase Examples — the mishearings to look for. Each example is shown as a separate chip.

You can show 10, 25, 50 or all entries per page. Each row has edit and delete actions, and you can tick several rows and use Delete to remove them together — bulk delete asks you to confirm and cannot be undone.

Adding an Auto-Correction

Click + Add at the top right. A new editable row appears.
In Phrase, type the correct spelling — for example Uniqa.
In Incorrect Phrase Examples, add every mishearing you have seen for it — for example unika, uniqua, you nika. Press Enter after each one to add it as a separate example.
Save the row.

Both fields are required: you cannot save a row without a phrase, and you cannot save a row with no examples. A row that has a phrase but no examples has no effect on any transcript.

Type real text, not spaces. The check is only that a field is not empty, so a Phrase consisting of nothing but spaces counts as filled and the row saves. A blank-looking phrase does not correct anything — it replaces every matching example with spaces, deleting those words from the transcripts of all conversations processed afterwards. Removing the row stops the damage but does not repair it: there is no way to put the deleted words back automatically. If you have the transcript editing permission you can retype an affected line by hand from the conversation view, but analytics that already ran on the damaged text are not recalculated. Pressing Enter on a space in Incorrect Phrase Examples likewise adds a blank chip, which is at best useless. If a row's Phrase column looks empty in the list, open it and fix it.

Keep each correct phrase to a single row. Nothing stops you from creating two rows with the same Phrase — no warning is shown — but a duplicate is worth avoiding: a JSON upload merges its examples into only one of the matching rows, so the other one quietly stops receiving updates. The list has no search box, so check for an existing row by sorting on Phrase and looking it up alphabetically — showing all entries per page helps on a long list. If the phrase is already there, edit that row and add your new examples to it instead.

Creating Auto-Corrections While Reviewing a Conversation

The most reliable way to build the list is from real mistakes as you find them. Open any conversation, select the misheard text in the transcript with your mouse, and a menu appears with two relevant options.

The same menu is available in Discovery: select text in a search result's snippet — either the main snippet or one of the additional matches under it — and you can create or extend an auto-correction without opening the conversation. Searching for a mishearing and correcting it straight from the results is a quick way to build the list.

Create auto-correction — use this when the correct phrase isn't in the list yet.

The text you selected is filled in as the Incorrect phrase (alias) and cannot be changed in this dialog.
Type the Correct phrase — the spelling you want to see instead.
The correct phrase must not be empty and must be different from the text you selected. That comparison uses exactly what you typed, so a stray space around the phrase gets past it — and the spaces are then stripped when the entry is saved. Typing Uniqa against a selection of Uniqa creates an entry that replaces the text with itself and changes nothing.
Saving creates a new entry in the list with your selected text as its first example.

Add phrase to existing auto-correction — use this when the correct phrase is already in the list and you've just found a new way it gets misheard.

The dialog shows your whole list of auto-corrections with a Search auto-corrections box that matches on both correct phrases and existing examples.
If the selected text already appears as an example somewhere, it is highlighted so you can see it's already covered. The highlight only appears on an exact character-for-character match, including capitalisation — matching itself ignores case, so an existing example of uniqa already covers a selection of UNIQA even though it is not highlighted. Use the search box to check before adding a near-duplicate.
Click Add on the right entry to attach the selected text to it. Click Undo to reverse a choice before saving.
The dialog lets you add the selected text to more than one entry before saving, but attach each example to a single correction. If the same example is listed under two different correct phrases, the rows are applied one after another in alphabetical order of the correct phrase, each working on the text the previous one left behind. Usually that means the alphabetically earlier correction wins and the later row never sees the example. It can be worse than that: if the earlier correction's phrase still contains the example as a word of its own, the later row matches it again. With unika listed under both Unika Group and Uniqa, the misheard text first becomes Unika Group and is then rewritten to Uniqa Group — neither of the two corrections you intended. Pick one entry.

How Matching Works

Case is ignored. An example of uniqa matches Uniqa, UNIQA and uniqa.
Replacement uses your exact spelling. Whatever the transcript said, the result is written exactly as you typed the Phrase, capitalisation included — with two exceptions. First, do not put a backslash in the Phrase. A backslash is not written out literally: \n turns into a line break, \1 is replaced by the misheard text that was matched, and a combination that is not recognised, such as \q, stops processing for new calls in the same way an invalid example does. Second, avoid full stops, question marks and commas in the Phrase. For languages where Ender Turing applies advanced punctuation, the transcript is re-punctuated straight after the correction: those three characters are stripped from the corrected text and punctuation is then reinserted automatically, so a phrase such as Acme, Inc. may not come out exactly as you typed it even though the correction matched. Write Acme Inc instead.
Don't use one row's correct phrase as another row's example. Rows are applied one after another, in alphabetical order of the correct phrase, and each row works on the text the previous rows already produced. So if Uniqa is the Phrase of one row and also an example under a later row whose phrase is Uniqa Insurance, a misheard unika first becomes Uniqa and is then rewritten again to Uniqa Insurance. The final wording is the last row that matched, not the row you were looking at. Keep your correct phrases out of other rows' examples.
Whole words only. An example matches only when it stands on its own, not when it's part of a longer word. An example of nika will not match inside technika.
Multi-word examples work, but avoid overlapping ones. you nika is a valid example and is matched as a phrase. Do not, however, list one example that starts with another — you alongside you nika. Of two overlapping examples, the one stored first in the row is the one that matches, regardless of length: with you stored before you nika, the misheard you nika becomes Uniqa nika rather than Uniqa. You cannot rely on that order either, since a JSON upload may reorder the examples in a row. Keep examples distinct instead.
A multi-word example must fall inside one line of the transcript. Matching is done line by line, on each transcript line separately. The transcript is split into lines as speech recognition heard it, and a phrase whose words fall across two consecutive lines will never match, even though the words look continuous when you read the conversation. If you select a mishearing that spans a line break, add the part that sits within a single line instead.
All languages, one list. Auto-corrections are not scoped per language. Every entry applies to every transcribed conversation in your organization, whatever language it was recognised in.

When Corrections Are Applied

Auto-corrections run as part of processing a call, early — after the transcript is produced by speech recognition, and before anonymization, tags, compliance checks, topics, summaries and quality scoring. Everything downstream therefore reads the corrected wording, and the corrected wording is what gets indexed for search.

Because anonymization runs after correction, it can still hide part of what you corrected. If your correct phrase contains a standalone number, or if it happens to sit where an anonymization rule masks text, the corrected transcript is masked with * before analytics and search ever see it. Correction feeds anonymization rather than bypassing it — if a product name with a number in it keeps showing up masked, that is anonymization, not the correction failing.

Conversations that arrive with their transcript already written skip this step entirely: they go straight to anonymization and analytics, so no auto-correction is applied to them. This covers imported chats and emails, and also calls synced from an external provider that hands Ender Turing a finished transcript — the correction step belongs to Ender Turing's own speech recognition, not to the conversation's media type.

Corrections apply only to conversations processed after you save them. Adding a new auto-correction does not go back and fix conversations that were already processed — those keep the transcripts they already have. This is why it's worth adding corrections early, as soon as you notice a recurring mishearing, rather than in a batch later.

Changes to the list can take up to a minute to be picked up by processing. This applies to every change — adding a row, editing one, and deleting one — so a rule you have just removed can still be applied to calls processed in the next minute. If you're testing a rule against a fresh upload, allow for that short delay before concluding it didn't work.

If you need a damaging rule to stop immediately, switch corrections Off. The switch is read fresh for every conversation, so it takes effect at once, while deleting the row does not. Then fix or remove the entry, wait a minute, and only then switch corrections back On. The one-minute delay applies to your fix as well, so switching straight back on can put the old rule to work again for the remainder of that minute.

Editing the List as JSON

For large lists — for example when you already maintain a glossary of company and product names elsewhere — you can work with the whole list at once.

Open the three-dot menu at the top right and choose Upload/Edit JSON. The page shows your current list as JSON, and offers two ways to submit changes:

Edit the JSON directly in the editor and click Save changes.
Choose a .json file with the file picker and click Submit.

The format is an array of entries, each with a correct phrase and its examples:

[
  {
    "word": "Uniqa",
    "aliases": ["unika", "uniqua", "you nika"]
  },
  {
    "word": "Gajewski",
    "aliases": ["gajefski", "gaevski"]
  }
]

Uploading merges — it never deletes. Entries whose correct phrase is new are added. Entries whose correct phrase already exists have their examples merged into the existing entry, with duplicates removed. Existing entries you did not include are left untouched.

Whether an entry counts as already existing is decided by comparing the correct phrase exactly, capitalisation included. Uploading uniqa while the list already holds Uniqa does not merge — it creates a second row. Write phrases in your file exactly as they appear in the list.

Give each correct phrase once per file. Merging compares your file against the list as it was before the upload, not against entries created earlier in the same file. If a phrase that is new to your list appears twice in the file, both entries are created and you end up with two rows for it instead of one merged row. Glossaries exported from elsewhere often repeat a target phrase, so combine the examples for each phrase into a single entry before uploading.

This matters most when you edit the JSON in the browser: removing a line from the editor and clicking Save changes will not remove that entry. To delete an auto-correction, go back to the list and delete the row there.

If something is wrong with the upload you'll see one of these messages:

"Please upload a JSON file" — the file wasn't recognised as JSON.
"JSON file is damaged. Please provide a correct one" — the file isn't valid JSON. Check for a missing bracket or a trailing comma.
"JSON file has a wrong format. Please provide a correct one" — the JSON is valid but an entry doesn't have the expected shape. Every entry needs both a correct phrase and a list of examples.

The top level must be an array, as in the example above. A file containing a bare value such as null, true or a number is valid JSON but never reaches the format check, so it fails with a generic error rather than the message above.

Check that no value in the file is blank. The format check looks only at the shape of an entry, not at what is in it, so blank strings are accepted without any error and both kinds do damage:

A blank correct phrase — {"word": "", "aliases": ["unika"]} — does not correct anything. It deletes every occurrence of unika from the transcripts instead.
A blank example — {"word": "Uniqa", "aliases": [""]} — does not match nothing. It matches in a great many places and scatters Uniqa through every transcript processed afterwards.

Both apply to every conversation processed until you notice and remove the entry, and neither is reversed on transcripts that were already processed — the same manual repair described above is the only way back. Glossaries exported from other tools often contain empty cells, so check the file before uploading it.

Use Back to list to return to the table view.

Practical Limits and Caveats

Corrections change the transcript itself. The corrected wording is what reviewers read, what search returns and what analytics score. There is no side-by-side "as recognised" view in the transcript, so add corrections you are confident about.
Avoid punctuation and symbols in examples. Characters such as (, ), [, ], |, +, *, ?, . and \ are interpreted as pattern syntax rather than as literal characters, so an example containing them may not match what you expect. Worse, an example with an unmatched ( or [, or one ending in \, is not a valid pattern at all: while corrections are enabled, it stops processing for every new call. Those conversations are retried automatically for a while, so fixing the entry quickly is usually enough for them to finish on their own. A conversation that keeps failing for long enough, though, is eventually given up on, and correcting the entry after that does not bring it back — restarting those conversations is an operational action your administrator or Ender Turing support has to trigger. Stick to plain words and spaces.
Be careful with short examples. A short, common example replaces a real word wherever it appears on its own. Prefer distinctive mishearings over generic ones.
One list for the whole organization. Because there is no per-language or per-team scoping, an entry added for one product line applies to every transcribed conversation.
Only mishearings you've listed get fixed. Auto-correction handles the variations you write down. New variations you have not yet seen will pass through unchanged, which is why reviewing transcripts and adding examples from them is the natural way to keep the list current.