The Tags described in this article can be used in Voice Test Cases. All Tags are supported within CX Models and these Tags flow through to the generated Test Cases.
Choice
Tag is currently the only Tag that
supports storing data within a variable for use in subsequent Test Case steps. Phone Number Tags
Tag: {Codecs codec1[,codec2[,...]}
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.
Tag: {EarlyMedia}
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.
Expect to Hear Tags
Tag: {*}
(Wildcard)
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.
Actual Audio Heard | Expect to Hear | Outcome |
---|---|---|
Hello and Welcome to Assure Bank, Welcome Back David, Please Hold |
Hello and Welcome to Assure Bank, Welcome Back
|
Successful: The actual audio heard does match the
text in the Expect to Hear field, with the exception of the
spoken customer name "David". The Expect to Hear field
contains the |
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.
Actual Audio Heard | Expect to Hear | Outcome |
---|---|---|
Hello and Welcome to Assure Bank, Please Hold, (Hold Music), Your call is important to us, (Hold Music), a representative will be with you shortly. | Hello and Welcome to Assure Bank, Please Hold, {*} ,
Your call is important to us, {*} , a
representative will be with you shortly. |
Successful: Using the {*} Wildcard Tag
multiple times within the same Expect to Hear text is supported,
and is particularly useful for longer prompts that are broken up
by audio clips that might not pass speech recognition such as
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.
Tag: {AGD}
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"}
{AGD
Length=4-6}
Tag: {AllowHangUpInReply}
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.
Tag: {AlphaNum}
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
Parameter | Description |
---|---|
Length | Optional parameter but recommended for improved accuracy. The exact length is best, a range is second best, and no length at all will give least accuracy |
<variable> | Optional parameter that takes the form of
$variablename. The variable will be populated with the
results of the {AlphaNum} recognition. You can also
specify a comparison to be made against the variable. If the
comparison fails, then the Step will fail with the Detailed Step
Result including "Expected 'variablename' to be
'expectedValue' but was 'actualValue'" |
Examples of usage:
- {AlphaNum Length=6 $postcode}
- {AlphaNum Length=4-6}
- {AlphaNum $id}
- {AlphaNum Length=6 $id == "K2G4A3"}
Tag: {BargeIn}
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.
Tag: {BypassRecognition}
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)
Tag: {Choice}
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").
- In this example,
- 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"}
- You can use the
- 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.
Actual Audio Heard | Expect to Hear | Step Outcome |
---|---|---|
(During Business Hours) Welcome. For telephone banking, press 1. To report a stolen card, press 2. (After Business Hours) Welcome. Our office is now closed. For telephone banking, press 1. To report a stolen card, press 2. | Welcome. {Choice Our office is now
closed.|.} For telephone banking, press 1. To report a
stolen card, press 2. |
Successful: This single Expect to Hear prompt will match both of the potential audio sets heard. The Choice Tag offers the "Our Office is Closed" prompt, as well as a "." to match with no additional prompt. |
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).
Actual Audio Heard | Expect to Hear | Step Outcome |
---|---|---|
Please enter the second digit of your PIN | Please enter the {Choice
pin1=first:6|second:5|third:4|fourth:3} digit of your
PIN |
Successful: The prompt will be matched using choice "second". This will set a value of "5" into the variable named "pin1". The variable pin1 can be used in Step Reply With field as {$pin1} |
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.
Actual Audio Heard | Expect to Hear | Step Outcome |
---|---|---|
Hello, this is Adam speaking. | Hello, This is {Choice Var1=Adam:.|Barry:,} speaking. | 2.0 Seconds of Silence |
Hello, this is Barry speaking. | Hello, This is {Choice Var1=Adam:.|Barry:,} speaking. | 0.2 Seconds of Silence |
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}
Tag: {Currency}
Language | Currency | Example |
---|---|---|
en-AU | AUD | Two Australian dollars and fifty two cents |
en-AU | none | two dollars and fifty two cents |
en-GB | EUR | two Euros and fifty cents |
en-GB | GBP | two pounds and fifty pence |
en-GB | none | two fifty |
en-US | USD | two U S dollars and fifty cents |
en-US | none | two dollars fifty cents |
es-US | MXN | cinco pesos y cinco centavos |
es-US | none | cinco dólares y cinco centavos |
ja-JP | JPY | にてんれいいちえん |
nl-NL | EUR | vijf euro en vijf cent |
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.
Actual Audio Heard | Expect to Hear | Outcome |
---|---|---|
Your account balance is two dollars and fifty two cents | Your account balance is
{Currency}
|
Success: When the active language is en-US or en-AU, any prompt saying a valid dollar (or cents-only) amount will match and this Step will be marked 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.
Actual Audio Heard | Expect to Hear | Outcome |
---|---|---|
Your account balance is two pounds and fifty two pence | Your account balance is {Currency
$var == 2.52}
|
Success: As the active language for
this account is set to en-GB, the {Currency}
Tag would correctly recognise British Pounds. The supplied value
of Two Pounds and Fifty Two pence would match 2.52 so the test
case step is marked as Success. |
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.
Parameter / Operation | Syntax | Description |
---|---|---|
<$VariableName> |
{Currency $VariableName}
|
The {Currency} Tag supports
the optional Variable parameter. This variable will be populated
with the results of the {Currency} recognition.
Using this Variable you can also make comparisons against the
Variable, if this comparison fails the step will fail and post a
detailed result as follows. "Expected 'VariableName' to be 'ExpectedValue' but was 'ActualValue' |
<$VariableName> EqualTo |
{Currency $Variablename == 2}
|
{Currency} Tag variables can also be used to return a successful step outcome, when the recognised digits Do Match a provided value by using the == (EqualTo) Operation. |
<$VariableName> NotEqualTo |
{Currency $Variablename != 2}
|
{Currency} Tag variables can also be used to return a Successful Step result for a digit that Does Not Match by using the =! (NotEqualTo) operation. |
<$VariableName> GreaterThan |
{Currency $Variablename > 2}
|
Check if the supplied currency is Greater than the supplied value by using > (GreaterThan) operation. |
<$VariableName> LessThan |
{Currency $Variablename < 2}
|
Check if the supplied currency is Less than the supplied value by using > (GreaterThan) operation. |
<$VariableName> GreaterOrEqualThan |
{Currency $Variablename >= 2}
|
The Greater Than or Equal To operations can be combined in the same operation by using the "GreaterOrEqualThan" Operation. If the supplied variable is 2 or greater this example will be marked as Successful. |
<$VariableName> LessOrEqualThan |
{Currency $Variablename <= 2}
|
In the same way, Less Than or Equal To operations can be combined into a single operation by using the "LessOrEqualThan" Operation. If the supplied variable is 2 or less this example will be marked as Successful. |
Tag: {Date}
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
{Date}
Tag are as shown below for US
English:
Example Prompt |
January fifth two thousand |
Yesterday |
Today |
Tomorrow |
the fourth |
June four |
June fourth |
fourth June |
Wednesday the twelfth |
June fourth nineteen ninety seven |
June four ninety seven |
Wednesday June four ninety seven |
four six |
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.
Actual Audio Heard | Expect to Hear | Outcome |
---|---|---|
The date today is the 4th of June 2014 | The date today is the {Date}
|
Successful: Any audio heard that matches a valid date mark this step as successful. Check the above table for examples of valid spoken dates. |
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.
Actual Audio Heard | Expect to Hear | Outcome |
---|---|---|
The school holidays will start on Monday the 5th of July |
The school holidays will start on |
Successful: The audio heard must not only contain a date, but that date must also be July 5th (the ???? in the comparison indicates that a year is not expected to be heard. |
Tag: {Digits}
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.
Language | Example |
---|---|
en-AU | zero one two three four five |
en-AU | one oh five |
en-GB | zero one two three four five |
en-GB | one oh five |
en-US | zero one two three four five |
en-US | one oh five |
es-US | dos tres dos uno |
es-US | cinco |
ja-JP | 零一二三四五六七八九 |
nl-NL | drie vier vijf |
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.
Actual Audio Heard | Expect to Hear | Outcome |
---|---|---|
The service department number is 9 8 7 6 5 4 3 2 1 | The service department number is {Digits} | Successful: As long as the spoken telephone number does not exceed 20 digits, this step will return a successful outcome independent of the actual digits spoken. |
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.
Actual Audio Heard | Expect to Hear | Outcome |
---|---|---|
Your telephone account PIN is 9 8 9 8 | Your telephone account PIN is {Digits Length=4} | Successful: As long as the spoken telephone number does not exceed 20 digits, this step will return a successful outcome independent of the actual digits spoken. |
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.
Actual Audio Heard | Expect to Hear | Outcome |
---|---|---|
Your telephone account PIN is 9 8 9 8 7 | Your telephone account PIN is {Digits Length=4-6 $PIN == 55121} | Failed: In this example, the number of spoken digits was within our range (5 digits were spoken and our set range was from 4-6 digits). This recognition would then set the $PIN Variable to "98987", then run the comparison to the provided "55121". As the supplied pin was not the expected value, this step will fail and return the following detailed result. "Expected PIN to be 55121 but was 98987" |
Optional Parameters and Operators for the Digits Tag.
The {Digits} Tag supports the following additional optional parameters and operators.
Parameter / Operation | Syntax | Range | Description |
---|---|---|---|
Length | {Digits Length=X} | 1-20 | X is the number of digits to Recognize. Note: X can not be greater than 20 |
<$VariableName> | {Digits $VariableName} | n/a | The {Digits} Tag supports the optional Variable parameter. This variable will be populated with the results of the {Digits} recognition. Using this Variable you can also make comparisons against the Variable, if this comparison fails the step will fail and post a detailed result as follows. "Expected 'VariableName' to be 'ExpectedValue' but was 'ActualValue'. |
<$VariableName> EqualTo | {Digits $Variablename == "2"} | n/a | {Digit} Tag variables can also be used to return a successful step outcome, when the recognised digits exactly match a provided value by using the == (EqualTo) Operation. |
<$VariableName> NotEqualTo | {Digits $Variablename != "2"} | n/a | {Digit} Tag variables can also be used to return a Successful Step result for a digit that does NOT match by using the =! (NotEqualTo) operation. |
<variable> | None. | Not Applicable. |
Optional parameter that takes the form of
$variablename. The variable will be populated
with the results of the $variablename can also be used as to return a PASS for a digit that does NOT match using the following syntax.
|
Tag: {DTMF $variablename}
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.
Tag: {EndCall StepResult=result
Details="details"}
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.
Attributes | Values |
---|---|
StepResult | Failed, Success, Satisfactory |
Details | "Any text" in double quotes (Note the quotes in the example tag above) |
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:
Greeting type | Meaning to Ops team |
---|---|
Normal phone banking greeting | Green - System is operational |
Technical difficulties greeting | Red - System is experiencing unexpected issues |
Upgrading IVR greeting | Yellow - System is under maintenance - calls transfer to agents after greeting |
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"}}
Actual Audio Heard | Outcome |
---|---|
Welcome to ABC Bank. For telephone banking press 1. To speak with a banking representative, press 2. | Step 1 marked as “Success” and the call proceeds to the reply of Step 1 (e.g. replying with DTMF 1). |
Sorry, we are experiencing technical
difficulties. Please call back later. <IVR hangs
up>
|
Step 1 marked as “Failed” with Detailed Step Result containing “ERROR: Tech Diff”. The call ends. |
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.
<pause, then transfers to agent
queue>
|
Step 1 marked as “Satisfactory” with Detailed Step Result containing “Maintenance Mode” and Cyara ends the call during the pause before the call is transferred to an agent. |
<garbled, unintelligible audio>
|
Step 1 marked as “Failed” and call ends due to none of the specified choices matching and Detailed Step Result contains "Ending call: confidence too low to continue" |
Tag: {EndCallIfNoAudioWithinThreshold}
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
Tag: {EndCallIfNoMatch}
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.
Tag: {EnhancedConfidenceAlgorithm}
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.
-
{EnhancedConfidenceAlgorithm Lenient}
- Default and not need to be specified, uses Levenshtein String Distance algorithm -
{EnhancedConfidenceAlgorithm Strict}
- Strict algorithm uses NIST alignment algorithm -
{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.
Tag: {Fax}
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}
Tag: {Ignore}
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.
Tag: {Language}
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.
Actual Audio Heard | Expect to Hear | Outcome |
---|---|---|
Hola, bienvenido al banco de ejemplo |
{Language us-ES} Hola, bienvenido al banco de
ejemplo |
Successful: The actual audio heard does match the
Spanish text in the Expect to Hear field, and the
|
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
Actual Audio Heard | Expect to Hear | Outcome |
---|---|---|
Welcome, for English press One, Hola, para español presione dos. | Welcome, for English press 1
{Language us-ES} ola, para español presione
dos. |
Successful: As long as the default language is set to
en-US (English), the first half of the opening prompt will
be recognised in English, and the introduced
|
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.
Actual Audio Heard | Expect to Hear | Outcome |
---|---|---|
G'day and welcome to Australia Bank, have you heard about our latest promotion | G'day welcome to Australia Bank,
{Language en-US} have you heard about our
latest promotion |
Successful: Assuming that the default language on
this Cyara Account is set to en-AU. Inserting the
|
Tag: {ListenForPsstAfter}
The {ListenForPsstAfter}
tag ignores any silence periods that
fall within the time specified in this tag and start detecting for any silence
only after the timer has expired.
Conditions and Restrictions
- Incompatible tags List:
{Ignore}
,{BargeIn}
,{Repeat}
,{Optional AudioLength}
,{Optional Speech}
,{WaitForHangUp}
,{Fax}
. - The
{ListenForPsstAfter}
tag value should be greater than or equal to 0 and less than or equal to 21599. - Multiple instances of this tag are not allowed within the same step.
- 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.
Example of usage:
In the example screenshot below, you can see the first Ignored Leading Silence
in Red, The {ListenForPsstAfter}
tag value in Orange, A block
of ignored silence that falls inside the {ListenForPsstAfter}
value period in Green, and finally the value actually counted towards the PSST
highlighted in Black.
Tag: {MaxAudioLength}
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".
Tag: {MeasureResponseTimeTo BeginningOfAudio} / {MeasureResponseTimeTo
BeginningOfSpeech}
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:
Actual Audio Heard | Expect to Hear | Outcome |
---|---|---|
(music) Your account balance is $1000 |
{MeasureResponseTimeTo
BeginningOfAudio} Your account balance is one
thousand dollars |
Response time is measured from end of last Step to the start of music |
(music) Your account balance is $1000 |
{MeasureResponseTimeTo BeginningOfSpeech} Your
account balance is one thousand dollars |
Response time is measured from end of last Step to the start of the word “Your” |
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.
- If the previous Step had a reply, then the next Step’s response time is measured from the end of the reply (end of the DTMF, Speech, or AudioFile).
- If the previous Step did not have a reply, then the next Step’s response time is measured from the end of the audio heard in the previous Step. The PSST of the previous Step is considered part of the next Step's response time.
Tag: {Number}
{Number}
tag recognizes numbers spoken naturally instead of a
sequence of individually spoken digits. Examples of prompts that can be matched by
the {Number}
tag are shown in the Table below:
Language | Example |
---|---|
en-AU | zero point one |
en-GB | nine hundred and ninety nine million nine hundred and ninety nine thousand nine hundred and ninety nine point nine nine |
en-US | twenty five |
en-US | twelve thousand three hundred forty five |
en-US | twelve hundred |
en-US | fourteen point five six |
es-US | Veinticinco |
es-US | doce mil trescientos cuarenta y cinco |
es-US | tres punto uno cuatro uno seis |
ja-JP | にじゅうご |
ja-JP | ひゃくにじゅうさん |
ja-JP | いちまんにせんさんびゃくよんじゅうご |
ja-JP | まいなすよん |
ja-JP | じゅうよんてんごろく |
nl-NL | Vijfentwintig |
nl-NL | twaalf duizend drie honderd drieënveertig |
nl-NL | veertien komma tweeënzeventig |
nl-NL | éénendertig punt dertien |
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 calledMaxDecimal
. TheMaxDecimal
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 betweenNumber
andMaxDecimal
: {Number MaxDecimal=4}This will match and return a result with 4 digits after the decimal point like 5.1234.
Actual Audio Heard | Expect to Hear | Outcome |
---|---|---|
There are One Thousand and Four products available | There are {Number} products available | Since a valid number was heard, this Step is flagged as Success |
Your rating is Twelve point one four seven | Your rating is {Number MaxDecimal=3} | Since the number heard is a valid number and has no more than 3 decimal places, it matches and this Step is flagged as Success. If the MaxDecimal parameter had not been specified, the prompt would not have matched (or at least not with as high a confidence) because only up to 2 decimal points would have been expected |
Your rating is twelve point fourteen | Your rating is {Number $n == 12.14} | Although a valid number was heard, it was not the expected value, so the Step is marked as Failed and the Detailed Step Result contains "Expected n to be 12.14 but was 12.4" |
Tag: {Optional}
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
, andWaitForHangup
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.
Actual Audio Heard | Expect to Hear | Outcome |
---|---|---|
Due to unusually high call
volumes, you may encounter longer wait times. [audio duration=4.0s] |
{Optional AudioLength=3.9-4.1} Due to unusually high call volumes, you may encounter longer wait times. | The heard prompt is within the range expected for this optional Step. This Step's " Reply With" is played to remote party. In the example below this would be the speech "I want to speak with someone" |

{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.
Actual Audio Heard | Expect to Hear | Outcome |
---|---|---|
Welcome to ABC Bank. For Phone
Banking, press 1. For home loan enquiries, press 2. [audio duration=7.0s] |
{Optional AudioLength=3.9-4.1} Due to unusually high call volumes, you may encounter longer wait times. | Duration does not match. Optional Step is skipped (the Reply With of the Optional Step is not played). Collected step recording is used for the next Step |
{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
-
Optional Speech tag should not be used in Cruncher load testing Campaigns
- Optional tag only allowed at the start of the Expect to Hear field.
- PSST of the Step that contains the
Optional
tag and that of the following Step must be the same. - The speech recognition matching process takes some time (0.5 to 3.0 seconds), so Test Cases should take this delay into account. While speech recognition is taking place, the Platform is not listening, so it may miss some of the following prompt if that prompt begins playing before recognition has completed.
- Multiple consecutive steps can use
the
{Optional Speech}
form of the tag on an account configured to use the new CE.Next Call Engines (consecutive steps with{Optional Speech}
cannot be used on accounts using the older Call Engine technology). Consult your Account Administrator to determine which CE technology you are using. -
BargeIn
,Ignore
, andWaitForHangUp
tags cannot be used on the Step following a a Step containing the{Optional Speech}
form of the tag. -
{Language}
tags cannot be used in Optional steps, meaning that a single Optional step supports a single language.
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.
Actual Audio Heard | Expect to Hear | Outcome |
---|---|---|
Due to unusually high call
volumes, you may encounter longer wait times. [audio duration=4.0s] |
{Optional Speech} Due to unusually high call
volumes, you may encounter longer wait times. |
Prompt is matched immediately against Expected To Hear. Reply With is played to remote party, in the example below this would be the speech "I want to speak with someone" |
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.
Actual Audio Heard | Expect to Hear | Outcome |
---|---|---|
Welcome to ABC Bank. To get
started, please enter your account number. [audio duration=4.0s] |
{Optional Speech} Due to unusually high call
volumes, you may encounter longer wait times. |
Prompt does not match. Optional Step is skipped (the Reply With of the Optional Step is not played). Collected step recording is used for the next Step |
Tag: {RemoteMOS}
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").
Tag: {Repeat [MaxRepetitions]}
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:
-
{Repeat 5}Please wait
-
{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
, orFax
. - The Step following a Repeat Step cannot
include the following tags:
Optional
,Ignore
,WaitForHangup
,DTMF
,RemoteMOS
, orFax
. - 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.
Tag: {Sensitivity <level>}
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
Tag: {SetStepResult}
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.
- You will receive your card by mail within the next 3 working days.
- You will receive your cards by mail within the next 3 working days.
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”.
Tag: {Time}
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.
{Time}
Tag are:
Example Prompt |
---|
twenty twenty |
half past eight |
eight twenty in the morning |
seven fifteen p m |
quarter past seven in the evening |
twenty four hundred hours |
twenty four hundred |
Conditions and Restrictions
- If an optional variable is specified, the variable result cannot be used in a subsequent dynamic reply
Actual Audio Heard | Expect to Hear | Outcome |
---|---|---|
At the third tone the time will be 12:24 P M precisely | At the third tone the time will be
{Time} precisely |
Since a valid time is heard, the tag matches and the Step is flagged as Success |
Opening times are from 9:30 A M till 5:30 P M each weekday | Opening times are from {Time}
till {Time} each weekday |
Since both times heard are valid times, this step will be flagged as Success |
Tag: {WaitForHangUp}
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.
Reply With Tags
Tag: {$variableName}
This is a dynamic reply variable from a Choice.
Tag: {Insert}
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" ...}
Variable | Description |
---|---|
CLI | Calling party's phone number |
DNIS | Called party's phone number |
DateYYYYMMDD | Start date (in UTC) of Test Case in YYYYMMDD format |
TimeHHMMSS | Start time (in UTC) of Test Case in HHMMSS format (24-hour clock) |
All modifiers are optional and multiple modifiers can be combined.
Valid modifiers:
Modifier | Description |
---|---|
Separator | Specifies that each character of the variable should be separated by the specified string |
Prefix | Prefixes the variable with the specified string |
Suffix | Suffixes the variable with the specified string |
Range | Limits the characters of the variable to the specified range of characters. The value of this modifier is a hyphen-separated pair of 1-based indices, for example, "1-7" specifies characters 1 through 7 (inclusive) of the variable should be inserted. If there are fewer characters than the upper end of the range specifies, the result is truncated. If there are fewer characters than the lower end specifies, then the result is blank |
Default | Specifies the default (string) value to be used if no value exists for the variable or if the value is blank |
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
Tag: {SayDigits}
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}"
Tag: {SayMOS}
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.
Tag: {Voice}
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}
otes Tags
Tag: {LogInfo}
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:
-
CallID
: SIP Call-ID corresponding to this call (Inbound Tests Cases only currently) -
Ticket
: Internal Scheduler/Call Engine Ticket GUID -
CallEngineID
: last byte of the CE's signalling IP address (for example, ".112") – use this to quickly tell which Call Engine placed the call so you can easily grab the Call Engine logs 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" }
Tag: {Language code|country|language|language,
country}
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
Tag: {Voice country|name|country, name}
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
Tag: {Sensitivity <level>}
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.
Comments
0 comments
Please sign in to leave a comment.