Welcome to the Cyara Knowledge Center

This is a comma-separated list of codec(s) to be offered in calls from the Call Engine.

Conditions and Restrictions

Note: The {Codecs} tag is not supported for use in the Cyara cloud. This Tag may only be used by Cyara premise customers.

• Only applies to calls originated by the Call Engine, not calls that it receives.
• Overrides the default SIP/Codecs parameter in the CE config.
• The order of codecs determines the codec priority.
• For the list of supported codecs for your platform, please contact your Account Administrator. Care must be taken to ensure that if this tag is used in a mixed Campaign (G.711 and G.729), that all Call Engines are licensed for G.729.

Normally, Step 1 in a Test Case starts when the call is answered (SIP 200 OK). Use the {EarlyMedia} tag so that the Test Case instead starts when early media is detected (SIP 183 Session Progress).

Optional Parameters

• TreatRingingAsConnected, can be included after the {EarlyMedia} Tag in the form: {EarlyMedia TreatRingingAsConnected}) in which case the Test Case will start when ringing is detected (SIP 180 Ringing).

• TreatRingingOrProgressingAsConnected. Example: {EarlyMedia TreatRingingOrProgressingAsConnected}

  This optional parameter will instruct CEN to answer a call when it receives SIP 180 Ringing or SIP 183 Session Progressing which ever arrives first.

Conditions and Restrictions:

• The tag needs to appear at the start of the Called Number field.
• There should be no space between the end of the tag's closing brace and subsequent content in the Called Number field.

The wildcard tag ignores part of a prompt in recognition. It matches anything in the Expect to Hear prompt.

The {*} Wildcard Tag is a functional Cyara Test Case Tag that performs a specific function. Including the Wildcard Tag in an Expect to Heard field on a Test Case will inform Cyara Speech Recognition to ignore part of a prompt in recognition. The {*} Wildcard Tag is used as a placeholder to replace the Expect to Hear text that should be ignored.

The {*} Wildcard Tag has a range of applications when testing customer contact solutions that have highly interchangeable parts, such as menus that will speak out a Day of the Week or a Customers' Name for example. Rather than making Test Cases to cover each of these simple differences, the {*} Wildcard Tag can be used instead.

Conditions and Restrictions

• The {*} Wildcard Tag can be used multiple times within the same prompt
• Cannot be immediately followed by another {*} Wildcard Tag in the same prompt (some text must separate these Tags)
• The {*} Wildcard Tag can not be used inside of a {Choice} Tag

Examples of usage:

• Very changeable parts of prompt speech such as varying time or monetary values (although the specific {Time} and {Currency} tags should be preferred over this generic wildcard tag)
• Unrecognized words
• Audio glitches such as ring-back, truncated words, and music

{*} (Wildcard) Tag Scenario 1.

In this scenario, we have deployed a contact centre solution that identifies the customers first name from their call-in number and greets them with a personalised welcome message. As we are only speaking the customers first name, we can use the {*} Wildcard Tag to ignore this part of the welcome message as it will always be changing depending on our testing scenario. Ignoring this spoken name while listening to and performing Speech Recognition on the remainder of the welcome message helps us ensure that our new contact centre solution is performing as we expect.

Note : In the above scenario, we are choosing to ignore the spoken name section of the welcome message greeting. If you are aiming to ignore changing Time or Monetary values that are presented by your IVR, we recommend using the specialised {Time} and {Currency} tags over this generic {*} Wildcard Tag as the {Time} and {Currency} tags are designed to handle the unique grammar and syntax around expressing these values and will result in a higher recognition score for your Test Cases.

{*} (Wildcard) Tag Scenario 2.

The {*} Wildcard Tag can also be used to ignore more than just speech from your IVR, it can also be used to ignore audio glitches, music, ringback tones, truncated words and more. In this below example we have a long hold message that we want to ensure is being played to customers in full. However this hold message is interspersed with sections of music.

Note : In the above scenario, we are choosing to ignore the spoken name section of the welcome message greeting. If you are aiming to ignore changing Time or Monetary values that are presented by your IVR, we recommend using the specialised {Time} and {Currency} tags over this generic {*} Wildcard Tag as the {Time} and {Currency} tags are designed to handle the unique grammar and syntax around expressing these values and will result in a higher recognition score for your Test Cases.

The {AGD} Tag is used to recognise an AGD ID only. This is a special tag that instructs Cyara platform to listen for a special input of digits which start with spoken literal A G D followend by number of digits an example: A G D 1234.

This is specifically designed to listent for a Cyara AGD identify itself.

How is the AGD Tag used?

Instead of using this Expect to Hear: A G D {Digits $AGD_ID Length=4}

you can use just this: {AGD}

Examples of usage:

• Changing variable name: {AGD $custom_var_name}
• Reguiring 6 digits long and asigning a cutom name: {AGD Length=6 $long_agd_id}
• Ensuring AGD_ID is 9999: {AGD $agd_id == "9999"}

Use this tag to not fail the Test Case when the far end hangs up while the Test Case is playing a reply. If the far end hangs up while a Step is playing its reply, the Step is normally flagged as a failure. However, if this tag is present in the Expect to Hear field, this situation will not be flagged as a failure.

The {AlphaNum} tag is used to recognize alphabet letters and numbers in English.

Conditions and Restrictions

• Can recognize 0-9 and A-Z in English
• If an optional variable is specified, the variable result cannot be used in a subsequent dynamic reply

Examples of usage:

• {AlphaNum Length=6 $postcode}
• {AlphaNum Length=4-6}
• {AlphaNum $id}
• {AlphaNum Length=6 $id == "K2G4A3"}

The {BargeIn} Tag does as the name suggests, it "Barges In" and interrupts an IVR prompt with the next Test Case Step Reply. This tag is useful for simulating more real-world customer facing contact scenarios, where customers can speak the name of the the next menu they want to progress to for example. Testing that your IVR can recognise when customers interrupt menu prompts and can perform interactions successfully under these situations is key to delivering great customer experience

