Welcome Community

Calling all inventors, Dr. Frankensteins, and Edisons! 

It's the most fun time of the year in the Genesys Community. Why? Because we open the doors to the innovation vault and let your genius shine with the Big, Bad Bot Bash! 

To add to our collection of innovation marvels, we want to ask you: 

Have you conjured up a bot, automation, or performance enhancing feature using Genesys software?

Tell us about it in the comments below! And you could end up a big winner!

What Makes a Spine-Tingling Entry?

Include details like:

-What problem does your creation solve?

-What inspired you to make it?

-How does it work?

-Share screenshots, stories, testimonials, whatever you need to sell it! We want to know all the ins and outs of your invention.

Deadline for Submissions:

You'll have the full month of October to submit your creations, so put some thought into it. Once the contest closes October 31^st, we'll send all entries to our panel of judges to decide a winner.

Scary-Good Prizes: 

Everyone who submits their innovation will receive:

• 25 Advocacy Points
• The Big, Bad Bot Bash Badge (say that three times fast...)

The winner will get the badge above, plus:

• A Prize Wall pick and
• 100 Advocacy Points
• A Dr. Don Brown ribbon

Head over to the Big, Bad Bot Bash to learn more about other community contests happening in October!

 

------------------------------
Nicole Milliken
Senior Online Community Video Specialist
------------------------------

Hi everyone!

Here's my entry for the Genesys Showcase contest.

I created a BOT TASK called Dynamic Menu, designed to make menu creation in Architect faster, reusable, and fully dynamic.

What problem does it solve?
In complex bot designs, developers often need to create multiple static menus for different contexts, which increases maintenance effort and limits flexibility. My goal was to simplify this process and make menu creation reusable and adaptable - allowing both structured options and open data collection when needed.

What inspired you to make it?
During several bot implementations, I noticed that most menus followed the same logic but required manual duplication and customization. I wanted a smarter, cleaner way to handle menus - one that adapts automatically based on variables, can collect free-form user input (like a document number or code), and integrates seamlessly with Genesys Knowledge for open queries.

How does it work?
I created a generic reusable task in Architect called Digital Menu.

• The menu text ({{Flow.textoMenu}}) and options (Flow.opt1 to Flow.opt10) are dynamically passed as variables.

• The same task can generate from 1 to 10 quick reply options without hardcoding them.

• It also supports generic data collection - the developer can specify, just like other options, that the desired type is "input". In this mode, the bot switches behavior and asks the user to type information such as a document number, code, or other value.

• The developer only needs to set the variable values before invoking the task - the menu automatically adjusts to the use case.

• The task handles the user's response and returns the selected or typed value to the main flow for further logic.

This framework was designed for traditional menu-based bots that don't rely on intent recognition.
This approach remains very common in Brazil, where many organizations prefer structured, predictable flows similar to IVR-style menus. It offers better control, simpler maintenance, and clear user navigation - especially in environments with large customer bases or mixed digital channels.

This solution allows any bot to reuse the same logic for both menus and open data collection, improving flexibility, consistency, and maintainability. It also supports multilingual flows and dynamic data sources (such as Data Actions).

Results:

• 80% faster menu creation.

• No duplicated flow logic.

• Supports both guided and open input interactions.

• Works perfectly for traditional bots without intents.

• Commonly adopted by Brazilian organizations for scalable, reliable CX automation.

• Easier maintenance and updates.

Thanks for checking out my bot! Hope this idea helps others build faster and smarter with Genesys Cloud.

------------------------------
Luiz Rosa
Full stack developer
------------------------------

Wow, @Luiz Rosa - this is seriously impressive! Thanks for your entry!

------------------------------
Nicole Milliken
Senior Online Community Video Specialist
------------------------------

Original Message:
Sent: 10-10-2025 19:09
From: Luiz Rosa
Subject: The Big, Bad Bot Bash is BACK!!!

Hi everyone!

