By: Bethany Avery, Practice Manager
An organization that has been live on any software platform for some amount of time can tell you that the types of data organizations need to collect is not static. The list will not magically stop growing the day you go live. And if it did, this might be a good time to take a look at what data you aren't collecting and why.
With extensible platforms like Blackbaud CRMâ„¢, it's easy to add a new field to capture data related to a new business need. You can also use robust out of the box attribute and attribute form extension functionality to add new fields with simple configuration, no coding required.
Yet before you dive in and start adding new fields - and a million new attributes - there are a few questions you should be sure to think through.
Does it overlap with anything else you are tracking? If so, consider adjusting rules or values for your existing data point first as there is nothing more confusing than overlapping or conflicting ways to track the same thing.
How will users need to use it and report on it? This is the central question behind what you decide to set up and where you set it up. Is it for segmentation, financial reporting, donor preference management? Thinking through the real need, and any surrounding needs such as reporting will help you ensure you set it up in a way that actually allows you to accomplish those needs.
How will it be added? Will it be manually added, will it come in via imports? If so, which ones? The answer to this will determine if you need to not only add a field, but potentially extend batches, add logic to import processes, etc.
How will it be updated? Frequently, users have thought about the question above, but not this one. If the data is purchased (i.e., NCOA), does your organization have plans to purchase a refresh on an annual or more frequent basis? Will it be from the same vendor? If not, is your structure flexible enough to grow? How will you keep the data from getting stale? Do you need to set up a global change to remove it when it is no longer relevant?
How will you ensure consistency? I'll state the obvious, but where possible, use code tables over free text. And set defaults where applicable. Also ensure your staff is clear on how to use the field, including any ancillary values such as start dates and comments with attributes. The devil is in the details!
Is it documented? Every organization should have a data dictionary, and every new field (or attribute) should be added. This is useful for developers, end users and some day when you switch software systems, you'll be glad you have it.
Is this really an attribute? Attributes are the junk drawer of any CRM system. They're a place where you can store all kinds of information and then some - but that doesn't mean you should. When determining if you should add a new attribute or put the data elsewhere in the system, consider what type of information it is. Will you need more than one attribute to capture the data? If so, will those attributes be updated in the future? If they will, how will you "group" them so that end users understand which attributes are related? Consider other areas of the system to track data that is recurring or complex.
And there you have it! Taking the time to answer these seven questions at the outset will go a long way in preventing short sighted setups and future messy data.