I’m doing some database cleanup and have a number of accounts that were tagged with an incorrect constituent type when they were converted during the Tessitura integration. For example, id 12345 “Mr & Mrs Smith” is tagged as a corporate constituent type, but should really be a household. However, I have no idea what first name or even first initials are, so I can’t change the type in the front end of the client. (I should mention that all of the accounts I've checked are ancient and have no recent activity on them).
What is the harm/is there harm in me changing the type in SQL so that I have a more accurate count of constituent types? Or would you choose a placeholder letter/name? Or is this one of those things I should just live with?
Kathleen Smith said:What is the harm/is there harm in me changing the type in SQL so that I have a more accurate count of constituent types?
You'd run into no issues with changing a customer type via SQL, though making hhold records with no affiliates may end up with records that confuse Tess.
Kathleen Smith said:Or would you choose a placeholder letter/name?
This refers to a fname perhaps? If you're creating hhold affils for the new hholds above, and you have no fnames, yes, I would probably substitute "Mr." and "Mrs." for the fnames, lacking anything else. I think SQL would let you create constituents without a fname, but Tess will complain if you open one of these in the client.
Is there any reason not to just inactivate the accounts? If they don't have any recent activity, it may not be worth the time to clean them up.
Both Chris and Carol have points. There are indeed database concerns. You have affiliate, name and prefix issues. But frankly, if they are converted/import accounts and they have no activity, are they really worth anything to you? E-mailing them with zero purchases is not really actually anything. (I have had this fight with marketing.) And a duplicate account of an inactive account... is that really an issue? Just asking.
Kathleen Smith said:a number of accounts that were tagged with an incorrect constituent type
How many are we talking about? Re: Carol's and John's replies about whether or not these are worth cleaning up, the time it would take to do so is definitely a factor, even for data hygiene fans like myself. If a few hundred or less, and I would likely clean them up, one by one if necessary. If thousands, I'd... probably let it go.
All really good points. I sometimes feel like I'm on an episode of Hoarders and people are reluctant to give up (inactivate) anything. I may try to persuade people to let me inactivate one more time because I have SO MANY dirty old records.
Thanks for letting me bounce thoughts around.
At one point, I went and inactivated 10K+ accounts without asking anyone and waited for someone to complain. There was a brief question in e-mail about our marketing e-mail counts going down a little which I pretended to not see. Beyond that, I never heard a single word.
Just ask your staff if those old records are sparking joy. ;)
Beyond inactivation, my consortium has started merging constituent records that have no contact info and have had no activity in X years into our General Public account and then purging that record on a regular basis. Of course that's just one approach to cleaning, but the idea is that as these records age they become less useful (if they ever were) and cleaning them up (i.e. inactivating, consolidating) makes the remaining constituent records more valuable.
To your initial question about changing the constituent type to Household, though, while it's simple enough to change the cust type in the backend, like others have mentioned, creating affiliations, etc. adds another layer of complexity. Also, once those records are households, merging and data cleanup become a little more complicated as well. You could instead convert these records to the Individual customer type and either set the prefix or fname to "Mr & Mrs". Then, if your staff do have more info on these constituents they can manually switch the record to a household from the front-end and update the records as appropriate. Maybe after an agreed-upon amount of time the records that are still individuals could be inactivated en masse.