Here's my entry for the Genesys Showcase contest.

I created a bot component called Dynamic Menu, designed to make menu creation in Architect faster, reusable, and fully dynamic.

What problem does it solve?
In complex bot designs, developers often need to create multiple static menus for different contexts, which increases maintenance effort and limits flexibility. My goal was to simplify this process and make menu creation reusable and adaptable - allowing both structured options and open data collection when needed.

What inspired you to make it?
During several bot implementations, I noticed that most menus followed the same logic but required manual duplication and customization. I wanted a smarter, cleaner way to handle menus - one that adapts automatically based on variables, can collect free-form user input (like a document number or code), and integrates seamlessly with Genesys Knowledge for open queries.

How does it work?
I created a generic reusable task in Architect called Digital Menu.

• The menu text ({{Flow.textoMenu}}) and options (Flow.opt1 to Flow.opt10) are dynamically passed as variables.

• The same task can generate from 1 to 10 quick reply options without hardcoding them.

• It also supports generic data collection - the developer can specify, just like other options, that the desired type is "input". In this mode, the bot switches behavior and asks the user to type information such as a document number, code, or other value.

• The developer only needs to set the variable values before invoking the task - the menu automatically adjusts to the use case.

• The task handles the user's response and returns the selected or typed value to the main flow for further logic.

This framework was designed for traditional menu-based bots that don't rely on intent recognition.
This approach remains very common in Brazil, where many organizations prefer structured, predictable flows similar to IVR-style menus. It offers better control, simpler maintenance, and clear user navigation - especially in environments with large customer bases or mixed digital channels.

This solution allows any bot to reuse the same logic for both menus and open data collection, improving flexibility, consistency, and maintainability. It also supports multilingual flows and dynamic data sources (such as APIs or Data Actions).

Results:

• 80% faster menu creation.

• No duplicated flow logic.

• Supports both guided and open input interactions.

• Works perfectly for traditional bots without intents.

• Commonly adopted by Brazilian organizations for scalable, reliable CX automation.

• Easier maintenance and updates.

Thanks for checking out my bot! Hope this idea helps others build faster and smarter with Genesys Cloud.

------------------------------
Luiz Rosa
Full stack developer
------------------------------

What problem does your creation solve?

My innovation solves the problem of rigidity and repetitive work in customer satisfaction surveys. With a single dynamic flow, it's possible to use the same survey structure across different channels (voice, messaging, chat, and others) without the need to build separate flows or make complex changes for each channel. This approach makes it easier to maintain, run A/B tests, and personalize the customer experience.

💡 What inspired you to make it?

The inspiration came from the need to make surveys more flexible and scalable, reducing the time spent on developing and maintaining multiple flows. I wanted to create a centralized and reusable model that could adapt to any type of media and question format, ensuring agility and consistency in collecting customer feedback.

⚙️ How does it work?

It works through a data table that stores a key (e.g., "Support") and a JSON in the following format:

{
  "id": 1,
  "media": "voice",
  "questions": [
    {
      "id": 1,
      "type": "range",
      "text": "In a scale from 1 to 5"
    },
    {
      "id": 2,
      "type": "range",
      "text": "In a scale from 1 to 10"
    },
    {
      "id": 4,
      "type": "open",
      "text": "Open question"
    }
  ]
}

The survey flow retrieves the key for the specific interaction and receives the JSON data. Based on the media type and question type, it automatically triggers the specific task for that scenario.

This allows me to:

• Add, remove, or modify questions easily

• Reuse the same flow for any channel

• Run A/B tests more efficiently

• Save all responses and question texts in participant data, making it easier to track customer behavior and make quick adjustments.

This feature will receive soon and update to change the data action in a frindly UI design.

------------------------------
Debora Lopes
------------------------------

Whoa! Super cool @Debora Lopes- thanks for submitting!

------------------------------
Nicole Milliken
Senior Online Community Video Specialist
------------------------------