How is the {BargeIn} Tag Used?

The {BargeIn} tag functions by indicating that the next Test Case Step Reply should interrupt the prompt being heard after the time specified in the PSST field for this step. The ‘barge-in’ occurs after the specified time (in seconds) after the beginning of the audio for the Step is detected.

Note: The length of time to enter in the PSST field is best determined by loading a previously run Test Case validation .wav recording into an audio editor like Audacity. Audio editing programs typically have the ability to accurately measure the time duration of selected sections of the audio recording.

Conditions and Restrictions

• Any text in the Expect to Hear field after this tag will be ignored but may be included for context
• Speech recognition is only performed on the audio that was heard from the end of the previous Step until the expiry of the barge-in time. Matching is performed with the text in the Expect to Hear field up to, but not including, this tag
• Unless the Minimum Confidence % field is zero, changing the barge-in time also requires changing the position of this tag in the Expect to Hear field to ensure that the correct text is matched with the audio fragment that was captured up until the barge-in

Examples of Using the Bargein Tag

Scenario 1.

In this example we want to simulate a customer interaction where the customer interrupts the main menu of a simple IVR that recognises speech input. Here we include the BargeIn tag on the speech recognition step that we want to interrupt, in this case the main menu.

The {BargeIn} Tag operates by waiting for the time allocated in the PSST field for this step, in the above example this is set to 2.5 seconds. After this time threshold has elapsed, the Cyara Test case will interrupt this speech recognition step with the next reply, in this example we are interrupting the main menu by speaking the word "Balance" to progress to the account balance menu.

As the the first step in this Test Case includes the {BargeIn} Tag, speech recognition occurs on the audio heard up to the triggering of the BargeIn by the PSST timer. Any subsequent text in the Expect to Hear field on this Test Case step after the {BargeIn} Tag will be ignored.

The {BypassRecognition} tag is used to indicate that speech recognition should not be done on any of the audio heard in this Step.

This will return a 100% confidence score, regardless of whether the text matches the audio or not.

Conditions and Restrictions

