BC support have stated that the system cannot currently allow identical email addresses for multiple customers even if you choose to use a unique YOUR ID. No identical email addresses can be used across multiple records, end of story.
I am aware that "senior" BC parters have raised this issue before and I'm pleased it's being considered at that level, however that doesn't help me now.
We are developing a website for a tennis club and the idea is for the system to help with purchasing and renewal of memberships. However, we've hit a major snag, many people who belong to a club use the same email address; couples, families etc and because BC won't allow identical email address we don't know how to handle this issue. BTW, we're not talking about one or two instances here, many, many people use the same email address.
Here are a few examples of where we hit the wall:
A couple (that use a single email address) decide to purchase membership online at the same time, they enter 2 x adult memberships. When they get to the check out, because if the limitation we can only, register an email address against one of their names, so what should be a simple case of collecting details for both members so we can hold them as separate records, becomes a headache as we now need to come up with some type of "couples" option in the system where a couple will buy 2x adult memberships as one product with a "main member" and some kind of "attached member". This presets a number of issues especially when running reports, It all becomes unnecessarily complex and adds unnecessary overheads.
The same as 1A except that it's a family, so 2 adults and 3 kids for example. We could use the "main" and "attached" solution, but that means we don't get individual records for the 2nd Adult and none for the kids. This is a bit easier as the FAMILY category exists already, whereas the club doesn't have (or necessarily want) a COUPLES category.
One partner in couple (that use a single email address) buys membership today… no issue here as this is processed as single adult. 6 months later however the other partner decides they also want to join… they get to the checkout and enter their (joint) email address and the BC system either produces an error message saying "the email address is already being used in the system, please use another one" or it will overwrite the existing record (I'm not actually sure what the BC system will do).
Has anybody come up against the same issue and found an acceptable workaround?
What Partenrs do you feel think this is a big issue because I for one do not want to see any system allow sharing of an email address for multiple users.
There is a heap of problems, masive ones with such a concept allowing a system to support that.
Consider the password reset just as one example and the email going out..
I can just think of way to many bad reasons why I do not want this.
A username can be the same, so to the password which is a problem but you can get around that by using the email as username...
I can go on, really easily but - Have to totally disagree, I for one never want to see multiple CRM customers being able to share the same email - No thanks!
Many people use same email address? I hope not and every time we have customers who do- we get them to change their practices.
Lots of correct methods to implement such things in the proper way with the relationships that can be set up, custom fields, use of username and password... Just a lot of the right way.
Maybe others will disagree (I hope not) but all of what you outline I would be doing very differently for heaps of reasons :/
Thanks for the reply. I can certainly see why in some/many/most instances identical emails would not be wanted or warranted and as you've pointed out can see how it can affect some of the system operations. But I'm still left with a problem I don't know how to resolve.
Many people use same email address?
Yes, in a club situation many people share the same email address, many couples and many families.
Lots of correct methods to implement such things in the proper way
I've looked into relationships but can't see the benefit. You don't seem to be able to run a report against them, so list all people with relationships, or filter against them. There is also no flag in the main customer details view that that customer has any relationships, so nothing to prompt you to look under "More>Relationships". You could add an extra CRM field with a note, but if you're going to do that, and with benefit issues raised above, you may as well just stick the relationships straight into the note.
I am using custom fields, perhaps I could use them better, but however I use them I don't think they will resolve scenario 2.
use of username and password
How could U&P be used to resolve the issues presented in the scenarios?
Just a lot of the right way
I've spent a lot of time contemplating and trying to work out solutions to these issues. I think there are perhaps solutions around some of them, probably clunky ones and extra work for all involved, but I'd be willing to consider any reasonable solution. The one issue I can't see a solution for is scenario 2, just stumped on this one. Do you know what the system will do in this case? Will it produce an error message or will it accept the application and overwrite the existing record?
Tim did you come up with a solution for this?
I'm quoting for some sporting club websites and will have exactly the same problem. Say a junior football club 2 children aged 6 and 9 plus parents
I need to be able to keep the children seperated in the database so I can put them into correct age groups / teams etc. but 6 and 9 year olds don't have email addresses.
Liam understand fully issues re multiple people using email addresses but in case of children and this environment its an issue.
Any work arounds
We're working on it, come up with a few possible workarounds... current favoured is the 'main' and 'attached' idea where we'll capture the main/primary details and take payment, then on 'thankyou' page if family or identical email has been detected we'll ask for 'attached' member details. Attached members will get a record but without an email address, which is not ideal, but is ok as they have agreed to be an attached member. Fair amount of fiddling and work involved.
Correction: 'senior' partners have not raised this as major concern. It's not on the radar so workarounds will be order of the day for foreseeable future.
Europe, Middle East and Africa