A caller says, “It’s Bill Henderson, I’m a member.” Your staff member types “Bill” and “Henderson” into constituent search and gets nothing. The record exists, but it’s under William, with Bill in the nickname field. The caller waits while someone tries “Will,” then “William,” then gives up and searches by last name only and scrolls.
The front desk runs into this all the time, and it’s worth understanding exactly how your Altru search treats the two fields before you train anyone on a workaround.
First name and nickname are separate fields
On an individual constituent record, Altru stores the legal or formal first name and the nickname (the name the person actually goes by) in different places. That separation is useful: acknowledgment letters and tax receipts can use the formal name, while membership cards, emails, and the desk greeting can use the nickname.
The catch is search. Whether typing a value into the first name box of constituent search also checks the nickname field is something you should confirm in your own database rather than assume. Search behavior can depend on configuration and on how your records were entered, and we’ve seen staff at different organizations come away with different impressions of how it works.
A two-minute test
- Pick (or create, in a sandbox if you have one) a constituent with a distinct first name and nickname, for example first name “Katherine,” nickname “Kit.”
- Search with only the nickname in the first name box and the correct last name.
- Search with a partial first name (“Kath”) and the last name.
- Note which searches find the record. If the nickname search comes up empty, you know the first name box only looks at the first name field.
If the results are unclear or seem inconsistent, ask Blackbaud support how constituent search handles nicknames in your environment. That’s a quicker route than guessing from a handful of records.
Search habits that work regardless
Whatever your test shows, a few habits take the nickname problem out of most lookups:
- Lead with the last name alone. For anything but very common surnames, a last-name-only search returns a short enough list to scan. Add a city or ZIP if your search screen offers those fields.
- Ask for something unique. Email address, phone number, or the member or lookup ID on a card will find the record no matter what name it’s filed under. Train staff to ask for one of these before they start guessing at names.
- Use partial first names. If wildcard or “begins with” matching is available in your search, “Will” catches William and Willard. It won’t help with nicknames that don’t share letters with the formal name (Bill, Peggy, Jack), which is exactly why the habits above come first.
- Check households. If the caller says their spouse bought the membership, search for the spouse and open the household. The person on the phone may be a household member with a name nobody expected.
Build a query when you need both names at once
For back-office work, such as matching an event list or a spreadsheet of names against your database, a constituent query gives you more control than the search screen. Add first name and nickname as criteria joined with OR, plus last name, and output the lookup ID, both name fields, and email. That gives you every record where the name matches either field.
The same query, with output only (no criteria), is also a good audit tool. Export it and look for records where the nickname is blank but the first name is obviously a nickname (“Bob,” “Liz,” “Tony”), or where someone typed the nickname in quotes or parentheses inside the first name field. Those records are the ones search will trip over later.
Fix it at data entry
Most nickname search trouble starts when the record is created. A short written standard helps more than any search trick:
- First name holds the formal name when you know it; nickname holds what the person goes by.
- If someone only gives you “Bill,” enter Bill as the first name. Don’t invent “William” on their behalf.
- Never put quotes, parentheses, or two names in the first name field (“William (Bill)”). It breaks salutations and makes search less predictable.
- When a guest corrects you at the desk (“Actually, I go by Meg”), update the nickname then and there.
Online purchases deserve a look too. People type whatever they’re called into a web form, so many records created online will have the nickname in the first name field. That’s fine as long as staff know it, and it’s one more reason to search by email first when the person bought online.
Watch for duplicates this creates
When a search under one name fails, staff often create a new record. Over time you end up with “William Henderson” from a donation and “Bill Henderson” from an online ticket purchase, each with its own history. If your duplicate review compares first names exactly, these pairs won’t be flagged. Include last name plus email or address in your duplicate checks so name variations surface, and make “search by email before creating a record” a firm desk rule.
Quick answers
Should we copy the nickname into the first name field so search finds it?
No. You’d lose the formal name for receipts and letters. Use the search habits above instead.
Which name prints on membership cards?
That depends on how your card templates and name formats are set up. Check which field or name format they pull from, and decide deliberately whether members see their nickname or formal name.
