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:
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.
------------------------------
Raphael Poliesi
------------------------------