Genesys Cloud - Main

What I normally do during the implementation and ramp-up phase is something very similar.

When I need to present and compare TTS options with a customer, I usually create one separate test flow for each of the main voices available within what the customer has contracted/licensed.

I replicate the same basic flow and configure a different TTS voice in each copy. All of them use the same Data Table with the same sample phrases, so the comparison is consistent.

For the phrases, I normally include scenarios where TTS differences or limitations are easier to notice, such as:

• Dates and times

• Currency values

• Long numbers

• Phone numbers

• Acronyms

• Proper names

• Decimal values

• Longer sentences or prompts

If there are spare DIDs available in the organization, I assign one DID to each test flow. This makes the customer session very easy because they can simply call each number and compare the voices directly.

If there are no numbers available for testing, I use the option to call the flow directly from within Genesys Cloud. In that case, I provide the customer with the exact flow name to test. Since I normally have one flow per voice, I usually include the TTS/voice name in the flow name as well, which makes it easier to identify which one they are listening to.

The main reason I started doing it this way was to prepare everything before the customer testing session.

Instead of changing the TTS voice during the meeting, republishing the flow, testing it, changing it again, and repeating the process, all the flows are already published with their respective voices.

It was the easiest way I found to anticipate that work and make the actual testing session with the customer much smoother.

So I think your Data Table approach makes a lot of sense. The only thing I would add, especially if you are planning to compare several voices live with the customer, is having one pre-published test flow per voice, all using exactly the same set of phrases.

That has worked well for me during ramp-up and customer validation sessions.

Hi Raphael,

Thanks! This is really helpful. I like the idea of having one pre-published flow per voice and using the same Data Table and sample phrases across all of them. That should make the comparison much easier.

One other question if you happen to know: when using TTS and speech recognition/STT within a Dialog Engine Bot Flow, is there an additional usage cost associated with either of these?

I've been looking through the Genesys documentation, but some of the pricing/included usage information seems to refer specifically to Virtual Agent/Agentic Virtual Agent or AI Guides, so I'm not completely clear on how TTS/STT usage is charged for a standard Bot Flow.

Would be interested to know how this works in practice.

Thanks again!

What I normally do during the implementation and ramp-up phase is something very similar.

When I need to present and compare TTS options with a customer, I usually create one separate test flow for each of the main voices available within what the customer has contracted/licensed.

I replicate the same basic flow and configure a different TTS voice in each copy. All of them use the same Data Table with the same sample phrases, so the comparison is consistent.

For the phrases, I normally include scenarios where TTS differences or limitations are easier to notice, such as:

• Dates and times

• Currency values

• Long numbers

• Phone numbers

• Acronyms

• Proper names

• Decimal values

• Longer sentences or prompts

If there are spare DIDs available in the organization, I assign one DID to each test flow. This makes the customer session very easy because they can simply call each number and compare the voices directly.

If there are no numbers available for testing, I use the option to call the flow directly from within Genesys Cloud. In that case, I provide the customer with the exact flow name to test. Since I normally have one flow per voice, I usually include the TTS/voice name in the flow name as well, which makes it easier to identify which one they are listening to.

The main reason I started doing it this way was to prepare everything before the customer testing session.

Instead of changing the TTS voice during the meeting, republishing the flow, testing it, changing it again, and repeating the process, all the flows are already published with their respective voices.

It was the easiest way I found to anticipate that work and make the actual testing session with the customer much smoother.

So I think your Data Table approach makes a lot of sense. The only thing I would add, especially if you are planning to compare several voices live with the customer, is having one pre-published test flow per voice, all using exactly the same set of phrases.

That has worked well for me during ramp-up and customer validation sessions.

In a standard Genesys Dialog Engine Bot Flow, there is already the normal Bot Flow voice usage, but the native speech services work a little differently.

For TTS, Genesys Enhanced TTS is included without additional charge when used within Dialog Engine Bot Flows. So, in your case, using Amazon Polly Olivia NTTS through Genesys Enhanced TTS should not add the normal per-character Enhanced TTS charge while it is being used inside the Bot Flow.

Outside of that scenario, Enhanced TTS does have character-based pricing, and more advanced voices such as NTTS are normally priced higher.

For STT, I haven't personally used it in this type of implementation yet. From the documentation, Genesys provides its Enhanced STT engines as part of the Bot Flow experience, and I couldn't find a separate usage charge documented for the native engines beyond the normal Dialog Engine Bot Flow usage.

If you use a third-party STT integration, such as Microsoft Azure or Google Cloud STT, additional BYOT usage charges may apply.

These are the references I found:

Genesys Enhanced TTS pricing
https://help.genesys.cloud/articles/genesys-enhanced-tts-pricing/

TTS engines overview
https://help.genesys.cloud/articles/tts-overview/

STT engines overview
https://help.genesys.cloud/articles/speech-to-text-stt-engines-overview/

Genesys Cloud pricing hub
https://help.genesys.cloud/articles/genesys-cloud-pricing-hub/

Since this involves billing and licensing, I think it would also be worth validating it with your Genesys CSM or opening a question with Customer Care, just to make sure the pricing for your specific subscription and configuration is confirmed.

Hi Raphael,

Thanks! This is really helpful. I like the idea of having one pre-published flow per voice and using the same Data Table and sample phrases across all of them. That should make the comparison much easier.

One other question if you happen to know: when using TTS and speech recognition/STT within a Dialog Engine Bot Flow, is there an additional usage cost associated with either of these?

I've been looking through the Genesys documentation, but some of the pricing/included usage information seems to refer specifically to Virtual Agent/Agentic Virtual Agent or AI Guides, so I'm not completely clear on how TTS/STT usage is charged for a standard Bot Flow.

Would be interested to know how this works in practice.

Thanks again!

What I normally do during the implementation and ramp-up phase is something very similar.

When I need to present and compare TTS options with a customer, I usually create one separate test flow for each of the main voices available within what the customer has contracted/licensed.

I replicate the same basic flow and configure a different TTS voice in each copy. All of them use the same Data Table with the same sample phrases, so the comparison is consistent.

For the phrases, I normally include scenarios where TTS differences or limitations are easier to notice, such as:

• Dates and times

• Currency values

• Long numbers

• Phone numbers

• Acronyms

• Proper names

• Decimal values

• Longer sentences or prompts

If there are spare DIDs available in the organization, I assign one DID to each test flow. This makes the customer session very easy because they can simply call each number and compare the voices directly.

If there are no numbers available for testing, I use the option to call the flow directly from within Genesys Cloud. In that case, I provide the customer with the exact flow name to test. Since I normally have one flow per voice, I usually include the TTS/voice name in the flow name as well, which makes it easier to identify which one they are listening to.

The main reason I started doing it this way was to prepare everything before the customer testing session.

Instead of changing the TTS voice during the meeting, republishing the flow, testing it, changing it again, and repeating the process, all the flows are already published with their respective voices.

It was the easiest way I found to anticipate that work and make the actual testing session with the customer much smoother.

So I think your Data Table approach makes a lot of sense. The only thing I would add, especially if you are planning to compare several voices live with the customer, is having one pre-published test flow per voice, all using exactly the same set of phrases.

That has worked well for me during ramp-up and customer validation sessions.