Original Message:
Sent: 10-16-2025 17:28
From: Debora Lopes
Subject: The Big, Bad Bot Bash is BACK!!!

What problem does your creation solve?

My innovation solves the problem of rigidity and repetitive work in customer satisfaction surveys. With a single dynamic flow, it's possible to use the same survey structure across different channels (voice, messaging, chat, and others) without the need to build separate flows or make complex changes for each channel. This approach makes it easier to maintain, run A/B tests, and personalize the customer experience.

💡 What inspired you to make it?

The inspiration came from the need to make surveys more flexible and scalable, reducing the time spent on developing and maintaining multiple flows. I wanted to create a centralized and reusable model that could adapt to any type of media and question format, ensuring agility and consistency in collecting customer feedback.

⚙️ How does it work?

It works through a data table that stores a key (e.g., "Support") and a JSON in the following format:

{
  "id": 1,
  "media": "voice",
  "questions": [
    {
      "id": 1,
      "type": "range",
      "text": "In a scale from 1 to 5"
    },
    {
      "id": 2,
      "type": "range",
      "text": "In a scale from 1 to 10"
    },
    {
      "id": 4,
      "type": "open",
      "text": "Open question"
    }
  ]
}

The survey flow retrieves the key for the specific interaction and receives the JSON data. Based on the media type and question type, it automatically triggers the specific task for that scenario.

This allows me to:

• Add, remove, or modify questions easily

• Reuse the same flow for any channel

• Run A/B tests more efficiently

• Save all responses and question texts in participant data, making it easier to track customer behavior and make quick adjustments.

This feature will receive soon and update to change the data action in a frindly UI design.

------------------------------
Debora Lopes
------------------------------

Very good Débora, it helps the team a lot with day-to-day development.
It's a "pain" for our customers that can easily be overcome by your idea.

Regards.

Lilian Lira
Head of Software Engineering and Services

------------------------------
Lilian Lira
Services and Developer Manager
------------------------------

Original Message:
Sent: 10-16-2025 17:28
From: Debora Lopes
Subject: The Big, Bad Bot Bash is BACK!!!

What problem does your creation solve?

My innovation solves the problem of rigidity and repetitive work in customer satisfaction surveys. With a single dynamic flow, it's possible to use the same survey structure across different channels (voice, messaging, chat, and others) without the need to build separate flows or make complex changes for each channel. This approach makes it easier to maintain, run A/B tests, and personalize the customer experience.

💡 What inspired you to make it?

The inspiration came from the need to make surveys more flexible and scalable, reducing the time spent on developing and maintaining multiple flows. I wanted to create a centralized and reusable model that could adapt to any type of media and question format, ensuring agility and consistency in collecting customer feedback.

⚙️ How does it work?

It works through a data table that stores a key (e.g., "Support") and a JSON in the following format:

{
  "id": 1,
  "media": "voice",
  "questions": [
    {
      "id": 1,
      "type": "range",
      "text": "In a scale from 1 to 5"
    },
    {
      "id": 2,
      "type": "range",
      "text": "In a scale from 1 to 10"
    },
    {
      "id": 4,
      "type": "open",
      "text": "Open question"
    }
  ]
}

The survey flow retrieves the key for the specific interaction and receives the JSON data. Based on the media type and question type, it automatically triggers the specific task for that scenario.

This allows me to:

• Add, remove, or modify questions easily

• Reuse the same flow for any channel

• Run A/B tests more efficiently

• Save all responses and question texts in participant data, making it easier to track customer behavior and make quick adjustments.

This feature will receive soon and update to change the data action in a frindly UI design.

------------------------------
Debora Lopes
------------------------------

After seeing an Agentic AI ad by Google, I thought to myself, I could do that.  Essentially, a lady calls her Google Agent and ask it to book a dinner appointment and the bot calls out to do that and gives her an SMS confirmation.  While the ad was totally scripted and not at all realistic with the technology at the time, I wondered if a Guide could do this.  No an hour or two later, it worked!!

