Genesys Cloud - Main

Hi Team,

We are running a WhatsApp Outbound Campaign that operates daily from 9:00 AM to 6:00 PM. (Created a campaign schedule)

I have the following questions regarding the campaign behavior:

Question 1: Contact Processing on the Next Day

When the campaign starts again at 9:00 AM the next day, will it start processing the contact list from the first record again, or will it skip contacts that have already been processed?

my understanding is that the campaign will skip contacts that have already been processed and continue processing new/eligible contacts. Could you please confirm whether this understanding is correct?

Question 2: Observed Multiple Attempts for the Same Contact

We have a campaign rule configured with the condition and action mentioned below. However, we have observed multiple attempts for the same phone number, even though there are no duplicate phone numbers in the contact list.

Could you please clarify what could be causing these multiple attempts?

Your clarification on the above behavior would be highly appreciated.

Thank you for your support.

Good Day Narasimha

Q1:

According to my understanding, it depends on whether the campaign finished the list:

• Still mid-list at 18:00 → the schedule pauses it, and at 09:00 it resumes from where it left off. This matches your understanding.
• Reached the end of the list before 18:00 → the campaign completes and automatically recycles. At 09:00 it starts again from record 1 and re-attempts every contact still marked contactable.

Worth knowing for a 9-to-6 WhatsApp campaign: Attempt Controls and wrap-up code mapping are voice-only. They do nothing on a digital campaign, so there's no attempt-limit backstop preventing a second pass.

Q2 - the recycle plus the choice of action explains it.

Your rule is a pre-contact rule with action Do Not Send. That only suppresses that single send. It writes nothing to the contact record, so the contact stays contactable and is re-evaluated on every subsequent pass. It suppresses repeats only for as long as Last Result Overall keeps matching OUTBOUND-MESSAGE-SENT exactly. A few things break that match:

• The previous attempt got a different disposition - OUTBOUND-MESSAGE-FAILED, or OUTBOUND-RULE-ERROR-SKIPPED if a rule error occurred.
• A later event overwrote the last result: an inbound reply, a bot flow disconnect, or an agent wrap-up.
• The Media Type = WhatsApp qualifier doesn't match how the result was recorded (a common one if the channel is fronted by Open Messaging rather than native WhatsApp).

Any of those makes the condition false and the contact goes out again on the next recycle.

Fix - make the suppression permanent:

Add a post-contact rule alongside what you have:

• Condition: Last Result Overall is OUTBOUND-MESSAGE-SENT
• Action: Mark Contact Uncontactable (or Mark Contact Address Uncontactable if you only want to burn that one address)

Uncontactable contacts are skipped by every future recycle, so the behaviour survives the daily restart. Keep your existing pre-contact Do Not Send as a second layer. If you want the suppression to apply org-wide rather than just this list, use the post-contact Append to DNC action instead.

Also worth confirming while you're in there: the digital rule set is genuinely attached to the campaign, and where it sits in the evaluation order, rule sets evaluate left to right, so an earlier set can act first.

To confirm the diagnosis: export the contact list and check the per-contact last attempt / last result values, then cross-reference against Performance > Workspace > Interactions with the Delivery Status column. That will show you what disposition each attempt actually received, which should tell you immediately whether the rule condition was ever matching.

Hope this helps.

Regards

Hi @Stephan Taljaard

Thank you for your response. This is really helpful and will assist me in troubleshooting the issue.

For Q1

Stephan: Reached the end of the list before 18:00 → the campaign completes and automatically recycles. At 09:00 it starts again from record 1 and re-attempts every contact still marked contactable.

Narasimha: Based on my further testing, it was observed that if the campaign completes processing the entire contact list before 18:00, and at 09:00 its not starting from first record1 

I have another question:

Q3: For some interactions, I can see the Delivery Status as "delivery-failed" with the error "GeneralError – template name (XXXX_template) is paused."

For these deleviry failed interactions, I have observed multiple reattempts. My question is: If the delivery fails because the WhatsApp template is paused, does Genesys automatically reattempt delivery?

Thank You

Hi Narasimha

Thanks for testing that.  Your result is useful, and it actually connects to your Q3.

Q1 - revised. You may be seeing a recycle that looks like no recycle. Your pre-contact Do Not Send rule silently suppresses every contact whose Last Result Overall is OUTBOUND-MESSAGE-SENT. If the campaign does restart from record 1, it walks the whole list, matches that rule on all the successful contacts, and sends nothing. 

Two ways to tell them apart:

1. Watch the campaign's Dialing Progress / percentage complete after the 09:00 start. If it climbs from 0% again, the list is being reprocessed, the rule is just doing its job.
2. Temporarily disable the pre-contact rule in a test org/list and see whether the second pass re-sends.

If progress genuinely stays at 100% and never resets, then the campaign is sitting in Complete and the schedule's "on" isn't triggering a fresh pass, in which case you'd need a manual recycle, or Always Running mode, to reprocess. Either way the diagnostic above tells you which world you're in.

Q3 - no, Genesys is not retrying these.

Digital campaigns have no retry or recall configuration at all. Attempt Controls and recall settings are voice-only, and there is no equivalent for messaging. So what you're seeing isn't a delivery retry, it's the contact being selected again on a later campaign pass.

And here's why it's specifically the delivery-failed ones repeating: your Do Not Send rule matches on OUTBOUND-MESSAGE-SENT. A contact that failed doesn't carry that result, so the rule doesn't match, so nothing suppresses it, so it goes out again on the next pass. Your successful contacts are protected; your failed contacts are not. That is exactly the pattern you're observing.

Worth checking, though: delivery status is asynchronous. The send can be accepted (wrapped OUTBOUND-MESSAGE-SENT) with the failure arriving later as a delivery report showing delivery-failed. Export the contact list and compare the per-contact last result against the Delivery Status in the Interactions view. If the last result says SENT but delivery says failed, your rule is suppressing contacts that never actually received the message, a different and arguably worse problem.

The template issue is a Meta problem, not a Genesys one. template is paused maps to Meta error 132015 , Meta pauses a template when its quality rating drops based on user feedback (blocks, reports, low engagement). While paused it cannot be sent. Fix it in WhatsApp Manager: review the quality rating, edit the template content, and let it recover. Repeatedly hammering a paused template with campaign passes will keep accruing failures and can escalate it from paused to disabled, which is much harder to come back from.

Suggested rule changes:

• Post-contact: Last Result Overall is OUTBOUND-MESSAGE-SENT → Mark Contact Uncontactable (makes the suppression durable rather than re-evaluated every pass)
• Post-contact: Last Result Overall is OUTBOUND-MESSAGE-FAILED → Update Contact Column to increment a failure/attempt counter, then use a contact list filter to exclude contacts above your threshold

The second one gives you controlled retry logic instead of an open-ended loop, you decide how many failed attempts a contact gets, rather than letting every recycle try again indefinitely.

Hope this helps.

Regards