I have an ongoing problem. As an earlier adopter of Gmail, I have the “original” firstname.lastname versions of the gmail.com address for both my maiden and married names. This means that people with similar names often mistakenly receive email at my addresses. In the past several years, this has gotten much worse. Some of the emails I’ve received have included:
- E-cards for my daughter’s birthday from her grandparents (I have no daughter)
- Confirmation for my application for an energy job in Texas
- My itinerary for an Alaskan cruise, including receipts and travel documents
- Invitations to parties (several)
- A follow-up from a very nice gentleman who had gone on a first date with alter-ego me through a widows with children website
- PTA requests for the Catholic school in Arizona another daughter attends
- Legal documents related to an ongoing lawsuit
I just got another misdirected email that got me thinking about an edge case we rarely consider in service design: The mistaken account information.
This email was from Sprint, and included receipts and information for a new family account with 5 phones. Within the attached document, I had the phone numbers for all 5 phones, along with the home address of the lead person on the account, and access to create an online account through which I could manage their phone plan. The security info I needed to create the online account using the link provided was all in the email attachments. Essentially, when the customer mistakenly gave my email address to Sprint, I received a back door into an important part of his financial life (yes, his. I don’t even know anymore.).
I have no desire to deprive this family of its Sprint access, so I called Sprint to rectify the mistake. The first representative I spoke to was unable to help me because I did not have the security information for the account.
Let that sink in: I couldn’t remove my contact information from the account because I didn’t have the security information the actual customer had provided.
Now I did have a way to update that information myself by setting up an online account, but again, I’m not a total jerk. So I asked what I could do and was directed to Sprint’s fraud line. I spent another 20 minutes navigating phone trees (many choices led to being hung up on) and finally reaching a rep who removed my email address from the account.
The point of this post is not to complain (although I don’t mind venting a little about this ridiculous situation). It’s to note that I have personally never in my career considered the type of edge case that I now frequently find myself in: The person who’s been accidentally tied to an account by mistakes in contact information.
And I don’t think many other designers have considered it either, based on my experiences calling and emailing various businesses to ask them to remove my email address from an account. The lawyer who sent me the legal documents defended himself by saying I was entitled to see everything in them, then when I pointed out again that I was no relation to the woman actually involved in the case, stopped responding. The travel agent sending me Alaskan cruise plans will stop for a bit, then send me an updated itinerary by replying to an old email. And Sprint was utterly unhelpful; the only reason my problem ever got resolved, if it really has been resolved, it because I was lucky to reach a rep who was willing to be creative about solving the problem (thank you, Julio!).
I’m certain there are many other unusual but not impossible edge cases like this where we have failed to design easy solutions. In the case of mistaken identity, it would be helpful if companies had policies in place such as:
- Remove a piece of contact information from an account on request, but do not permit the person making the request to change any other account details
- Allow someone following a link from an email to an account creation page to select “this is not my account” and opt the email address out of further communication
- If either of the above has happened, trigger an outbound communication to the actual account holder on another contact method such as phone number, if available
Have you ever designed for the mistaken identity use case? What has your solution been? What would you do?