I needed two Guides, three data actions, and an outbound campaign.  

1. Guide answers SMS/Messaging/Call and takes the information for where to eat and city as well as information like number in the party, time, variance of time allowed, and name.
2. Guide calls a Google Places API to get the restaurant phone number based on name and city and/or State
3. Guide calls Genesys API to insert contact into a contact list
4. Guide tells caller they will make the appointment and hangs up
5. Agentless campaign (always running) calls out to restaurant 
6. Outbound flow calls Guide
7. Guide negotiates the reservation 
8. Either success or failure, Guide sends SMS to original caller
9. Guide thanks the restaurant and hangs up.

Here is the original video:  https://youtu.be/-qCanuYrR0g. I'll work on a video of mine.

------------------------------
Robert Wakefield-Carl
ttec Digital
Sr. Director - Innovation Architects
Robert.WC@ttecdigital.com
https://www.ttecDigital.com
https://RobertWC.Blogspot.com
------------------------------

The Holiday-Smart Callback Scheduler

Problem

Users who were locked out of their accounts, due to forgotten passwords, MFA failures. They had no way to request help once the Service Desk closed at 6 pm AEST/AEDT.

• IT support operates only Monday – Friday, 8 am – 6 pm (Melbourne time).
• Staff and students overseas were left waiting through the night or weekend.
• No automatic way existed to queue a callback for the next business day.
  
  

Solution

I built a Genesys chatbot-driven callback scheduler that lets users securely lodge a request at any hour even at 2 am on a Sunday.
The bot determines the next open business day, skips weekends and public holidays, and schedules an outbound callback in the correct one-hour slot (9am-5pm Melbourne time).

How it works

• Melbourne-aware scheduling: The bot computes the target business day and slot in local Melbourne time and then converts to UTC using the correct AEST ↔ AEDT offset based on the target date.
• Weekend + holiday loop: A lightweight loop checks the date against weekends and a Public Holiday Data Table (YYYY-MM-DD keys). It advances until it finds the first open day, guaranteeing callbacks always land on valid business days.
• Capacity and duplicate control: Before confirming a callback, the bot queries Genesys Analytics to:
1. Count callbacks already scheduled for that target business day and queue.
2. Prevent duplicate callbacks for the same phone number and date - ensuring fair load distribution and avoiding repeat bookings.
• Self-adjusting for DST: Because offsets are calculated from the target day rather than "now," transitions between AEST and AEDT are handled automatically no code change required.
• Data-table driven: Public holidays are maintained externally; month and year transitions work naturally with date math.
  
  

Results

• Around 45 callback requests per month are now auto-scheduled.
• Users save 12 – 48 hours of waiting per request, more than 90 hours of total wait time saved each month.
• Zero missed callbacks across DST changes, weekends, and holidays.
  
  

Impact

This bot closes the service-availability gap between "after hours" and "next business day," ensuring no user ever gets stranded outside support hours even on long weekends or during daylight-saving changeovers.

Example (11:00–12:00)
Build the Melbourne-local timestamp, then subtract the correct offset (11h in AEDT, 10h in AEST) to store the callback in UTC:

Note: We use Minute(Flow.LocalDateTime) when building the Melbourne-local timestamp so callbacks don't all land exactly at 11:00 each request keeps the user's current minute (e.g., 11:23), which distributes calls across the hour.

AddHours(

  MakeDateTime(

    Year(Flow.TargetBizDate11),

    Month(Flow.TargetBizDate11),

    Day(Flow.TargetBizDate11),

    11,

    Minute(Flow.LocalDateTime),

    0

  ),

  -If(

     MakeDateTime(Year(Flow.TargetBizDate11),Month(Flow.TargetBizDate11),Day(Flow.TargetBizDate11),0,0,0)

       < GetDayOfWeekOccurrence(1,1,Year(Flow.TargetBizDate11),4,3,0,0)

     Or

     MakeDateTime(Year(Flow.TargetBizDate11),Month(Flow.TargetBizDate11),Day(Flow.TargetBizDate11),0,0,0)

       >= GetDayOfWeekOccurrence(1,1,Year(Flow.TargetBizDate11),10,2,0,0),

     11,  

     10  

   )

)