• If this tag is used in a Multi-Step prompt (A prompt that is covered by multiple steps in the Cyara Test Case), it must only be placed on the initial sub-step. (If this tag is used in subsequent sub-steps within this multi-step prompt they will be ignored.
• This tag cannot be used with any other tags except {MaxAudioLength} and {EndCallIfNoAudioWithinThreshold}
• Any text included with this tag will be ignored (which is useful for commenting what is being bypassed)

The {Choice} Tag can be used when matching a prompt that has at least two known alternatives. For example, an IVR that has a different opening voice message during different times of day. {Choice} Tags can specify multiple phrases and Cyara will attempt to match the prompt against each provided phrase within the Tag.

Choice Tags also have an advanced application where the result of a choice outcome can determine what response the Cyara Test Case makes in subequent Test Case Steps. For more information, read the Optional Parameters & Operators for the Choice Tag.

How is the Choice Tag used?

The {Choice} Tag is inserted in the Test Case Expect to Hear field or a CX Model Prompt field, representing multiple alternate phrases that can be matched by the Cyara speech recognition engine.

For example, Hello, this is {Choice Adam|Barry|Charlie} speaking.

In the preceding example, we expect to hear "Hello, this is" and then either the name "Adam, Barry or Charlie", any of these three names being spoken by the IVR would result in this step having a successful outcome.

Conditions and Restrictions

There are a few key points with the {Choice} Tag to be aware of;

• The reply variable is only allowed in the Reply With field of the same or subsequent Steps
• Only one use of any reply variable is allowed in any single Reply With field
  • A Step's Reply With field can only contain 1 Choice variable reference (for example, you can not include {$Var1} {$Var2} or {$Var1} {$Var1})
• If no reply variable value is specified by a Choice, the variable is assigned the value of the choice prompt.
  • In this example, {Choice $Var1=Adam:1|Barry:2|Charlie:3}, the variable is called "Var1" and the variable values are 1, 2, and 3. If the Reply With field contains {$Var1} then the Step will reply with the value assigned in the Expect to Hear Step (1, 2, or 3). However if the Expect to Hear Step instead contains {Choice Var1=Adam|Barry|Charlie} (that is, without the optional variable values), the variable "Var1" is assigned the literal choice option (for example, "Adam, "Barry", or "Charlie").
• Choice Tag reply variables must be assigned only once. However, they can be referenced multiple times in separate Test Case Reply With steps.
• Choice tags cannot contain other nested tags except for the {EndCall} or {SetStepResult} tags.
  • You can use the {SetStepResult StepResult="result" Details="details"} tag to specify that the step result can be set to a specified value or default to Failed if the option part of the choice is heard. For more information about using the {SetStepResult} tag, see Tag: {SetStepResult}.
  • You can use the {EndCall StepResult=result Details="details"} tag with the <variable value> part of a {Choice} tag to specify that the call must end if the <choice prompt> part of the choice is heard. For information about using the {EndCall} tag with the Choice tag, see Tag: {EndCall StepResult=result Details="details"}
• A Choice prompt can be set to blank, "." (a single period/full stop), or ".*" all of which will match nothing.
  • {Choice Hello|} how are you", "{Choice Hello|.} how are you", and "{Choice Hello|.*} how are you" have equivalent meaning, and will successfully match against "Hello how are you" and "how are you".
• A Choice Tag reply variable should not be used in Cruncher load testing Campaigns

Examples of using the Choice Tag.

The following examples show how the {Choice} Tag can be used to handle multiple business scenarios on the same Cyara Test Case. In the examples below we will increase the complexity of using the {Choice} Tag, starting with a basic prompt matching moving on to more advanced Choice Tag Reply Variables.

Scenario 1.

In this example, we want to build a Test Case that can handle two slightly different prompts at different times of the day (A normal operating hours and an Out of Hours message) and how you would use the Choice tag to handle either scenario in the same Test Case.

Scenario 2.

Now we can build a more complex Test Case Step where we set a Variable to be used in a later Test Case Reply With Step. In this scenario an IVR is performing a validation task by asking the caller to enter a random digit from their PIN (Either the First, Second, Third, or Fourth Digit). We want to be able to accept any of these four options, and change the reply with text of a later Test Case step based on what was entered by the caller (a security validation pass/failure for example).

Scenario 3.

An advanced application of using the Choice Tag is to reply with an amount of silence in the Reply With field. This is achieved by setting a Choice Tag Reply with Variable to either a "." (A period/Full Stop), or a "," (a Comma). A Period/Full stop will reply with 2.0 seconds of Silence, While a Comma will reply with 0.2 seconds of silence. This method only works if the Reply With step is set to the DTMF Reply Type. Assuming the Reply With field is set to {$Var1}, then the following would apply.

Optional Parameters and Operators for the Choice Tag.

An optional extension of the tag allows a return value based on the phrase that was matched within the {Choice} Tag, and this return value can be used to alter subsequent Step replies.

The extended form of the choice tag also matches several alternatives, but will also return a value that can then be used in subsequent steps. For Example;

Hello, this is {Choice VariableName=Adam:1|Barry:2|Charlie:3}

This example above, the prompt will still match for either of the three available names (Adam, Barry or Charlie), but in this instance the VariableName variable will be assigned a value of 1 for Adam, 2 for Barry and 3 for Charlie. This VariableName can then be used in subsequent reply with fields by using {$VariableName}

Conditions and Restrictions

• Recognition of Currencies is dependent on the Active Language set in your Cyara Account.
• If an optional variable is specified for the {Currency} Tag, the variable result can notbe used in a subsequent dynamic reply.

Examples of usage:

The following scenarios cover how to use the {Currency} Tag in a range of testing situations to accurately recognise spoken monetary values, following onto more advanced implementations of the {Currency} Tag to perform comparison operations.

Currency Tag Scenario 1.

In this Test Case we are using the {Currency} Tag to pass a Test Case step so long as a valid "Dollar" amount (dollar and cents) is spoken during this Test Case Step. Having the Cyara Active Language set to en-US or en-AU will set the {Currency} Tag to recognise these spoken "Dollar" amounts.

This recognition is particularly useful for listening to account balances that could often change, rather than creating a Test Case for each balance, we can use the {Currency} Tag to pass any valid currency. We hear the audio "Your account balance is two dollars and fifty two cents" which the {Currency} Tag will recognise as a spoken currency, and as a result will mark this Test Case Step as a success.

Currency Tag Scenario 2.

To improve our Test Case accuracy further, we will now perform a comparison of the heard currency against a provided value. In this example we want to ensure that the spoken currency value is exactly " £2.52", having the {Currency} Tag recognise British Pounds requires the Active Language on your Cyara account to be set to en-GB.

In this scenario hear the audio "Your account balance is two pounds and fifty two pence" which the {Currency} Tag will recognise as a spoken currency. However this time we are also storing this currency value in the $var Variable in the Expect to Hear field. This Variable is then compared to the supplied value of 2.52 by using the == (EqualTo) Operation.

Note: You can use this Test Case example with a range of different operators, such as "==" (EqualTo), "<=" (GreaterOrEqualThan) and more, see the Optional Parameters and Operators table below for more information.

Optional Parameters and Operators for the Currency Tag.

The {Currency} Tag supports the following additional optional parameters and operators. To use these operators you write the tag using the following syntax.

Note: In the following syntax, it's important to include the spaces between each statement of Currency, $VariableName, Operation and Value.

{Currency $VariableName Operation Value}

{Currency $Currency1 >= 350}

To use these operators you write the tag using the following syntax.

The {Date} tag recognizes a spoken date in a prompt. Examples of recognized date formats are shown in the table below. The {Date} tag is very flexible and can recognize many different date formats in the active language.

The {Date} tag recognises a spoken date in a prompt. Due to the various ways that Dates are expressed when spoken, it's important to have a dedicated Tag to perform this recognition. The simple form of the {Date} Tag will pass a Test Case Step if any recognisable date is heard, this is particularly useful for contact centre solutions that have spoken dates in menu prompts. Rather than building a unique Test Case for each date option, the {Date} Tag can be used instead.

Examples of recognised date formats are shown in the table below. The {Date} tag is very flexible and can recognise many different date formats in the active language.

Conditions and Restrictions

• The Recognition of Dates is dependent on the Active Language set within your Cyara Account.
• If an optional variable is specified, the variable result cannot be used in a subsequent dynamic reply

Examples of usage:

The following example scenarios cover a range of applications of the {Date} Tag to improve Test Case recognition scores for IVRs that speak calendar dates to customers. The {Date} Tag allows you to pass multiple variants of a date being recognised by a Cyara Test Case.

Date Tag Scenario 1

In this scenario we want to build a Test Case that will be able to pass any date that is heard on a specific prompt. This prompt is designed to speak today's date to the customer while they are on hold. As this will change each time we run this Test Case, changing the Expect to Hear text each time wouldn't be workable. Instead we can insert the {Date} Tag to accept any spoken date and mark the Test Case Step as Successful.

Date Tag Scenario 2.

In this example we want to perform a comparison between the date heard on the call, and a supplied value. This comparison method is a useful testing solution where you can confirm that backend systems that surface dates to customers (Such as account expiry dates, or contract renewal periods) are sending the correct data exactly, rather than just validating any Date.

This example also highlights how comparisons between dates are performed. Dates are trans-coded into a 8 digit number with the following format : yyyymmdd (So January 5th 2002 = 20020105). You can replace a section (years, months or days) of this format with question marks, to indicate that Cyara should not expect to hear that section of the date. For example to make a comparison to a date without checking the year, you compare your variable to "????mmdd".

Note: Ensure you enter the correct number of question marks to indicate that Cyara should not Expect to Hear that section of the date, 4 question marks for Years, and 2 for Months and Days.

To do this comparison, we store the date that the {Date} Tag hears, as a variable. In the example below we enter the {Date} Tag into the Expect to Hear Field as follows.

{Date $VarDate == "????0705"}

The "{Date" section starts the Date Tag, $VarDate is our declared Date Variable. We are performing an "EqualsTo" operation so we use ==, and the value we want to compare to is "????0705 which will match to the 5th of July in any year.

The {Digits} Tag is used to recognise when an IVR is confirming digits such as PIN or telephone numbers. {Digits} Tags are able to recognise any combination of Single-Digit numbers (eg. 1 3 5 9).

Using the {Digits} Tag assists in a more accurate recognition score for that step, as the Cyara Platform will use a specialised set of grammar related to how digits are expressed when performing recognition.

How is the Digits Tag used?

The {Digits} Tag is inserted in the Test Case Expect to Hear field to recognise a set of single-digit numbers spoke individually.

In this example above, we expect to hear a phone number spoken as part of step 1. As long as this telephone number does not exceed 20 digits in length, this prompt will return a successful result, independent of the actual numbers spoken.

Conditions and Restrictions

There are a few key points with the {Digits} Tag to be aware of;

• The {Digits} Tag can recognise a maximum sequence of 20 digits.
• The {Digits} Tag can only be used for spokendigits (Digits entered by the customer as DTMF Tones should use the {DTMF} Tag).
• Punctuation characters such as hyphens, dots, and underscores are not recognized; if these are spoken, recognition accuracy will be reduced.
• If a (optional) variable is specified, the stored variable result cannot be used in a subsequent dynamic reply.

Recognition is dependent on the active language of your Cyara Account. You can specify alternative languages for recognition by using the {Language} Tag. Below are examples of digit sets that can be recognised in various languages.

Examples of using the {Digits} Tag in Cyara Test Cases.

The following examples offer different applications of the {Digits} Tag in Cyara Test Cases, and how the Tag can determine a Successful or Failed Test Case Step. Each of these examples contain the "Actual Audio Heard" by Cyara on the call , the Expect To Hear field on the Test Case and the outcome of that step as it is configured.

Digits Tag Scenario 1.

In this scenario we want to build a Test Case step that will listen for spoken digits, and that will return a successful result regardless of what these digits actually are. This is useful if your IVR contains a security verification prompt that is unique per caller (e.g Your call verification code is 1234). The Digits tag enables you to build a single test case step that listens for any set of digits and returns a Successful Outcome.

Digits Tag Scenario 2.

Now we can build a more complex Test Case Step that includes an Optional Parameter that is available for the {Digits} Tag, the "Length" Parameter. This Parameter changes the {Digits} Tag to listen for a set of digits that is an exact length, or within a set range.

This parameter allows us to build a Test Case that listens for an account PIN number for example, ensuring that it is exactly 4 digits in length without checking what these digits are, see the example below.

Digits Tag Scenario 3.

Building on the above example, we want to confirm that a set of spoken digits is within a correct range, and that it matches an expected set of Digits exactly. To achieve this we will use both of the available Length and Variable Parameters on the same {Digits} Tag.

Optional Parameters and Operators for the Digits Tag.

The {Digits} Tag supports the following additional optional parameters and operators.

The {DTMF ...} tag will listen for DTMF instead of speech. The PSST is the inter-digit timeout and the Major Threshold Time is the initial DTMF timeout.

Note: The syntax for this tag expects the DTMF tones immediately after the tag, for example:

{DTMF $variable}1234

Conditions and Restrictions

• A variable name must be specified; the Detailed Step Result will contain a list of DTMFs received (for example, id="1234")
• The variable result cannot be used in a subsequent dynamic reply
• If an optional list of DTMFs is specified after the tag, the received DTMF(s) will be matched against the list, and if they don't match, the Step will fail with Detailed Step Results including text like: 'id="1234" No match. Expected "5678"'. However, if the Step's Major Confidence Threshold is set to 0, this Step will be marked as a "Success" even if they don't match.

The {EndCall StepResult=result Details="details" } tag is allowed only with the <variable value> part of a {Choice} tag (that is, after the colon) to specify that the call should end if the <choice prompt> part of the choice is heard (that is, before the colon).

StepResult must be in the list of supported values in the table below in order for the {EndCall} Tag to function correctly.

This tag can be used with multiple alternatives in a Choice. If an alternative is heard, the call is ended with the Step marked with the specified result (Success, Satisfactory, or the default Failed). If the optional Details argument is specified, the details text will be included in the Detailed Step Result, otherwise it will contain "Ended call due to Choice option heard."

Caution: This tag causes the Step to require Priority Recognition and should not be used in load campaigns unless the Cyara ASR to Call Engine port ratio has been specifically configured.

Example of usage for Choice’s EndCall Tag:

The Operations team wants to set up a Pulse Test Case that normally runs through a dummy telephone banking transaction. However, if abnormal greetings are heard, they want to be alerted according to their desired severity scale. They do not want any calls going through to agents.

{Choice Welcome to ABC Bank. For telephone banking press 1. To speak with a banking representative, press 2.

| Sorry, we are experiencing technical difficulties. Please call back later.

  : {EndCall StepResult=Failed Details="ERROR: Tech Diff"}

| We are currently upgrading our automated phone banking services. If you have an urgent issue, 
please stay on the line to speak with a banking representative. 

  : {EndCall StepResult=Satisfactory Details="Maintenance Mode"}}

Use this tag to specify that the call should be ended if no audio is heard within the Major Threshold Time of the Step. By default, a grace period that is much longer than the Major Threshold Time is given for audio to begin being heard. If this tag is used and the silence at the beginning of the Step exceeds the Threshold, the call is ended immediately with the reason "Abandoning call because no audio was heard within n seconds".

This tag is useful for ending a call that has too long of a delay before audio is heard (for example, the IVR takes too long to reply).

Conditions and Restrictions

• Do not use with {Ignore} or {WaitForHangUp} tags
• Major Threshold Time is silence before call is dropped in seconds

Use this tag to specify that the call should be ended if recognition results are below the minimum confidence level specified on that step. For example, if a Step within a Test Case specifies the Minimum Confidence rating of 80 and is using ASR for recognition, a result returned of 79% will end the call with the following message: "Ending call: confidence too low to continue".

This tag is useful for ending a call that uses a long Test Case when a specific step fails, without having to wait for the entire Test Case to run to completion.

Conditions and Restrictions

• Caution: This tag causes the Step to require Priority Recognition and should not be used in load campaigns unless the Cyara ASR to Call Engine port ratio has been specifically configured.
• Minimum confidence rating of a "Satisfactory" result will still allow the test case to continue. The call will only be terminated if a step returns a "Failed" result.

The {EnhancedConfidenceAlgorithm} Tag is enabled across all Cloud Platform Cyara Accounts. This feature addresses an issue in earlier versions of the Cyara Platform, where false negative confidence scores of 0% or 3.1% were being generated due to signal interference, background noise or various other factors. Enabling the Enhanced Confidence Algorithm feature enables Cyara Call Engine Next to differentiate between different recognition algorithms to determine Word Accuracy Rate (WAR).

The Enhanced Confidence Algorithm treats all speech matching tags as Wildcard {*}. It ignores all words corresponding to speech matching tags when calculating Word Accuracy Rate (WAR).

Configuration Options

Enhanced Confidence Algorithm can be configured at platform level as follows.

• Set "Enable Enhanced Confidence Algorithm" in Platform Configuration to "Licensed" to enable Enhanced Confidence Algorithm at platform level.
• Set "Enable Enhanced Confidence Algorithm" in Platform Configuration to "False" to disable Enhanced Confidence Algorithm at platform level.

Enhanced Confidence Algorithm can also be configured at account level as follows.

Select "Enhanced Confidence Algorithm Type" in Features tab in Account Details page:

• Disabled : Enhanced Confidence Algorithm is disabled for the account.
• Lenient : The account will use Lenient Enhanced Confidence Algorithm by default.
• Strict : The account will use Strict Enhanced Confidence Algorithm by default.

Examples of Usage

To control how Word Accuracy Rate (WAR), we use the {EnhancedConfidenceAlgorithm} Tag which can be specified with the following options.

1. {EnhancedConfidenceAlgorithm Lenient} - Default and not need to be specified, uses Levenshtein String Distance algorithm
2. {EnhancedConfidenceAlgorithm Strict} - Strict algorithm uses NIST alignment algorithm
3. {EnhancedConfidenceAlgorithm Disabled} - Can be used to disable Enhanced Confidence for a specific recording or Test Case.

The {EnhancedConfidenceAlgorithm} Tag can be used in the Expect to Hear field, or the notes field to apply to all Steps within the Test Case.

Conditions and Restrictions

• The Enhanced Confidence Algorithm is not used when an Expect to Hear field contains more than one Choice tag. In these instances the standard ASR Algorithm is used for recognition.
• The Enhanced Confidence Algorithm is not applicable to Priority steps regardless of Campaign type.
• The Enhanced Confidence Algorithm is not compatible with Cruncher Campaigns.

The Cyara Support Knowledge Center also features additional use cases and examples of how to use the {EnhancedConfidenceAlgorithm} effectively in Cyara Test Cases.

Use this tag in the Expect To Hear field to indicate that a Fax tone is expected (specifically, a 2100±15Hz fax CED tone in with accordance with RFC 4734) within the Major Threshold Time. Note that all other audio (speech, tones, silence, and so on) is ignored while waiting. The expected fax tone must be between 2.6 and 4 seconds in length. If an entire, valid fax tone is not heard within the Threshold, the Step is flagged as a failure and the call is abandoned, otherwise the call continues – typically, there are no further Steps, so the call is ended and flagged as an overall success.

The Response Time is the time to the beginning of the fax tone.

The Fax Tag accepts an optional argument Duration=min[-max]

This new argument allows users to control what duration CED tone is acceptable as a fax tone.

Values are in milliseconds with a Default min=2400 & max=4200

Examples: {Fax Duration=1500} will accept CED tone duration between 1500ms and 4200ms (as the max was not specified the default is used.

{Fax Duration=3500-5000} will accept CED tone duration between 3500ms and 5000ms

Example: {Fax}

This tag skips a part of the call flow. The period to ignore is specified in seconds in the PSST field and the period begins at the end of the previous Step. The Reply With portion of the Step (if specified) begins after the ignore period.

Conditions and Restrictions

• Only allowed at the beginning of the Expect to Hear field, and may be followed by additional text (useful to keep some description of what is being ignored)
• Any additional text is ignored
• No spaces are allowed before the tag
• No Step recording is available for a Step using this tag but the audio recorded is available in the whole call recording
• Step with {Ignore} tag, no reply and PSST 0 cannot be followed by a MultiStep Prompt.
• The Major and Minor Threshold fields are ignored for a Step using this tag.

Testing IVRs that offer customer interactions in a range of different language is becoming more common, and Cyara's {Language} Tag gives you the flexibility to nominate different languages to be recognised for a given Test Case Step. Having the ability to specify a Language instructs the Cyara Speech Recognition to listen for the nominated language, and all of the unique grammar, syntax and wording that is involved, allows you to create a comprehensive multi-lingual testing suite easily.

The {Language} Tag overrides your nominated Cyara Account default recognition language with a new one, for only the Test Case step where it is included. Subsequent steps will return to the Account default language. The selection of language is determined by the country code specified inside of the Tag.

Conditions and Restrictions

• The {Language} tag can be used multiple times within a step, this is particularly useful for multi-lingual IVRs that switch between multiple languages within menus.
• Any expect to hear text after the {Language} tag will be transcribed in the specified language from the Tag.
• This tag operates on a step level, if you set the{Language} tag on one step, the next step will still use the default Language.
• If no {Language} tag is set, then the default Language for that account is used for recognition.
• You can override the default language for an entire Test Case by entering the {Language} tag into the Notes field of a Test Case.

Example of usage:

The following example scenarios cover a range of applications of the {Language} Tag to improve Test Case recognition scores for IVRs that are engaging with customers in a range of languages.

Language Tag Scenario 1.

In this scenario, we are deploying a new contact centre that caters for customers in Spanish. Most of our Cyara Test Cases are testing our US-English contact centres and swapping the account default language back and forth is not workable. To resolve this situation, we can nominate Test Case Steps in our Cyara Test Case to recognise a language other than our Account default.

Note: In the above scenario, rather than specifying the Language on each Test Case Expect to Hear field, you could instead write {Language us-ES} into the Notes field on the Test Case. Applying the {Language} Tag to the notes field on a Test Case overrides the default language for All steps within that Test Case.

Language Tag Scenario 2.

In this scenario we again have a welcome prompt that offers two options, both of which are spoken in different languages. However in this scenario this welcome menu switches between both offers very quickly, and as such will be built as a single Cyara Test Case step

Language Tag Scenario 3.

Another application for the {Language} Tag is to improve test case recognition results for IVRs that speak in accents that could be challenging for Speech Recognition that has been trained on speech for a different country (The differences between Australian and American English for example).

In the below example, we have an Australian Bank opening main menu message. However the "Latest Promotion" text is spoken by someone with an American accent, which is delivering poor speech recognition results.

The {MaxAudioLength} Tag is a functional Cyara Test Case Tag used to perform a single unique function. This Tag is used to specify a maximum duration in whole seconds for the audio heard in this Test Case Step (starting from the beginning of audio heard, skipping any leading silence).

This Tag is unique in it's application in that it will not only mark a Test Case Step as Failed, it will end the call if it does not pass. If the audio duration exceeds the supplied amount of time specified in the Tag, the call is ended immediately with the reason "Abandoning call because audio length exceeded maximum duration". This tag is useful for ending a call that has audio that goes on too long (for example, hold music that lasts too long).

Conditions and Restrictions

• Maximum time entered in seconds
• Cannot be used with
• As this Tag is listening for a Maximum amount of audio to be heard in a single test case step, this tag can notbe used with the {BargeIn}, {Ignore}, or {WaitForHangUp} Tags.
• If this tag is used in a Multi-Step prompt (A prompt that is covered by multiple steps in the Cyara Test Case), it must only be placed on the initial sub-step. (If this tag is used in subsequent sub-steps within this multi-step prompt they will be ignored.

Examples of usage:

The {MaxAudioLength} Tag will hangup the call if the audio heard for a step is longer than the specified maximum value, this tag is best used on Test Case Steps where terminating the call is appropriate.

In this example we want to confirm that a customer can be placed within a secondary hold queue, and we want to ensure that they can hear at least the first 60 seconds of hold music. We also don't want to leave the Test Case running forever so we can terminate the call after this 60 seconds of hold music is heard.

In the above example, The Cyara Speech Recognition will be performed on Step 1 where we expect to hear "Welcome to Assure Bank, please hold". Then the 2nd Test Case Step will wait for a maximum of 60 seconds of listening to audio before terminating the call with the reason "Abandoning call because audio length exceeded maximum duration".

This tag is used to alter the way Test Step response time is measured. Use this when you need to measure the time to ringback, music, or any other non-speech sound.

Normally, a Step's response time is determined as the time from the end of the previous Step until the time ‘speech’ is heard (Beginning of Speech). However, if music or non-speech audio is present at the beginning of the response, the response time would be reported as longer than expected, because the music will form part of the response time.

The response times with the {MeasureResponseTimeTo} tag are as shown:

The {MeasureResponseTimeTo x} tag causes the Step response time to be calculated from the end of the previous Step to when audio or speech is heard. There are two options that can be specified for the tag:

{MeasureResponseTimeTo BeginningOfSpeech} (default)

{MeasureResponseTimeTo BeginningOfAudio}

Both options are illustrated below.

The default case is to measure response time from the end of the last Step to the start of any recognized speech. When the Expect to Hear prompt contains non-speech audio, it will lead to longer response times being reported.

The MeasureResponseTime tag used with an option of BeginningOfAudio will measure response time from the end of the last test Step to the start of any speech or audio detected.

The MeasureResponseTimeTo examples are as shown:

Conditions and Restrictions

• The MeasureResponseTimeTo tag is only allowed at the beginning of the Expect to Hear field and must be followed by additional text.

Conditions and Restrictions

• If an optional variable is specified, the variable result cannot be used in a subsequent dynamic reply
• Individual digits must be pronounced after any decimal point (natural numbers not allowed)
• Numbers from 0 to 999,999,999.99 can be recognized
• The {Number} tag has an optional parameter called MaxDecimal. The MaxDecimal parameter controls the number of decimal places that are allowable, the default value is 2, the minimum is 0, and the maximum is 9.

  An example of setting MaxDecimal attribute, note the space between Number and MaxDecimal: {Number MaxDecimal=4}

  This will match and return a result with 4 digits after the decimal point like 5.1234.

The two different "{Optional}" Tags are used to mark a Cyara Test Case Step as "optional" for situations where prompts may or may not be played. For example, high-volume messaging, confirmations, holiday messages, and promotions.

If a Step is marked as optional, then it will be skipped if a prompt is heard that does not match its criteria. The prompt is considered absent if a prompt of matching criteria is not heard – it is marked as "Skipped" in the Step results and the Test Case will continue to the next Step.

When the criteria of an optional Step is matched, any reply specified in the Reply With field is played before continuing to the next Step.

The Optional tag supports two different ways of specifying these matching criteria, follow below for more information on the two implementations of the Optional Tag:

{Optional AudioLength=range}

{Optional AudioLength=3.5-4.5}

Expect To Hear.

In the above example, if the duration of audio in the captured Step recording for the Step that contains this Tag (from the beginning of audio until the end of audio) is between 3.5 and 4.5 seconds long, then the subsequent Reply With field is played.

If the audio duration is not within the range, Cyara then considers the optional Step as "absent" and will proceed to try to match the captured Step recording with the following Step’s Expect To Hear.

{Optional AudioLength=range}Conditions and Restrictions

• The {Optional AudioLength=...} Tag must be included at the start of the Expect to Hear field.
• The Tag requires a range of two values in seconds separated by a -
• The PSST of the Step that contains the Optional tag and that of the following Step must be the same.
• For the AudioLength form of the Optional tag, the optional Step must be distinguishable from the following non-optional Step by audio duration alone (as in, if both optional Step and following Step have similar durations, then using the {Optional AudioLength=...} form of the Optional tag will not work – consider using the {Optional Speech} form of the tag instead).
• The Audio Length of the step that contains the {Optional AudioLength=...} can not overlap with the audio length of the next step.
  • For example if you had a Test Case Step using {Optional AudioLength=5-10} (a range of 5-10seconds would trigger this step).
  • The subsequent Step must not be within this 5-10 seconds range.
• The {Optional} tag can not be followed immediately by another Step containing an {Optional} tag of either form.
• BargeIn, Optional, Ignore, and WaitForHangup tags cannot be used on the Step following a Step containing the {Optional AudioLength=...} form of the tag.

Examples of usage:

The following two examples demonstrate different scenarios that cover the usage of the{Optional AudioLength=...} form of the tag, in how it determines matching prompts.

{Optional AudioLength=range} Scenario 1.

In this scenario we want to trigger a Reply With Step within a Cyara Test Case based on hearing a section of audio that is within a given range. Here we can simulate a customers verbal response after being played the pre-recorded queue busy message of "Due to unusually high call volumes, you may encounter longer wait time.

Note: To play the Reply With speech to the remote party, the Reply With field must be completed on the Same Step that contains the {Optional AudioLength=...} Tag as follows.

{Optional AudioLength=range} Scenario 2.

Expanding on the example above, we show what the {Optional AudioLength=...} Tag would do if the audio heard was outside the expected range. In this example we will use the same Test Case setup as before, but play it different audio (we will play audio of a normal non-busy queue).

The Optional tag is useful in allowing you to setup a single Test Case that covers multiple scenarios.

{Optional Speech}

With the Speech form of the Optional tag, the Platform considers the optional Step present if the captured Step recording matches the text following the tag. The Platform uses speech recognition immediately after the PSST of the Step has expired to try to match it with the text.

If the recognition matches, the optional Step is considered to be present. Otherwise, the optional Step is marked as “Skipped” in the Step results and matching of the captured Step recording continues to the next Step.

Conditions and Restrictions

Examples of usage:

The following two examples demonstrate different scenarios that cover the usage of the {Optional Speech} form of the tag, in how it determines matching prompts. These examples also highlight the differences between the {Optional AudioLength=...} form and {Optional Speech} form and their advantages.

{Optional Speech} Scenario 1.

In this scenario we want to trigger a Reply With Step within a Cyara Test Case based on hearing a section of audio that is within a given range. Here we can simulate a customers verbal response after being played the pre-recorded queue busy message of "Due to unusually high call volumes, you may encounter longer wait times.

Note: To play the Reply With speech to the remote party, the Reply With field must be completed on the Same Step that contains the {Optional AudioLength=...} Tag as follows.

{Optional Speech} Scenario 2.

To highlight the advantage of the {Optional Speech} form of this Tag, what if the length of the audio heard for a Test Case Step was the exact same duration as the subsequent Step? (If our main menu text was the exact same duration as the high call volume warning). The way to solve this issue would be to use the {Optional Speech} form of this Tag as follows.

The {RemoteMOS} tag is used to collect a MOS score from the remote end (for use with AGDs).

Conditions and Restrictions

• Currently this tag is only supported when the language is English for the Step. So, if you are using this tag in a Step on an account that is configured for a non-English language as the default language, you will have to add a {Language en-US} (or en-AU or en-GB) tag before it. This is because the remote end (AGD) conveys its MOS score as English words (for example, "three point seven").

Use this tag to indicate that a Step can be repeated for a maximum number of repetitions or not appear at all.

The MaxRepetitions attribute must be a whole number within the range of 1-100; if not specified, the default is 100.

Example of usage:

1. {Repeat 5}Please wait
2. {Repeat}{Choice Please wait|Your call is important to us|Operator will be with you shortly}

Conditions and Restrictions

• Repeat tag should not be used in Cruncher load testing Campaigns

• The PSST on the Step marked with the Repeat tag must be equal to the next Step's PSST
• This tag can not be used on the same Step as the following tags: Optional, BypassRecognition, Ignore, WaitForHangup, AllowHangUpInReply, BargeIn, DTMF, RemoteMOS, or Fax.
• The Step following a Repeat Step cannot include the following tags: Optional, Ignore, WaitForHangup, DTMF, RemoteMOS, or Fax.
• The Repeat Steps are not allowed to have replies.
• This tag cannot be on the last Step.
• The Repeat Step cannot follow another Repeat Step.

The {Sensitivity <level>} tag can be applied at the Step level in the Expect to Hear field and also at the Test Case level in the Notes field. The {Sensitivity <level>} tag enables users to set a Sensitivity level to distinguish the speech activity from the audio activity before the Cyara Call Engine triggers the PSST algorithm. The Cyara Call Engine records the audio from the calls it has made and then chops it up according to Post Speech Silence Timeout (PSST) to make the audio for each Step.

As part of this process, it looks at the silence periods that follow audio activity. Without recognizing what the activity is, once it stops and a silence starts, the PSST cutting algorithm is triggered. The issue here is that the Cyara Call Engine is unable to distinguish the audio activity of noise from the audio activity caused by speech. If the recording is noisy or there are other sounds happening during the call, then the cutting up of the audio will not match the Steps of the Test Case and hence a bad Test Case result will occur.

To fix this issue, the {Sensitivity <level>} tag is applied to audio recordings that will prevent the audio activity. The {Sensitivity <level>} tag sets the sensitivity level of the voice detector. A value of 1.0 means that it is highly sensitive to quiet input. A value of 0.0 means it is least sensitive to noise. The default value is 0.5.

Syntax

{Sensitivity <level>}, where the parameter, level ranges from 0 .. 1

The {SetStepResult StepResult=result Details="details"} tag is allowed only with the action part of a {Choice} tag (that is, after the colon) to specify that the Step's result should be set to a specified value or a default of Failed if the option part of the choice is heard (that is, before the colon). This tag can be used with multiple options in a Choice. If an option is heard, the Step is marked with the specified result (Success, Satisfactory, or the default Failed). If the optional Details argument is specified, the details text will be included in the Detailed Step Result, otherwise it will contain something like this "SetStepResult override from: 'Success'"

This Tag can be used for fine-tuning of recognition if the difference in speech does not yield a sufficiently high or low result.

In the above ETH, the only difference is the word 'card' versus 'cards'. Normally, ASR will not produce very different confidence scores if the wrong variant of ‘card’ is heard in the prompt.

The SetStepResult tag can be used to override the result.

For example, consider this Expected To Hear: You will receive your {Choice card|cards:{SetStepResult StepResult=Failed}} by mail within the next 3 working days.

This ETH tells the Cyara Platform to set the Step result to “Failed” if the word 'cards' is heard (overriding the default “Success” Step result). If 'card' is heard, the Step result is unchanged as “Success”.

The {Time} is used to recognize a spoken time in a prompt. Examples of time formats are shown in the Table below. The {Time} tag is very flexible and can be used to recognize many different time formats in the active language.

Conditions and Restrictions

• If an optional variable is specified, the variable result cannot be used in a subsequent dynamic reply

This tag is used to indicate that the call should not be terminated by the Cyara Platform after the last Step, but the Cyara Platform should wait for the far end to hang up.

Conditions and Restrictions

• Only allowed on the last Step
• No spaces before or after the tag
• Minor and major threshold specifies the time (in seconds) for which the Call Engine should wait for the far end to hang up. If the far end hangs up within the minor threshold duration, the Step result will be reported as successful. If the IVR hangs up within the range of minor and major threshold durations, the Step result will be reported as satisfactory. If the IVR hangs up after the major threshold duration, the Step result will be reported as a failure and the Cyara Platform will terminate the call
• PSST field is ignored
• No Step recording is available for a Step using this tag but the audio recorded is available in the whole call recording.

This is a dynamic reply variable from a Choice.

This tag can be used in the Reply With field to insert certain variables to reply in a Step.

Examples:

{Insert DNIS Range="7-10" Separator="," Suffix="#"} will insert digits 7 to 10 of the DNIS with each digit separated by commas and with a # at the end. So if DNIS was 8005551234, the inserted value would be: "1,2,3,4#". Note that separators are only placed between characters and not after the last one.

{Insert CLI Default="unknown caller"} will insert all digits of the CLI unless there is no CLI (it is blank or not available), in which case it will insert the string "unknown caller".

{Insert TimeHHMMSS Range="1-2"}:{Insert TimeHHMMSS Range="3-4"} expands to 00:29, on 08/11/2012 12:29:10 AM UTC.

Syntax

{Insert variable modifier1="value1" modifier2="value2" ...}

All modifiers are optional and multiple modifiers can be combined.

Valid modifiers:

Conditions and Restrictions

• This tag can be used with other Insert tags as well as mixed with normal text in the Reply With field. It can be used with either Speech or DTMF replies
• This tag is not available for the Expect To Hear prompt

This tag can be used in the Reply With field to speak the content of the following Service Step variable as spoken digits . By default the en-US male voice is used. Supported Digits 0-9. (spoken as point), * (spoken as star) and # (spoken as hash)

The main use for this tag is to support Voice Application testing with 2 Factor Authentication.

Conditions and Restrictions

• This tag can Only be used on the Reply With field before a {$variableName} Tag which is assigned by a Service Step.
• Invalid Characters will be skipped, eg. "1A2B*" will be spoken as "One Two star" A and B are skipped.

Examples of usage:

"{SayDigits} {$pin}"

This tag can be used in the Reply With field to insert MOS result into the reply. The MOS result will be spoken back into the call. By default the en-US male voice is used.

Conditions and Restrictions

• This Tag can not be used with any other tags in a Test Case step.
• This tag can Only be used on the Reply With field of a PESQ step in a Test Case.

The {Voice} tag is used for Text to Speech replies that deviate from the default Text to Speech language on a particular Step.

Conditions and Restrictions

• This tag can only be used at the beginning of the Reply With field and there can only be one {Voice} tag per Step.
• This tag is only relevant for Speech Reply types.
• The {Voice} tag operates on a step level, if you set a {Voice} tag on one step, the next step will still use the default Language.
• You can override the default language for all Text To Speech replies within a test case, to do this enter the {Voice} tag into the Notes field of the test case.
• This tag is not enabled by default. Please contact Cyara Support for any enquires relating to enabling use of this tag.

Examples of usage:

{Voice <country>|<name>, <name>}

For example, {Voice Australian English, Karen}

This tag logs additional information to the Detailed Result field of a Test Case result. The options are a comma-separated list of elements you would like logged for this call:

The Result Details for a call made with a LogInfo with all options specified might look like:

Step 0: Response time exceeded Minor Threshold Time of 5 seconds. { "Ticket": "b9b7cdcd-93b9-4bca-8351-e6f02bd06842", "CallID": "6912b48d-e8e5-4407-902d-b9d7bca066de", "CallEngineID": ".112" }

This tag is the same as the Language tag in the Expect to Hear field, but specifies the default speech recognition language for all Steps in the Test Case.

Conditions and Restrictions

• A {Language} tag in the Expect to Hear field overrides this value

This is the same as the Voice tag in the Reply With field, but specifies the default TTS voice for all Steps in the Test Case.

Conditions and Restrictions

• A {Voice} tag in the Reply With overrides this value

This tag is the same as the Sensitivity tag in the Expect to Hear field, but specifies the default sensitivity for all Steps in the Test Case.