The Community is hosting an End of Summer sweepstakes! Participants must complete tasks to earn tickets that will enter them with a chance to win a free year of Constant Contact and other great prizes!*
*No Purchase Necessary. For Official Rules, visit here. Constant Contact’s End of Summer 2020 Sweepstakes ends on October, 20, 2020 at 11:50 PM EST.
Good Morning - I recently discovered that we are not receiving confirmations for any registration that is a paid registration for events. When we first set up this events, we did a lot of testing, and this is not an issue. However, when testing today, I discovered that when I register for an event that is free, both myself (as the event venue) and the registrant receive the confirmation email. However, when it is a paid event, neither myself (as the event venue) nor the registrant receive the confirmation email. What is causing this and how do I correct it? Any help is sincerely appreciated. Thank you and all the best, Amanda
... View more
I will outline the use case and then some of the issues we have been having. We sell access to our site for 12 months at a time. When someone makes a purchase we want to: See if they are part of our newsletter list, if not, add them (we have this working) See if they are part of our 12 month auto-responder series If they are not a member, they should be added (we have done this) If they are already in this list, we need to re-set their "added to" date for the auto-responder series to today’s date. It would be even better if we could force the added-to date to be something other than today’s date. This is because in some situations people are renewing before their expiration - meaning that they could make a purchase on June 1st 2016 even though the current membership does not expire until July 1st 2016. This means that their new purchase would not run out for 13 months since it starts the “new clock” on July 1st 2016. Once they are added to the auto-responder list, we want to send emails at certain intervals as they approach their expiration date (ex: 3 months prior, 2 months prior, 1 months prior, 2 weeks prior etc.). We understand that this would be calculated from their “added" date since we are telling the system to send the email x number of days after being added. So, if the expiration is always 12 months from the add date, 3 months to expiration would be 12-3, or 9 months after being added. For testing we created an autoresponder series. There are 7 emails that are queued to send one day after another. We are able to add people to the list without issue. They do start receiving the series one day after being added. The issues start when we remove someone from the auto-responder list and then re-add them. The results of removing and re-adding cause many issues including: Some test emails continued to get emails on the original schedule Some test emails received 2 emails on the same day (some for “day 2" and another for "day 6”) Some test emails stayed on the original schedule, but received "day 1” again after the auto-responder series ran its original course of 7 days What is the correct way to re-set someone’s “add date" in the auto-responder series? We are using the API, so sample .NET code using the API would be great. Pseudo-coding would also get us going in the right direction. We noticed that the add date to the list is not a visible property of the member even though it must be tracked somewhere with their user record. Is their an API call to update that value? We are looking for a good way to solve our use case. The pieces seem to be there, we are just missing some of the un-published rules of the auto-responder series. We have spoken with several help desk folks. They have provided different answers in terms of how the autoresponder series works. If there is a better way to accomplish what we are trying to do, that is fine too. We just need a way to reliably “remind” customers that it is time to renew without making it a manual process. Any help is appreciated! I reached out to CC support and they told me to post here for an answer.
... View more