How are you using the Nickname field?

Max Classic
1

There doesn’t seem to be any programming logic behind the Nickname field. Am I right?

When I first saw the Nickname field I assumed IS would look at Nickname and if there was a value in the field, use it to override the First Name field when merging First Name into emails because using the more familiar nickname reinforces that we really know our contact. But, the software appears to not use the Nickname field…it just stores it which I don’t find very useful.

The other place I would love to see it used is in duplicate checking when adding a new contact or running the dedup process. If first name or Nickname matches either first name or Nickname consider that part of the name a match.

To make up for the lack of functionality, I started putting the Nickname in the First Name field and the formal name in the Nickname field. This sortof works but isn’t reliable.

I find that when people register for events, or even our webinars, they tend to use their formal name and the Nickname in the First Name field gets overwritten. Depending on the platform used to capture registrations and the parameters sent with the url, sometimes the first name is prepopulated and the contact will just go with it.

We speak at a lot of conferences, etc. and often get a list of conference attendees (without getting their email addresses). I import them simply to apply a tag that they were at that event to keep track of touch points and to capture the event as the leadsource for new contacts. After I the import the list I dedup them. However, the people with First Name mismatched (e.g., Andy in my existing contact and Andrew in the import) don’t get deduped because IS doesn’t compare First Name AND Nickname.) I am left with many duplicates and have to manually find and merge them. My latest import was about 600 records and my boss attends about 15 big events a year so it can be a big time sink.

Has anyone found another way to manage this lack of functionality with Nickname?

Thank you for your insights.

1 Like
2

Yeah, I think your understanding is correct. It doesn’t have any real logic behind it.

The ways that I’ve seen it used are for scenarios where you have members, or people you have closer relationships with and you know they they prefer to go by a different name; so you manually store their Nickname in that field.

This could be useful for sales reps who are calling out and you want to make sure they use “CJ” from their nickname field instead of “Christopher” from their First name field.

1 Like
3

I, too, would like the nickname field to be used in letters where I would specify ~Nickname~ but get ~FirstName~ if ~Nickname~ is blank.

Nobody wants “Dear Mathias” when they only use “Matt” in conversation. They KNOW they’re on a mailing list and it’s TACKY!

1 Like
4

Hi, @Jeff_Johnston,

So in your case, you can run an action set that raises a tag if the nickname field is empty. Then, based on that tag existing, you can use a decision diamond to split to one of two sequences that either use the nickname merge field or the first name merge field in the other.

5

Nora, great idea! I like including Nickname as part of the dup checking process.

I use Parsey to update records of existing clients, and sometimes for adding new Contact records, and so I use the first/last combo (alone, without email, etc., typically because I don’t have any of that other info available from an email that merely mentions their first and last names, and formal names at that.

I also get spouse’s name as the first/last, which doesn’t find the record because the FirstName field is the other spouse. Think husband as FirstName and wife as Spouse name. I’ve asked Parsey to consider adding to their first/last name only look up to look at SpouseName as a backup if first/last is not found, and to do that automatically, so that the email with hubby’s name gets looked up normally just fine, and then the email with wife’s name gets found by first searching for her just like we did him, but then look in SpouseName field for a match as a second attempt. Jury’s still out on that one, but ask Jarrod at Parsey to do my idea, please. :wink:

I only have 20 or 50 ideas for them so he knows my name really well. :wink:

But you bring up a great point of the de-dup’ing process might consider Nickname and also SpouseName fields as potential duplicates. I never thought of that as I don’t use the de-dup process much, or well, only when it becomes apparent that I have a duplicate. But, I love your idea!

I feel like I’m the lone ranger with many of my contacts representing a couple. It’s not feasible for me to have two Contact records… what if yours said I filed your joint return but your spouse’s Contact record did not match the numerous fields and tags that would reflect such was the case. Hence, I live on the 149 to 150 edge of custom fields. Okay, you could probably assume all 150 90% of the time. I continue to BEG for more! :wink:

NickName is a HUGE deal for me. I wish the system would deliver NickName when present, else FirstName, and that SpouseName was Spouse-First and Spouse-Last and Spouse-Nick as three separate system fields.

I have modified the Birthday campaign to handle using _SP-DOB custom field so that it sends birthday messages to Spouse on their birthday as well as the primary, but sending it with NickName that says “ & ” isn’t the greatest salutation on a birthday message! But, using the first name off their tax return is hardly personable on a Happy Birthday email. Neither is using “ ” a great salutation for her birthday card, either. It’s bad all the way around without separate fields for first/nick/last for EACH spouse. Spouse’d birthday should be a system field, too.

My recommendation to InfusionSoft (or Keap as the younger ones know it) is to:

1 - have completely separate fields for EACH spouse: First, Nickname, Middle, Last, Birthdate, SSN; one set for the primary, another set for the Spouse;

2 - have the system automatically deliver FirstName when NickName is empty (for each spouse) when referencing the NickName field in a report, email, campaign, etc.;

3 - have Nickname (for each spouse) be available in all field-picker windows (which is NOT the case now!);

4 - have Nickname “filled” an available test choice in Conditional use formulas (which is NOT the case now!), along with MANY other fields… why is empty a valid test, but filled is not?!?;

5 - have Nickname “empty” an available test choice (which is NOT the case now!).

Any further thoughts? I’d love to hear them to include with my laundry list of these kinds of things that I promised InfusionSoft I’d give them after a discussion at PartnerCon about these and similar issues.

Jeff

1 Like
6

Late to the party here, but I noticed our email campaign behavior using non-preferred (non-nick-)names as well, and found this post while looking for logic to handle that situation. (I feel a personal stake in this since my birthname is not my legal nor preferred name.) For now it sounds like the decision-diamond campaign split is the known way of handling it, short of an external-to-Keap solution, from what I gather of the above, right? Thank you.