You've waited an entire year...and it's back from the dead! The third annual Bot Bash is here to showcase YOUR scary inventions with Genesys! 

This year, we want to hear about something that wasn't working, and how you brought it back to life.

Every great creation starts with a problem. What was broken and what happened when you flipped the switch using Genesys AI products? 

TELL US:

THE GROTESQUE: What needed a few stitches?
Maybe a flow had become a monster to maintain, agents were buried in manual work, or customers were scary frustrated with a bot.

THE EXPERIMENT: What did you change?
Show us how you used Genesys AI products to rethink, rebuild, or improve the problem. We want those detailed items from your laboratory notebook.

IT'S ALIVE: What happened next?
Tell us what changed. What works better now? What did you learn? And what would you tell another mad scientist attempting the same experiment?

Screen shots are encouraged! (Make sure private info is removed).

We will have a panel of judges read the submissions to choose a winner! You have the whole month of October (October 1st - 31st) to get your entry in. For more information about the Bot Bash, please go to the landing page here (which explains rules, prizes, and has additional info). 

THE LAB IS OPEN! Let the Bot Bash Begin...

#CommunityAnnouncements

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

My support team found ourselves buried in a shallow grave of manual work.  Managing users across 14 different orgs surfaced constant screams of "what is my login URL?", shrieks of "It won't accept my password" and midnight howls of "I can't get logged in" that caused us to have to search for where a user was, and issue them their organization name appended login URL for our region (we're not in the one google results point you to, so count that as an issue, too).

The experiment.  Initially, we built a CLI tool to check the orgs for the user's email address and return the appropriate URL, but this was still a manual process, just less time consuming.  So a teammate had the thought:  what if we rebuilt that into a webservice and made a support bot to field the request.  And that is what we did, with a veritable Frankenstein's monster of AWS services we created a user export ETL job that runs against all of our orgs at a regular cadence to populate a table that a lambda function (thanks integration data actions) points to to retrieve the URL and relevant data for a user via a bot flow.

We're still in an early deployment phase, but we intend to have it in a voicebot flow as well that will email the user their login URL.  This has the added benefit of giving us a prebuilt demo/explainer flow when our customers ask us for technical showcases.

I guess I dropped the spooky there for the last parts.  Uhhh, boo.

Hah! I love you kept with the theme Aaron! LOL

Quality4ME: Bringing Quality Evaluations and Agent Feedback Back to Life

THE GROTESQUE: Scaling quality while keeping agents involved

In one customer operation, Genesys AI Scoring was already supporting quality evaluations, but completing the workflow still required repetitive operational work.

There was also an important business requirement: agents needed to receive their evaluations, review the feedback, and be able to agree with or contest the assessment.

The native fully automated evaluation workflow we assessed did not support that complete agent participation process for our use case. Adopting it would have left an important part of the operation's quality process unsupported.

Between April and June 2026, the operation recorded approximately 496 evaluation finalizations per month. We needed to increase that capacity while preserving the feedback and acknowledgment process.

THE EXPERIMENT: Combining Genesys AI with Quality4ME

At Solve4ME, we developed Quality4ME, a complementary solution that supports quality evaluation workflows alongside Genesys Cloud.

We kept the semi-automated evaluation process in Genesys, using AI Scoring to support the assessment, and used Quality4ME to finalize evaluations.

This approach preserved the operational flow in which agents could receive their evaluations, review the feedback, and agree with or contest the results.

Our work focused on:

• Reducing repetitive operational activities.

• Supporting higher evaluation volumes.

• Preserving agent participation in the quality process.

• Improving visibility into completed evaluations and outstanding work.

We have also submitted enhancement ideas to Genesys requesting support for this agent feedback and acknowledgment/dispute process within the native fully automated experience.

We measured the initiative through actual application usage, recorded finalization volumes, and a separate review of evaluation distribution across agents.

IT'S ALIVE: Greater scale with the feedback process preserved

During July and August 2026, the operation recorded approximately 1,756 finalizations per month, compared with 496 per month in April–June: approximately 3.5 times the monthly volume.

In August alone, 1,762 of 1,784 finalizations were performed through Quality4ME: 98.8% of the month's total.

Evaluation demand and policy settings also changed during this period, so these figures describe observed operational volume and adoption.

The sampling review revealed a further improvement opportunity. Across the queues reviewed in July, evaluation creation reached approximately 62% of the planned volume, while only 28% of active agent-days received at least two evaluations, the daily target used in the analysis.

That finding reinforced the importance of monitoring distribution across agents alongside overall completion volume.

Our biggest lesson was to design automation around the complete quality journey, including the person being evaluated. Receiving feedback, understanding an assessment, and having an opportunity to contest it were essential requirements of this operation.

------------------------------
Thanks!
Ganesh S
------------------------------

One interesting experience we had was using AI to improve understanding and information collection during automated interactions.

For some of our customers, we used AI to identify customer intents and also configured AI-powered slots within the bot flows to help collect and interpret information provided during the conversation.

This allowed us to create more natural interactions while reducing some of the complexity we would have had with a traditional approach based on multiple rules and decisions within the flow.

The results were very productive. One of our main lessons was that AI works best when combined with clear instructions, context, and well-defined boundaries.

Show

Original Message:
Sent: 10-04-2026 22:32
From: Sebastian Valenzuela
Subject: Bot Bash is BACK!

Hi everyone!

Here's my entry for Bot Bash: an AI agent that turns a plain-language description into a published Genesys Architect flow.

 

🧟 The grotesque: what needed fixing?

On every project, demo or pre-sales engagement, I was building the same flows in Architect by hand: IVRs, messaging, email, bots and common modules. They used the same DTMF menus, the same business-hours checks and the same data actions with retries, just rebuilt for each customer. It was slow, and many errors only showed up at publish time: a misspelled queue, a prompt that didn't exist in the org, a variable with the wrong type.

 

So I tried the obvious thing and asked an AI to write the Archy YAML. It looked perfect and didn't publish. The model made up actions, functions and properties that don't exist, or that depend on the org's license.

 

⚗️ The experiment: what did I change?

I set one rule: the AI doesn't write YAML. It writes a small intermediate JSON format, and a compiler (with no AI) turns that into YAML.

 

The org's own Archy schemas (archy refresh) are the source of truth. If an action isn't in the schema, the agent can't use it.

Before compiling, the agent looks up every queue, prompt, data action, data table, skill and AVA in the org. If something is missing, I get a missing-prerequisites report instead of a broken flow.

If my description isn't enough, the agent asks instead of guessing.

If a publish fails, it tries to fix it twice at most, then stops and shows me the exact Archy error.

Everything is exposed as MCP tools, so any AI assistant can design flows with the same rules.

On the Genesys side, I used Agentic Virtual Agents (imported and published through the API), Bot Flows and Digital Bots as bridges, Function Data Actions and Web Messaging for end-to-end testing.

 

⚡ It's alive: what happened next?

100% first-attempt publish rate with no human edits on my regression suite of 11 flow types (voice, in-queue, outbound, SMS, email, workflow, common module, bots, survey).

A multi-industry demo kit published in a sandbox org: 1 common module, 2 bridge bots, voice, messaging and email flows, and 9 AVAs. 15 out of 15 end-to-end conversations passed.

One flow serves 9 industries. To change a queue or an AVA, you edit a row in a data table, not the flow.

Demos that used to take weeks now come together in hours.

Tips for the next mad scientist:

 

Don't let the AI write the final file. Let it write something you can validate, and generate the file with deterministic code.

Track one honest metric (did it publish on the first try?) and roll back anything that makes it worse.

Test end to end. That's how I found that AVA End Context outputs without a mapping arrive empty (I fixed it with an "echo" Function Data Action), and that the digital bot's input has to be passed to the AVA as Start Context.

Wishlist for Genesys: reference an AVA by ID or expression in Architect, a lighter archy validate (a full refresh takes over an hour on a big org), and error messages that tools can act on.

 

Thanks for checking it out! I hope it helps others build faster and safer with Genesys Cloud.

------------------------------
Sebastian
Ingeniero de Proyecto
------------------------------

Submission Title: Frankenstein's IVR: Breathing Life into the Telephony Graveyard

Subtitle: Transforming Brittle Speech-Rec Menus into a Low-Latency, Generative Voice Bot with Intelligent Handoff

Part 1: The Grotesque - What Needed a Few Stitches?

(The Broken, Difficult, Frustrating, and Overly Complicated)

• The Telephony Nightmare: A monolithic Inbound Call Flow with over 60 nested DTMF menus, brittle dual-tone multi-frequency logic, and first-generation Speech Recognition (ASR) that failed whenever callers had accents, background noise, or hesitated.

• The Caller Experience Bottlenecks:

  • The "Barge-In" Despair: Static voice prompts played uninterrupted while callers repeatedly screamed "Representative!", eventually triggering a timeout or a disconnect.

  • Dead-Air Drops: Complex backend SOAP and REST Data Actions were firing sequentially on the telephony trunk. When CRM lookups exceeded 4 seconds, the SIP session experienced silence, causing over 18% of callers to abandon before ever reaching a queue.

  • Cold Transfers & "Start Over" Agent Handoffs: Callers forced through 4 minutes of automated speech menus arrived at an agent with zero context, forcing them to repeat their name, account number, and reason for calling.

Part 2: The Experiment - What Did You Change?

(Rethinking, Rebuilding, and Modernizing with Genesys Cloud Voice AI)

We eliminated the sprawling menu maze by restructuring the architecture into a Voice Bot Flow (Genesys Cloud Virtual Agent / Native Bot) backed by dynamic session management and low-latency speech synthesis:

1. Low-Latency Voice Bot Flow with Streaming ASR & Barge-In

• Replaced static IVR menus with a dynamic Inbound Voice Bot Flow using Genesys native Voice AI and integrated neural Text-to-Speech (TTS).

• Enabled configurable speech recognition sensitivity, complete phrase detection, and real-time barge-in. Callers can speak naturally or interrupt long explanations to narrow their request immediately.

• Implemented Dual-Channel Input: If voice transcription encounters low acoustic confidence (e.g., loud road noise), the bot automatically prompts for DTMF input ("You can also punch in your 6-digit pin on your keypad") without restarting the flow.

2. Asynchronous Data Retrieval & Audio Fillers

• Solved the "dead-air" problem by decoupling external data lookups:

  • Placed lightweight conversational filler prompts ("Give me just a second while I pull up your account...") while executing Architect Call Data Action blocks asynchronously.

  • Set hard timeout thresholds (under 3.0 seconds) with explicit failure branches to keep the telephony session responsive and human.

3. Real-Time Telephony Handoff & Screen Pop Orchestration

• Integrated the Voice Bot with Genesys Agent Copilot / Agent Assist:

  • Extracted entities (CallerName, AccountNumber, IssueCategory, BotConfidenceScore) and wrote them into participant session attributes using Set Participant Data.

  • Packaged the live bot transcription into the interaction context so the destination agent receives a real-time Screen Pop with a pre-summarized voice transcript the instant the call is answered.

Part 3: It's Alive! - What Happened Next?

(Outcomes, Lessons Learned, and Voice Architect Logics)

1. Measurable Business Outcomes

• Voice Self-Service Containment: Rose from 9% to 37% on routine inquiries (balance checks, appointment reschedules, claim status).

• Telephony Dead-Air Abandonment: Dropped from 18% to under 1.5%.

• Escalated Call Handle Time (AHT): Reduced by 54 seconds per call due to automatic agent screen-pop identification and verification (ID&V).

2. Core Voice Architect Logics & Best Practices

When designing production-grade voice bots on Genesys Cloud Architect, implement these foundational rules:

<response-element class="no-md" ng-version="0.0.0-PLACEHOLDER"></response-element>

[Inbound Voice Call]
         │
         ▼
[Initial Identity & Verification] ──(Fails 2x)──► [DTMF Keypad Fallback]
         │ (Success)
         ▼
[Genesys Voice Bot Flow] ◄───(Barge-in Enabled)
    ├── Intent Recognized ──► [Async Data Action + Filler Audio] ──► [Audio Confirmation]
    ├── Knowledge Query   ──► [Knowledge Workbench Deflection]    ──► [Follow-Up Prompt]
    └── Ambiguity / Failure
             │
             ▼
    [Set Participant Data] (Save Transcript, Auth Status, Intent)
             │
             ▼
    [Transfer to ACD] ──► [Agent Desktop: Screen Pop + Copilot Summary]

<response-element class="no-md" ng-version="0.0.0-PLACEHOLDER"></response-element>

• The Voice Latency Budget: Keep round-trip latency (ASR transcription + NLU resolution + TTS playback) strictly under 1.8 seconds. Any delay over 2 seconds feels like a broken call to a phone customer. Use optimized data action payloads and avoid chaining multiple synchronous data actions.

• Smart No-Input / No-Match State Machine:

  • No-Input 1: Short reprompt ("Are you still there? You can say your account number or enter it on your keypad.").

  • No-Input 2: Shift modality (force DTMF collection block).

  • No-Match 2: Route to queue with participant data: TransferReason = "VoiceRecognitionExhausted".

• Zero Lost Context on ACD Transfer: Never use a blind Transfer to ACD block without running Set Participant Data first. Write the bot's extracted attributes into standard Genesys attributes (context.customerName, context.authenticated, context.intentSummary) so Agent Workspace scripts, routing rules, and Copilot have immediate context.

Advice for the Community

"In digital bots, users can tolerate a 3-second delay; in telephony, 3 seconds of silence is a hang-up. Treat audio latency as a critical architecture constraint. Build your voice bots with generous barge-in windows, explicit DTMF fallback safety nets, and seamless participant data handoffs."

Raising Holli from the Dead: How I Rebuilt Our IT Service Desk Chatbot from Scraps

THE GROTESQUE

Before I hauled her into my lab for a complete overhaul, Holli, our IT Service Desk chatbot, was an utter monster.

She had been built as a rigid, clumsy decision tree that forced employees down endless dead-end sub-menus. If someone made a minor typo or phrased a request slightly off, Holli would completely freeze, panic, and drop them into an endless loop. Users were constantly exasperated, typing "HUMAN" in all caps just to bypass her.

I was left dealing with the fallout:

• The Service Desk was drowned in repetitive tickets for basic tasks like checking ticket statuses or logging simple requests.

• Maintenance was an absolute nightmare. Modifying a single option meant trawling through dozens of fragile logic branches in Genesys Cloud, always risking breaking something else in the process.

• Frustrated employees avoided the bot entirely, preferring to flood our phone lines and inbox instead.

Holli was functionally useless, and fixing her was entirely down to me.

THE EXPERIMENT

I decided to scrap the old setup and rebuild Holli from the ground up, focusing on a clean, conversational user experience and deep backend integration.

While I don't currently use AI for response generation, I designed her whole structure in Genesys Cloud to feel conversational, friendly, and easy to chat with. Instead of forcing users through cold, rigid decision trees, Holli gently guides them through their issues step by step.

Here is how I engineered the transformation in my laboratory:

1. ServiceNow Integration & Self-Service

Using Genesys Data Actions, I connected Holli directly into ServiceNow. I built self-service workflows that allow staff to log new incidents and check the status of existing tickets straight inside the chat window without needing a human agent.

2. Custom Agent Screen Pop Script

When a chat does need to reach an agent, context is everything. I designed a visually pleasing, highly structured Screen Pop Script that triggers the moment the chat lands with a Service Desk agent. It immediately presents the agent with vital triage information:

• The user's current physical location and asset tag.

• A brief description of the issue.

• All currently open tickets for that user.

• The last ticket the user viewed in ServiceNow.

3. Expanding Knowledge Base

I linked Holli to an integrated Knowledge Base so she can answer common IT queries instantly. I am continuously expanding and refining this knowledge library, making her more useful with every passing week.

IT'S ALIVE!

The moment I threw the switch on the new Holli, the transformation was staggering.

Holli went from being an annoying obstacle to an essential tool for our whole organisation. Employees actually enjoy using her because the conversational flow feels natural, and self-service adoption has surged now that people can track and log ServiceNow tickets in seconds.

For my colleagues on the Service Desk, the difference has been massive. Thanks to the custom screen pop script, agents no longer have to waste time asking users for their location, asset tag, or ticket history. Everything is neatly laid out on their screen before they even type their first message, cutting handle times dramatically and eliminating daily friction.

Lessons Learned in the Lab:

• Prioritise the agent experience too: Self-service is only half the battle. Building a clear, context-rich screen pop for agents turns escalations into fast, painless interactions.

• A expanding knowledge base pays off: Taking the time to build up and prune your knowledge articles keeps your bot helpful without needing complex web logic.

Advice for Fellow Mad Scientists:

Don't get bogged down trying to build massive, overly complex decision trees. Connect your bot directly into backend tools like ServiceNow, craft a clean screen pop script that your support staff will actually appreciate, and focus on making the interaction feel like a helpful conversation.

------------------------------
Dale Wylie
GCX-GCP
Unified Communications Engineer
------------------------------

Hi team !

🧟 THE GROTESQUE: What needed a few stitches?

We had a new Genesys customer from the insurance industry. In their previous platform, many processes were very manual.

Sales and insurance claims were mixed in the same customer experience. They did not have an easy way to identify the customer's intention or separate the journey based on what the customer really needed.

They also had only one main channel: voice.

Web chat and WhatsApp were something they had not really explored before. In fact, there was some fear about using digital channels because they did not have experience with them in their previous platform.

The result was a very traditional experience, with manual work for agents and limited options for customers.

🧪 THE EXPERIMENT: What did you change?

With Genesys Cloud, we started experimenting together.

Instead of only showing features, we created different real insurance use cases and tested how the customer experience could work in a different way.

We showed how AI could help identify customer intentions and create different experiences for sales, claims, customer service, and other insurance processes.

We experimented with capabilities such as:

• Voicebot for voice self-service.

• Chatbot for digital conversations.

• Virtual Agent to understand customer intentions and provide automated assistance.

• Different journeys depending on what the customer wanted to do.

• New digital experiences using web chat and WhatsApp.

• Better transitions from automation to a human agent when necessary.

The first reaction was WOW!

But there was also some fear.

These capabilities were completely new for them, so the challenge was not only technical. We also needed to help the customer feel comfortable trying a new way of serving their customers.

We started with simple use cases, tested them together, learned from the results, and then created more scenarios.

Our laboratory became a place to break old paradigms and experiment with new customer experiences.

⚡ IT'S ALIVE: What happened next?

After implementing these new capabilities, the customer started to see the value of combining Genesys Cloud and AI.

They were able to reduce customer service times, create better and more personalized journeys, and improve both the customer experience and the employee experience.

But for me, the most interesting result was not only the technology.

We created use cases that the customer had never considered before.

Something that initially generated fear became an opportunity to innovate.

The biggest lesson was that sometimes the most important part of an AI project is not only implementing AI. It is helping the customer experiment, learn, and imagine a different way of doing things.

My recommendation to another "mad scientist" would be simple:

Start with a real customer problem, create a small experiment, demonstrate the experience, and let the results build confidence.

Sometimes you need to break a few paradigms before you can say...

IT'S ALIVE! ⚡🤖

THE GROTESQUE: The customer didn't choose human service, they were pushed toward it by the failure of self-service.

THE EXPERIMENT: AVA for scheduling vehicle part replacements

Previously, customers needing to schedule a part replacement couldn't complete the request by self-service. Without an end-to-end resolution workflow, inquiries were routed to human agents, increasing queue volumes, wait times, and the cost per interaction.

With the implementation of the AVA, scheduling now takes place entirely within the automated channel. The agent identifies the customer and the vehicle, understands the replacement need, presents available details and time slots, and confirms the appointment, all without transferring the customer to a human representative.

This allows us to handle requests by the virtual agent that previously went entirely to human support. Customers can resolve issues in minutes at any time, while the team remains dedicated to cases that truly require human analysis.

IT'S ALIVE:

Self-service resolution: part replacement scheduling is now completed end-to-end by the virtual agent, without transfers.

Retention in the automated channel: requests that previously went entirely to human agents are now handled by the virtual agent.

Lower volume in human queues: fewer transfers mean a reduction in the number of contacts reaching human agents.

Reduced wait times: customers can schedule immediately, without waiting for an available agent.

24/7 availability: scheduling can be done at any time, including outside business hours.

Lower cost per interaction: automated interactions cost less than human-assisted service.

·         Staff focused on tasks requiring analysis: agents can dedicate themselves to more complex cases.

·         Improved customer experience: the process is faster and simpler, requiring less effort to resolve issues.

From Training Nightmare to Intelligent CX Journey

THE GROTESQUE - What needed a few stitches?

During my experience with Genesys Cloud implementations, I noticed a recurring problem: the technology was powerful, but the knowledge around it was fragmented.

Customers had access to complex flows, Architect, WhatsApp, campaigns and multiple operational features, but information was often spread across training sessions, manuals and support interactions.

The result was increased dependency on support for questions that could often be solved by the users themselves.

The problem wasn't the technology. It was the experience around it.

THE EXPERIMENT - What did I change?

I started treating training and knowledge as part of the implementation itself, rather than something delivered at the end.

The approach was redesigned around three principles:

Demonstrate → Practice → Operate

Training became more practical and focused on real operational scenarios, simulations and hands-on activities.

Documentation was simplified and transformed into quick, visual resources that users could actually consult during their daily work.

From there, I started exploring how Genesys AI and conversational experiences could extend this model, allowing users to find information and guidance without depending on support for every question.

The goal was simple:

Use automation and AI to remove repetitive work and make users more independent.

IT'S ALIVE - What changed?

The biggest transformation wasn't simply creating a bot.

It was changing the way we think about Genesys implementations.

Training became part of the customer journey.

Documentation became an operational resource.

And AI became another layer for reducing friction and repetitive interactions.

This experience changed the question I ask when designing a solution:

That became just as important as asking whether the technology works.

The lesson

Don't start with the technology. Start with the problem.

Find what is frustrating the customer, agent or support team - and then use Genesys to bring a better experience to life.

Creating a Digital Brain: Teaching Our Bot to Think Before It Talks

THE GROTESQUE

Our digital support experience had become a maze.

Customers would ask clear questions, but the bot often responded with generic answers, keyword matches, or requests to rephrase. When customers couldn't find what they needed, they escalated to an agent, increasing workload and extending resolution times.

The real monster hiding in the lab wasn't a technology problem. It was a knowledge problem.

Information existed everywhere:

• Knowledge articles
• Internal procedures
• Product documentation
• Frequently asked questions

But none of it was connected in a way the bot could understand naturally.

Customers expected conversational answers. The bot expected precise wording.

Neither side was speaking the same language.

THE EXPERIMENT

Instead of adding more intents, menus, and decision trees, we tried something different.

We introduced Genesys AI Knowledge capabilities and shifted from intent-first design to knowledge-first assistance.

Our experiment included:

• Organizing and improving our knowledge content so AI could use it effectively.
• Replacing static responses with AI-powered knowledge retrieval.
• Training the bot to search for answers based on customer questions rather than forcing customers down predefined paths.
• Monitoring unanswered questions and continuously improving knowledge coverage.
• Using real customer interactions to identify content gaps and optimize responses.
• Establishing governance processes so knowledge quality remained high as content evolved.

Rather than teaching the bot every possible intent, we focused on teaching it where to find the answer.

IT'S ALIVE

The transformation was immediate.

Customers could ask questions in their own words and receive more relevant, conversational responses.

The bot became less dependent on rigid routing logic and more capable of handling variation in customer language.

Our teams spent less time creating and maintaining large intent libraries and more time improving knowledge quality.

Perhaps most importantly, every new piece of knowledge made the experience smarter without requiring a complete redesign of the bot.

The experiment reinforced a lesson many of us learn eventually:

A smarter bot isn't always built by adding more logic. Sometimes it's built by giving it better knowledge.

Advice for Fellow Mad Scientists

1. Don't assume a routing problem is actually a routing problem. It may be a knowledge problem.
2. Invest in knowledge quality before investing in additional bot complexity.
3. Review unanswered questions frequently. Customers will tell you exactly what knowledge is missing.
4. Let AI handle language variation rather than trying to predict every possible phrasing.
5. Treat knowledge as a living product that continuously evolves.

The best bots don't know everything.

They simply know where to look.

Architect Flows growing arms and legs. Effort oozing from their complexity. Documentation hopelessly scratched into ivy-ridden tomb stones.

What if Claude Code could be energised with Architect capabilities; allowing it to create, test, deploy, understand and debug Architect Flows, all with monstrous efficiency.

THE EXPERIMENT started with a sketch

Sat, like Frankenstein conceiving of his monster, I sketched out a plan to create a such a plugin.

Over the next 6 months I built it in public, from the initial sketch to a production ready plugin downloaded by 40+ people a week. During it's development I have shared my progress (and had some fascinating conversations from people across the industry) resulting in over 1500 likes, 110 comments, 60 reposts and 100k impressions.

IT'S ALIVE!

The plugin genesys-cloud-architect was stitched together and allows Claude Code (and soon other Agentic coding platforms) to be able to help Flow Architect's:

Create and test flows

Simply ask it to create a flow, and it crawls through the passageway of complexity for you. Then bolts it securely with tests.

You can even give it a hand-drawing or a diagram of your flow and it will create it as a flow for you:

Understand/Document flows

Command it to document an existing flow:

Or ask it to stitch together an answer about a flow (or the journey between flows) for you:

Debug flows

Have bugs festering between your Actions, or unhinged conditions you can't keep track of. As of last week (post coming soon) you can ask it debug a flow and it will creep through execution data to serve you answers.

---

Like Frankenstein releasing his monster from the straps, this project too is stumbling through the world - hopefully doing more good than Frankenstein's monster! 

The Renewal Lab: Bringing Lapsed Subscriptions Back to Life with an Agentic Virtual Agent

THE GROTESQUE: What needed a few stitches?

A software subscription company relied on a manual outbound campaign to win back customers who hadn't renewed. Agents had to call, remind, negotiate and document every attempt by hand, and along the way they faced unhappy, rude and frustrated customers. It was slow and repetitive, and hard on the people doing it.

THE EXPERIMENT: What did we change?

We built a proof of concept on Genesys Cloud: a voice-only, agentless outbound campaign led by an Agentic Virtual Agent (AVA).

• AVA makes the call and opens the conversation, asking the customer why they haven't renewed.
• It gives a friendly reminder about the pending payment.
• It adapts to the customer. If they mention financial difficulties or aren't sure about renewing, AVA can offer a discount instead of accepting a quick "no".
• No agent needed for the first contact. The campaign works through the contact list on its own.

And the door stays open for people. When a customer needs a human, the agent picks up with Genesys Cloud Copilot acting as a personal assistant:

• a summary of the whole conversation with the voice bot, so the agent starts with full context
• live suggestions as the conversation evolves
• a closing summary and suggested wrap-up codes, so documentation takes seconds instead of minutes

IT'S ALIVE: What happened next?

Full disclosure: this was a proof of concept, not a production deployment yet. But it taught us a lot.

The most surprising result was the human reaction: customers forgot they were talking to a machine. Many talked to AVA as if it were a person, and some even told it how it should behave to sound more like a human agent. That feedback was a gold mine for tuning its tone and behavior.

What we took away:

• An agentic bot can take on the hardest part of the first contact, the repetitive and sometimes tense conversations, so agents focus on the cases that truly need a human.
• The handoff matters as much as the bot. A good summary plus live suggestions turns the agent's first seconds from "who is this and what happened?" into "I know exactly where we are."
• Automatic wrap-up suggestions remove much of the documentation burden.

Advice for another mad scientist: Start with one narrow use case, like renewals, and design the handoff to the human agent from day one. And listen to how customers talk to the bot, because they will tell you how to make it better.

Bonus lesson from the lab: I also use AI tools for troubleshooting, and they helped me find a trunk issue in minutes. But in an intermittent Open Messaging case, with hundreds of MB of event logs, the AI couldn't find the problem. I found it by reading a single interaction log: the recipient field was being truncated in Architect. AI is a great copilot, but it still needs a pilot.

O GROTESCO:
Um dos desafios que encontrei foi trabalhar com um fluxo que tinha várias etapas, regras e integrações, o que tornava a manutenção e a identificação de problemas cada vez mais difíceis. Pequenas mudanças podiam gerar impactos em diferentes pontos da jornada.

 O EXPERIMENTO:
Começamos a revisar o fluxo, entender melhor o comportamento das APIs e organizar as tratativas dentro do Genesys Cloud Architect. Usando Data Actions, validações e uma estrutura mais clara de decisões, conseguimos simplificar a lógica e deixar o fluxo mais fácil de acompanhar e manter.

ESTÁ VIVO:
O resultado foi um fluxo mais organizado, com menos pontos de confusão durante os testes e uma identificação de erros muito mais rápida. Também ficou mais fácil entender o caminho percorrido pelo cliente e encontrar exatamente onde uma integração ou regra estava falhando.

Minha principal lição foi: antes de tentar criar algo ainda mais complexo, vale a pena entender bem o que já existe e descobrir onde podemos simplificar. Às vezes, o monstro não precisa ser destruído - só precisa de uma boa refatoração. 

THE GROTESQUE: What needed a few stitches?

Our B2B corporate portal (Firmenportal) was a classic creation of its time: functional, reliable, but visually and operationally stuck somewhere in the late 1990s.

It contained powerful self-service features and a massive library of FAQs. The problem? Nobody reads FAQs. Instead of navigating through complex menus, users turned to our support team for basic guidance. The portal wasn't technically broken-it was just buried in a crypt of hidden information, and customers were increasingly frustrated trying to find simple answers. We needed a bridge to make self-service effortless, so we set out to build a clean, rule-based clickable FAQ bot.

THE EXPERIMENT: What did you change?

We built our beautiful, structured, button-based flow. We opened the lab doors... and our users immediately ignored all the shiny buttons and started typing freely into the chat box!

That was our breakthrough moment in the laboratory. We quickly adapted our experiment:

1. Connecting NLU: We linked our flows to Genesys NLU to capture intent right from the free-text input.

2. Unleashing the Knowledge Base: Fueled by pure curiosity to test Genesys AI features to their fullest, we hooked the bot directly into a Genesys Knowledge Base.

Instead of maintaining rigid, endless dialog flows, managing and updating content suddenly became infinitely easier. The combination of rule-based options, NLU intent recognition, and Genesys AI-powered Knowledge Base created a hybrid assistant capable of understanding natural language while keeping answers accurate and consistent.

IT'S ALIVE: What happened next?

It's alive! And it's actually helping people help themselves.

• What works better: Customers now get instant, precise answers drawn straight from our knowledge repository without having to dig through 90s-era navigation trees.

• What we learned: Never assume users will follow your neat button paths-build for natural interaction from day one. Connecting the Genesys Knowledge Base turned what could have been a maintenance nightmare into a sleek, manageable setup.

• Advice for fellow mad scientists: Don't be afraid to let your users break your initial prototype! Start with structured flows, but let Genesys AI and Knowledge Management handle the heavy lifting. The combination of NLU and Knowledge Base is the real secret sauce for turning static FAQs into an intuitive, smart assistant.

Next up in the lab: expanding the bot's capabilities even further to handle more complex self-service workflows directly in the chat!

Just want to jump in here to say that you all have submitted some scary good submissions! KEEP BRINGING 'EM ON!!