A place to ask questions, connect with others, and stay in the know
Hoping someone can help? We currently use looping in emails however because we don't have anyone working through out the weekend the loops run out and disconnect before someone is able to be assigned the email by Monday morning. The wait time is currently set to 30 mins, and we attempted to up this to 35 minutes but this causes issues when agents need to start working on these as soon as possible on a Monday morning. The main issue is that there is a limit of 99 loops. We ideally need more loops in order to reduce the wait time significantly as we are getting kick back from users on how difficult the system is to use compared to a google group mailbox (which they would just deal with as soon as they log in in the morning.
You could add another loop that you put your current loop inside to get 99x99 loops, but I wonder what is the reason you need this loop in the first place?
How does the current loop reduce wait time?
Thanks for your response! We were told that inserting a loop within a loop wasn't an option unfortunately. If you could put a loop within a loop we could reduce the wait time for an email to enter a queue and route to an agent much quicker in the morning. Because of KPIs for the business we cannot have emails routing to queues during out of office hours as it skews the stats when we are reporting on how long it takes to deal with an email for the entire customer journey. Presently because the loop is et to 30 minutes if a customer sends an email at 17.30 on a Friday it times out by Sunday afternoon and disconnects. Increasing the loop time to 35 mins will get it to Monday morning when an agent logs on but there can still be the delay of up to 34 minutes depending on when they logged in vs when the next loop is. does that make sense? We are getting a lot of criticism from the business on this. Could you advise how to create a loop within a loop? thanks again for your help!
Okey so you're keeping the inbound e-mail flow running by adding a loop in it, and only releasing the e-mail during office hours?
Honestly I would rather send them to queue, and deal with the statistics.I don't know if there's a limit on how long an inbound e-mail flow can run.
If you really wanna keep them in flow I would do a calculation on when the queue opens again and use a wait action for the exact time,although the wait action can max be 72h.
You could also do something with the schedule group, for example first check if it will be open in 12h, if not then it can wait 12h before doing the next loop and next if it's open within 12h check for something smaller and so on. That would release your e-mail when the queue opens.
Thank you again! Would it be easy enough to do something with a schedule group? I have tried to find a guide of how to do something like this.
I had a thought of introducing an additional schedule within the "closed" hours to make the emails wait the duration of the weekend if it was a Friday.
i.e - Friday @ 5pm, emails hit a 62 hour wait and then route to ACD which should take us to say 6am, but I was thinking there must be a better way!
First of all it would be good if Genesys could give an input if it's a good idea to have a flow running like this, since during a holiday it could be running for several days.
You can use a schedule group to test at a specific time, not just the current.
What I'm thinking that you would first check if it's open, if it's closed then you'll check if it's open in for example 12 hours by on the Schedule Group action selecting Specific instead of Current and using something like AddMinutes(GetCurrentDateTimeUtc(), Flow.minToAdd) where minToAdd initially is set to 12 hours.
If the queue is open 12h in the future you could just divide the variable and check again, and so on.
If it's closed Wait for Flow.minToAdd
In theory this could be done within one loop, this is something I threw together that should work but I haven't tested it :)
Well first, by just putting it in queue over the weekend more accurately reflects the customer journey, how long the customer actually waits for a response the customer doesn't care if the business is capable of offering that response or not in that timeframe. Not counting that weekend wait time serves the business and their metrics / kpis not the customer.
But another way to do this, would be to just put it in a dummy queue that isn't manned or measures over the weekend, and then once it is Monday, have it transfer to the right queue.
In Q flows are infinite loops as is. And a simple wait 1 hour before checking the hours should be enough to ensure the emails start arriving again Monday morning.
E-mail queue flows have a bit of an undocumented "issue" in that they only run for 72 hours, unless something has changed since I tested this a bit over a year ago.After that they will just stay in queue but don't process the queue flow.
I encountered it when a customer wanted to have an overflow on e-mail after 5 days in queue and the overflow never happened.
Another funny "feature" with e-mail queue flows is that it will start by running the Recurring State once every minute.After 5 runs it adds 5 seconds so it will now run every 1m 5s.
After a while it will start adding time after 3 runs, 2 run and finally 1 run so the longer the e-mail stays in queue, the longer between the time it runs the queue flow and after 72 hours it just stops processing it.
I don't remember what the final delay between runs was, but if I recall correctly it also adds more time for each run in the later stages.
I'm guessing Message queue flows behave in a similar way since they also work with states, but I'll need to test exactly how they behave at some point.
Thank you for your reply!
I was thinking of using a dummy queue, but not really sure how to achieve this to transfer to the correct queue at the right times? Is this simple enough to do?
So, depends how accurate you want it.
It is easy enough to just have a schedule check and if it is Monday 7am (or whatever your start time is) then transfer to acd, if not then continue the flow (wait and loop), and as emails go through the loop they will start getting transferred to the open queue, but this won't be all at once.
If you need it to be more in bulk.. now I haven't done this myself, but what I would probably try to do is, as above, but check if it is 1 hour before start, if it is start a new loop that waits 5 minutes and checks if it is 10 minutes before start, if it is start a new loop that waits 1 minutes and check if it is opening time and if it is transfer to acd. That way the emails will essentially all end up in a 1 minute wait loop checking if it is open, and when it is send it all over, but if it is still too far out from opening its not going to chew through your action limit.
Otherwise you could probably create a simple app with the SDKs, to grab all the conversation ID's in the dummy Queue, and scheduled to run to at opening time to do the transfers.
Check out the Genesys Knowledge Network - your all-in-one access point for Genesys resources
Every year, Genesys® orchestrates more than 70 billion remarkable customer experiences for organizations in more than 100 countries. Through the power of our cloud, digital and AI technologies, organizations can realize Experience as a Service℠, our vision for empathetic customer experiences at scale. With Genesys, organizations have the power to deliver proactive, predictive, and hyper personalized experiences to deepen their customer connection across every marketing, sales, and service moment on any channel, while also improving employee productivity and engagement. By transforming back-office technology to a modern revenue velocity engine Genesys enables true intimacy at scale to foster customer trust and loyalty.