Huge thanks to everyone in this community for the wealth of knowledge and support you share!

    

------------------------------
Phaneendra
Technical Solutions Consultant
Monash University
Australia
------------------------------

This is an awesome bot, am passing the idea to our service desk team. 

------------------------------
Jake Hofer
Network Voice Engineer Associate
------------------------------

Original Message:
Sent: 10-19-2025 21:35
From: Phaneendra Avatapalli
Subject: The Big, Bad Bot Bash is BACK!!!

The Holiday-Smart Callback Scheduler

Problem

Users who were locked out of their accounts, due to forgotten passwords, MFA failures. They had no way to request help once the Service Desk closed at 6 pm AEST/AEDT.

• IT support operates only Monday – Friday, 8 am – 6 pm (Melbourne time).
• Staff and students overseas were left waiting through the night or weekend.
• No automatic way existed to queue a callback for the next business day.
  
  

Solution

I built a Genesys chatbot-driven callback scheduler that lets users securely lodge a request at any hour even at 2 am on a Sunday.
The bot determines the next open business day, skips weekends and public holidays, and schedules an outbound callback in the correct one-hour slot (9am-5pm Melbourne time).

How it works

• Melbourne-aware scheduling: The bot computes the target business day and slot in local Melbourne time and then converts to UTC using the correct AEST ↔ AEDT offset based on the target date.
• Weekend + holiday loop: A lightweight loop checks the date against weekends and a Public Holiday Data Table (YYYY-MM-DD keys). It advances until it finds the first open day, guaranteeing callbacks always land on valid business days.
• Capacity and duplicate control: Before confirming a callback, the bot queries Genesys Analytics to:
1. Count callbacks already scheduled for that target business day and queue.
2. Prevent duplicate callbacks for the same phone number and date - ensuring fair load distribution and avoiding repeat bookings.
• Self-adjusting for DST: Because offsets are calculated from the target day rather than "now," transitions between AEST and AEDT are handled automatically no code change required.
• Data-table driven: Public holidays are maintained externally; month and year transitions work naturally with date math.
  
  

Results

• Around 45 callback requests per month are now auto-scheduled.
• Users save 12 – 48 hours of waiting per request, more than 90 hours of total wait time saved each month.
• Zero missed callbacks across DST changes, weekends, and holidays.
  
  

Impact

This bot closes the service-availability gap between "after hours" and "next business day," ensuring no user ever gets stranded outside support hours even on long weekends or during daylight-saving changeovers.

Example (11:00–12:00)
Build the Melbourne-local timestamp, then subtract the correct offset (11h in AEDT, 10h in AEST) to store the callback in UTC:

Note: We use Minute(Flow.LocalDateTime) when building the Melbourne-local timestamp so callbacks don't all land exactly at 11:00 each request keeps the user's current minute (e.g., 11:23), which distributes calls across the hour.

AddHours(

  MakeDateTime(

    Year(Flow.TargetBizDate11),

    Month(Flow.TargetBizDate11),

    Day(Flow.TargetBizDate11),

    11,

    Minute(Flow.LocalDateTime),

    0

  ),

  -If(

     MakeDateTime(Year(Flow.TargetBizDate11),Month(Flow.TargetBizDate11),Day(Flow.TargetBizDate11),0,0,0)

       < GetDayOfWeekOccurrence(1,1,Year(Flow.TargetBizDate11),4,3,0,0)

     Or

     MakeDateTime(Year(Flow.TargetBizDate11),Month(Flow.TargetBizDate11),Day(Flow.TargetBizDate11),0,0,0)

       >= GetDayOfWeekOccurrence(1,1,Year(Flow.TargetBizDate11),10,2,0,0),

     11,  

     10  

   )

)

