Hello, @Janine Ankney.
I would approach this as more than just adding language skills. Language skills help with routing, but the Architect flow language controls prompts, TTS, speech recognition, and the customer experience inside the flow.
A good first step is to add the supported languages to the existing flows and decide how the language will be selected. For example, by DNIS, customer profile, IVR menu option, or previous CRM preference. After that, use Set Language early in the flow so prompts and TTS follow the right language.
For prompts, I would decide based on the customer experience and maintenance needs. Some teams prefer recorded prompts for stable and high-impact messages, while others use TTS to make updates easier across multiple languages. A hybrid approach can also work well: keep stable prompts more controlled and use TTS for dynamic or frequently changed messages.
I would also avoid converting the whole environment at once. Start with one language and one line of business, validate the caller journey, routing, agent language skill, reporting, and survey behavior, then expand.
For post-call or post-chat surveys, I would test this separately. Don't assume the same survey flow or form will behave perfectly for all languages without validating the language, prompt text, TTS, and survey behavior.
So my recommendation would be: define the language selection logic first, add supported languages in Architect, localize the prompts, keep language skills for routing, and pilot one language before scaling.
------------------------------
Arthur Pereira Reinoldes
------------------------------