Hi! 

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. 

Many thanks,

Alison

Hi Alison,

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?

 Hi! 

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. 

Many thanks,

Alison

Hi Jan,

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!

Alison

Hi Alison,

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?

 Hi! 

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. 

Many thanks,

Alison

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.

Hi Jan,

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!

Alison

Hi Alison,

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?

 Hi! 

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. 

Many thanks,

Alison

Hi Jan,

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!

Dale.

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.

Hi Jan,

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!

Alison

Hi Alison,

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?

 Hi! 

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. 

Many thanks,

Alison

Hi Jan,

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!

Dale.

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.

Hi Jan,

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!

Alison

Hi Alison,

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?

 Hi! 

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. 

Many thanks,

Alison

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.

Hi Jan,

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!

Dale.

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.

Hi Jan,

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!

Alison

Hi Alison,

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?

 Hi! 

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. 

Many thanks,

Alison

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.

Hi Jan,

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!

Dale.

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.

Hi Jan,

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!

Alison

Hi Alison,

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?

 Hi! 

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. 

Many thanks,

Alison

Hi Anton,

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?

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.

Hi Jan,

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!

Dale.

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.

Hi Jan,

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!

Alison

Hi Alison,

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?

 Hi! 

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. 

Many thanks,

Alison

Hi Dale,

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. 

Hi Anton,

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?

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.

Hi Jan,

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!

Dale.

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.

Hi Jan,

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!

Alison

Hi Alison,

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?

 Hi! 

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. 

Many thanks,

Alison

Hi Anton

would it be possible to share the snapshot of this in queue email flow if its done.. i am having some challenge in visualizing  the logic outlined above  ?

Regards

Halesha sn

Hi Dale,

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. 

Hi Anton,

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?

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.

Hi Jan,

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!

Dale.

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.

Hi Jan,

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!

Alison

Hi Alison,

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?

 Hi! 

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. 

Many thanks,

Alison