Huge thanks to everyone in this community for the wealth of knowledge and support you share!

    

------------------------------
Phaneendra
Technical Solutions Consultant
Monash University
Australia
------------------------------

Thank you Jake. Please reach out if you need anything. We're using this today in our digital bot, and we can apply the same approach in voice as well.

------------------------------
Phaneendra
Technical Solutions Consultant
Monash University
Australia
------------------------------

Original Message:
Sent: 10-28-2025 13:01
From: Jake Hofer
Subject: The Big, Bad Bot Bash is BACK!!!

This is an awesome bot, am passing the idea to our service desk team. 

------------------------------
Jake Hofer
Network Voice Engineer Associate
------------------------------


Original Message:
Sent: 10-19-2025 21:35
From: Phaneendra Avatapalli
Subject: The Big, Bad Bot Bash is BACK!!!

The Holiday-Smart Callback Scheduler

Problem

Users who were locked out of their accounts, due to forgotten passwords, MFA failures. They had no way to request help once the Service Desk closed at 6 pm AEST/AEDT.

• IT support operates only Monday – Friday, 8 am – 6 pm (Melbourne time).
• Staff and students overseas were left waiting through the night or weekend.
• No automatic way existed to queue a callback for the next business day.
  
  

Solution

I built a Genesys chatbot-driven callback scheduler that lets users securely lodge a request at any hour even at 2 am on a Sunday.
The bot determines the next open business day, skips weekends and public holidays, and schedules an outbound callback in the correct one-hour slot (9am-5pm Melbourne time).

How it works

• Melbourne-aware scheduling: The bot computes the target business day and slot in local Melbourne time and then converts to UTC using the correct AEST ↔ AEDT offset based on the target date.
• Weekend + holiday loop: A lightweight loop checks the date against weekends and a Public Holiday Data Table (YYYY-MM-DD keys). It advances until it finds the first open day, guaranteeing callbacks always land on valid business days.
• Capacity and duplicate control: Before confirming a callback, the bot queries Genesys Analytics to:
1. Count callbacks already scheduled for that target business day and queue.
2. Prevent duplicate callbacks for the same phone number and date - ensuring fair load distribution and avoiding repeat bookings.
• Self-adjusting for DST: Because offsets are calculated from the target day rather than "now," transitions between AEST and AEDT are handled automatically no code change required.
• Data-table driven: Public holidays are maintained externally; month and year transitions work naturally with date math.
  
  

Results

• Around 45 callback requests per month are now auto-scheduled.
• Users save 12 – 48 hours of waiting per request, more than 90 hours of total wait time saved each month.
• Zero missed callbacks across DST changes, weekends, and holidays.
  
  

Impact

This bot closes the service-availability gap between "after hours" and "next business day," ensuring no user ever gets stranded outside support hours even on long weekends or during daylight-saving changeovers.

Example (11:00–12:00)
Build the Melbourne-local timestamp, then subtract the correct offset (11h in AEDT, 10h in AEST) to store the callback in UTC:

Note: We use Minute(Flow.LocalDateTime) when building the Melbourne-local timestamp so callbacks don't all land exactly at 11:00 each request keeps the user's current minute (e.g., 11:23), which distributes calls across the hour.

AddHours(

  MakeDateTime(

    Year(Flow.TargetBizDate11),

    Month(Flow.TargetBizDate11),

    Day(Flow.TargetBizDate11),

    11,

    Minute(Flow.LocalDateTime),

    0

  ),

  -If(

     MakeDateTime(Year(Flow.TargetBizDate11),Month(Flow.TargetBizDate11),Day(Flow.TargetBizDate11),0,0,0)

       < GetDayOfWeekOccurrence(1,1,Year(Flow.TargetBizDate11),4,3,0,0)

     Or

     MakeDateTime(Year(Flow.TargetBizDate11),Month(Flow.TargetBizDate11),Day(Flow.TargetBizDate11),0,0,0)

       >= GetDayOfWeekOccurrence(1,1,Year(Flow.TargetBizDate11),10,2,0,0),

     11,  

     10  

   )

)

