Genesys Casual

Without sharing confidential details, what's the most interesting Genesys implementation project you've participated in?

I always enjoy hearing real-world use cases.

Thank you in advance for your cooperation.

One of the most interesting projects I worked on in Genesys Cloud was building a callback bot with dynamic scheduling, holiday handling, and timezone-aware logic.

What made it especially interesting was designing it so customers could request callbacks from any country while the bot automatically schedules the callback based on the organisation's Australian business hours and working days. I also designed it to handle daylight savings automatically with zero code changes required.

That project gave me a much deeper understanding of Architect, reusable tasks, date/time logic, and Data Actions because there were so many real-world scenarios to account for.

You can read more about the bot here

------------------------------
Phaneendra
Technical Solutions Consultant
------------------------------

It was really simple, but I really like it because it solves a huge problem for the customer.

We built an in-queue flow to send some messages and, if desired, disconnect interactions. We need to plan this to handle situations where customers don't want to stay in the queue and prefer to disconnect from message media. With the send message, the customer gets the possibility to communicate issues or problems for the final user and avoid SLA rupture.

One interesting project I worked on was a large messaging implementation for a bank.

The flow had many self-service options, information menus, validations, routing rules, AI agents, and several API integrations all connected in the same journey. Even after splitting the logic and using integrations to reduce the flow size, we still reached the limit at some points.

Since, at least in that scenario, we did not have something like "Transfer to Flow" available for Message Flows, one of the alternatives was to use Digital Bot Flows and In-Queue Message Flows to separate parts of the logic and keep the solution working.

For me, the interesting part was not only building the journey itself, but finding a way to organize a complex solution with many moving parts in a scalable and maintainable way, without creating a "monster flow". 😄

I built a Post Flow that would review each call and see if they were scheduled as a callback or not. If they weren't, then the Interaction would end, but if they were then the Interaction would continue on and see what day the callback was scheduled for and would then go onto check the time that it was scheduled for. 

The allowed day was governed by data table entries, with the queue name being the key in the data table, so each queue could have their own unique days and times to allow callbacks to be scheduled for. 

The request was that they didn't want the agents to schedule callbacks during the weekends, or out of hours. The flow used a data action to get the callback state and time. If it was scheduled as a callback, then it would check the day it it was scheduled for, then compare that to the allowed days from the data table. If it was scheduled for a day that was not in the list, then it was disconnected. If it was scheduled for a day it was allowed for, then it continued to a time check with the same type of logic. I had to build logic to account for day light savings to stop it from allowing calls out of hours 6 months of the year. To cancel the callback, it used another data action to cancel the callback. If it did cancel the callback, and the customer was using a mobile phone, it would then trigger an SMS common module to send a message to the person advising that the callback was scheduled out of hours.