Thanks to those who were able to join Chris and Sheetal Persaud from UNHCR Canada at the #21NTC session, It’s not the CRM, it’s your data! There were a lot of great questions in the chat, though we ran out of time to address some of them. We’ve included those questions below along with some pertinent comments.
We're going to have to do a map like this. Great idea.
Yes! Here are some steps to get started on making your own data map, and a sample data map to illustrate a possible outcome.
Yeah really interested in how folks are approaching this for constituents whose relationship isn't transactional; so many nonprofit data tools seem very biased to the *donor* relationship which misses out other ways we interact with folks
There are ways to accommodate non-donor supporters in industry leading nonprofit software. Unfortunately, organizational culture can come into play, where marketers and/or finance control coding and data, resulting in no consideration for non-donation relationships. This reiterates the point in the presentation about the importance of cross-functional teams, so everyone who is constituent-facing is at the table and can provide input on their needs. Constituents such as volunteers, mission-related partners, and stakeholders among others should be accommodated, since they are important to the organization.
Staffing/training is such a huge piece!
100%. Foundational training on the importance of data to an organization and the tools/resources that they use should be required on-boarding for all staff. This is needed even for those who don’t work with the database, sometimes requiring a cultural shift in the organization. Otherwise, for example, they could find themselves with a list of committee participants that they then put into a ‘rogue spreadsheet’ instead of using existing centralized systems.
Post-data audit, what does UNHCR's systems map look like now?
See Sheetal’s answer
@chris, do you have examples of questionnaires/protocols you could share? I love that idea!
This question was about how to decide whether information should be put in the database, for example by a database manager or cross-functional data team. Here are some questions to consider or use to develop your own protocol.
Is it useful? Is it important long-term? Is the database the only place it should live? Is there other similar data anywhere else (including other systems)? It there an existing field that this fits in? How will leverage this data (e.g. queries/reports)? Who needs to access this data? How easily can this be updated, and by whom? What is the source of this data? Are there fixed categories within? (e.g. income ranges to select from, or user-entered?) Will it become out of date/need commentary/need a date stamp (e.g. noting the income info was from 10 years ago)?
Reflecting on these last discussions and figuring out how to do it in a very small team. I'm determined that our small size won't keep us from good data but our options (in terms of time resources to spend) are limited. Ideas for prioritization?
The immediate priority is to establish your procedure, policies, and coding structure. If you can’t do a clean-up, at least everything moving forward is meeting the new standard. It won’t fix, for example, data in reports including last year, but reporting for this year will be far easier.
I'd really like to get, say, our marketing teams comfortable pulling their own lists, or membership pulling their own reports, etc.
As someone commented, yes, training is one way to facilitate this. You could develop your own syllabus, explaining how people can pull their own lists or reports. If people would respond to such incentives, you could use a survey tool to develop a quiz, and people get a ‘certificate’ on completing the ‘course’. Note: for reporting and querying, this should be fine, but make sure their permissions are such that they can’t do anything that could cause a problem for the other users (deleting records for just one example).
Another crucial element is having clean data. If they can go into the database and push a button to run their report, that’s easy—but not if it requires manual cleanup or reviewing records to confirm the report.
Finally, a caveat: if someone is very keen, they might get an idea like, “I’ll just call everyone in the query results.” Things like this can happen when they don’t know about some pieces of data that seem minor but are crucial: solicit codes (e.g. do not call), or soft-credits, or assigned solicitors, or how people are marked deceased, among others. So be sure to develop comprehensive training, and secure users’ permissions considering even things like who can export data.
Where does one start with data cleanup?
The first step in cleaning up your database is a database audit:
Note these steps can be undertaken by a database manager, a cross-functional team, or a external source.
data cleanup before or after purchasing CRM?
This was partially answered in the comments, but here is a more detailed response.
Firstly, it’s generally better to start with a clean database, so you don’t replicate old systems. Secondly, understanding the needs of a clean, functional database can better inform your decision on which CRM is best; if you are looking for a solution that will accommodate complicated manual processes to work around messy data, you might find after the clean-up that this is no longer needed, changing your CRM requirements. Further to this point, part of the clean-up should be ensuring that the data functions for all stakeholder are addressed—without going through the process, other users or departments may not be taken into account. And finally, since this process can take time (always longer than expected), there is no need to pay for a new CRM until you’re ready to start using it.
It will probably take us a year or more to even clean our database, so can't wait to learn more data stuff next year :D
Yes, it’s typically a longer-term goal to have a clean, streamlined dtabase. Chris undertook one database clean-up that took 12 to 18 months, even though it was a fairly significant in terms of the amount and complexity of data. It was able to move fairly quickly because: the data structure was replicated in Excel to allow others to understand what resourcing was needed (staff time, budget) and get buy-in to the project; there were several people on the core committee, from different departments; each person on the core committee was given their own tasks which could be carried out while they were still using the database for their day-to-day needs; and an external person was hired to undertake work such as global updates, made possible because of the budget because of support for the project.
As they say, the best time to plant a tree is 50 years ago; but the second-best time is now.