FoundationTennis and the TennisCommunicator sends one email to one contact record or one email address based on the selection filter used. Your customer can receive multiple emails however when you have multiple contact records in your database, each having the same email address.
Note: Foundation Tennis and the TennisCommnunicator allow multiple people/contacts to share an email address. Email address sharing across contact records is allowed to support family and couples memberships where one member of the family wishes to receive all correspondence.
So there are good cases where an email address may not be unique across member/player records, and there are as many ways to"not send" email to members and players who do not wish to receive email from you (discussed in the workarounds section of this article).
Before addressing the remedies in the case of multiple contact records and duplicate emial addresses, let's take a look at the software specification and warranty (how the product is warranted to work).
When you send email based on:
- Contact Manager, we generate one email per contact record.
- Distribution List(s), we send one email per contact record. Contacts belonging to more than one selected distribution list are "de-duped" after the list is generated, and before the email is composed. For example, I belong to multiple distribution lists (Parents of juniors and U10 volunteers). When you send an email based on Distribution List membership, selecting both Parents of juniors and U10 volunteers, my record will meet the selection criteria twice, and only be selected once, as the software will de-dupe the list before the email is composed.
- Payment items, we generate one email per unique email address for that payment item. For example, where I have made multiple purchases of a particular item, and you are sending email to all buyers of that particular item, I will receive only the one email. If I have made purchases of multiple items, and you are selecting multiple items in the selection filter, I will receive only one email.
- Event enrollments, we generate one email per unique email address regardless of the number contact records, number of enrollments and or participants in the event(s) selected.
- We never send email to contact records marked as children.
- We do not send email to deactivated contact records.
In summary, the Contact Manager and Distribution lists will only send "duplicates" if you have duplicate contact records. Payment items and event enrollments will never send duplicates as the email is not based on contact ID, but rather unique email address.
Underlying causes of 'duplicate' complaints and best practices going forward
TennisConnect, TennisCollect, and the String center allowed 'anonymous' enrollments, payments, and string tickets. By "anonymous" we mean in the database sense where names and addresses were just typed into forms and not connected to actual database / customer records.
Everytime the 'anonymous' process is used, it creates a record in the background, since the system must have a contact record to support every transaction - especially for enrollments/payments where credit card processing has been involved.
This practice was allowed, dating back to 2004, when the consequence of adding duplicate records was considered relatively less bothersome than requiring customer to login, or staff to pick from drop down lists.
Note: Foundation Tennis also allows"anonymous" transactions under certain circumstances. Generally we recommend that you avoid anonymous transactions, however it is a very useful capability for transactions expected to be one-time or non-repeat customers, or for customers who are uncomfortable creating a login.
Common uses of 'anonymous' transactions include:
- donation payments
- enrollment and payment for special fundraiser events
- special event purchases from people who are not your regular tennis players - like for the annual US Open bus trip
I think all Foundation Tennis customers hold community and charity fundraisers at some point, and/or sell tickets on your website. I know I am reluctant to register on a website just to make a donation, but will do so readily when all I have to do is enter my credit card to make a donation. I don't think I am alone, and that is why we support non-logged in (anonymous) transactions.
Deciding to create anonymous transactions is always your choice. You can require web site registration and use advanced payment forms instead of basic payment forms. It is always a deliberate choice not to require web site registrations (which will create a 'duplicate' contact in the background).
Login rules by transaction type
|Basic payment form|
|Advanced payment from|
|Payment on account|
|Using the APP|
x (one time login)
|Event enrollment||per your event setup||per your event setup|
|Profile update macro**|
*Note: when anonymous is supported, it still helps to be logged in, it is just not required. All payments are accessible through the member profile whether the transaction type being performed requires a login or not (as long as a player is logged in, we can tie everything together for them).
** Information about the profile update macro is available here.
- Training your staff to choose contact records from the drop-down lists will prevent creating future duplicates
- Monitoring and correcting duplicate registrations as they occur will help keep the task manageable
- Register your members for them - even if you and your staff are the only ones to use them (especially if you and your staff are the only people to use these records - they're your customers!)
- Use the Contact Manager upload and reload tools (click here to learn more)
Remedy - De-duping your database
You can de-duplicate your database yourself, or we can help you with Professional Services at our standard rates.
The workflow and principles are the sames. Sometimes our experience will allow us to do this faster for you, and it is worth investing in a few hours of support.
You will need to go through your contact manager and decide which records to de-activate. This requires investigation that can require some creativity, so the process is not 'hard and fast'. The exact steps for your database will vary. I can share what we do when you hire us to help:
The basic strategy is to do the work in MS Excel, adding a column to the worksheet to mark which records you want to keep and which to deactivate or delete
Deactivated records are still in your database in case you need any of their history, but they are not shown in Contact Manager nor selected by the group email system unless you "re"activate them. So the deactivate / reactivate process gets them out of the way of everyday uses.
You can delete records too, however we do not recommend deleting records since they are tied to other transactions (such as payments), which may leaving the other record with a number of blank or null fields.
Here are the steps we usually take>:
- download your data to MS Excel (Contact Manager >> Settings >> Export Contacts)
- add a column for 'keeper'. I also use this column to mark records that I actually want to delete as well
- look for duplicates by sorting the spreadsheet. (and use your 'keeper column' to mark the records you want to keep)
- we sort by last name, email address, phone number... anything that could highlight a duplicate
- then we sort by lastname ascending and at level 2 MemberID ascending.....
- ...it's a lot of sorting and scanning
- and then decide which record we want to keep. We look at the username and MemberID, and look back at the Contact Manager Activity tab in FoundationTennis to help figure out the 'best' record to keep
- sometimes you can tell which records may have been set up by mistake, or only have one old purchase on them
- and sometimes we call or email the customer - it just depends what you find
Tip: there are many clues that can be used to decide which records to keep and which records to deactivate
- The MemberID is a sequential number, so the higher number is the one created last. That is usually the keeper.
- The username can also be telling. Contacts created from anonymous payments or string tickets, or users 'opting in' without registering on your web site, will have a default username that is their first name + a 7 digit system ID (MemberID).
We understand that you cannot please all the people all the time. Consider these workarounds:
- Use a default email address. Members/Players who do not wish to receive email can use your default email address - so you get the email instead of them. (make sure it is a valid email address though, or you will hurt your domain reputation / spam score).
- Separate your members by Member Type, and set aside on type to whom you do not send email