Huge thanks to everyone in this community for the wealth of knowledge and support you share!

    

------------------------------
Phaneendra
Technical Solutions Consultant
Monash University
Australia

I have two projects I'd like to enter if that is okay. One that is completed, and used by the community. Another that is almost finished and demonstrates how Genesys Cloud can be integrated with other Agentic platforms, in this case Google's latest video based AI.

Website to test Web Messenger chatbots

In progress: Video AI Assistant in Digital Chatbot journey

This is a project I have almost finished, and will be subject to a newsletter article breaking down how it all works so others can recreate it. In it I want to show how each Genesys Cloud makes it to create CX journeys that utilise the latest in third-party Agentic technologies. In this case Google's Agent Development Kit coupled with its video based AI.

This is the high-level journey I created, that I shared on LinkedIn:

------------------------------
Lucas Woodward
Winner of Orchestrator of the Year, Developer (2025)

LinkedIn - https://www.linkedin.com/in/lucas-woodward-the-dev
Newsletter - https://makingchatbots.com
------------------------------

Hi everyone!

I'd like to share a simple yet impactful innovation built using Genesys Cloud: A Post-Interaction Feedback Bot that automatically collects feedback and opens a Salesforce Case whenever a customer reports a bad experience.

Email surveys were not giving us enough response volume, and by the time we got bad feedback, it was often too late to recover the customer. We needed real-time action.

How it works

1. Customer finishes a call or chat
2. A Digital Messaging bot (WhatsApp/Web Messaging) sends a short, conversational survey 
3. Customer responds with a satisfaction score (1–5)
4. Genesys Cloud evaluates the score
5. If 3 or below, a Data Action triggers the Salesforce API to:
- Create a Case automatically
- Include customer info and survey score
- Tag it as "Customer Recovery Required"

Results

- Much higher survey completion rate

- Real-time capture of negative feedback

- Immediate recovery efforts = more happy customers

- Better collaboration between the CX team and CRM operations

------------------------------
Gabriel Garcia
NA
------------------------------

Hello everyone!

What problem does your creation solve?

We created a bot that allows each of our customers to update their inbound and in-queue flow "front end" and "promo" prompts using TTS. 

What inspired you to make it?

Continuity of our customers' experience inspired this bot.
In PureConnect our customers were able to update Attendant audio prompts through the TUI admin options. This feature was used heavily throughout our customer base.
In Genesys Cloud CX prompts can be updated by users, but they are not division aware.
We have a single Org containing numerous customers, so we needed a way to restrict access to prompts between customers.
So, this bot was created to allow each customer access to only their prompts and the ability to update/silence those prompts using TTS.

How does it work?

The bot is deployed as a Client App.
It works by identifying/authorizing the user via group membership, and if permitted, allows access to silence or change the verbiage of certain prompts the customer has in their flows.

Share screenshots, stories, testimonials, whatever you need to sell it! We want to know all the ins and outs of your invention.

We originally used 'Find User Prompt' steps, but switched to using datatables for updating the prompts due to the way audio is buffered.
Using a datatable gets around this and allows for real-time updates to in-queue prompts so that callers circling in queue can hear new updates in real-time. Datatables are also division aware, which is a plus.
There's a datatable for each customer, each containing prompt names as the reference key and a field for the TTS string of each prompt.

Below is an image of the client app launch page.
I've refrained from posting Architect and datatable snippets since we commonly use customer names in these areas to help guide us along. But I'd be happy to answer any questions about the bot.

------------------------------
R. Brandon Weaver
CX Solutions Specialist | SAIC
------------------------------