I’ve talked long enough. I’ve griped long enough. I’ve hoped long enough. The end of NPSP development and the launch of a very different NPC under Industry Cloud put a cool on all work. It became impossible to know what to do. It’s been a couple of years now, and in my opinion, it’s really not any better.
So here’s what I’ll be trying to do in my last few years at the helm of Street Youth Ministry’s CRM or data solution. These are principles that I believe would make for a strong and safe implementation. I can’t fix the dilemma of NPSP vs NPC nor the overwhelming amount of “stuff” coming from Salesforce. It’s not a satisfactory position to try to hold but I don’t actually see a better solution so it must be sufficient.
Anyway… here goes:
My solution using Salesforce will be moving toward these features as fast as possible:
- Good architecture applicable to NPSP or NPC or Core. I have no control over what eventually happens here so I have be to OK with any of them.
- Static (nearly immutable) record tables for recurring / chronic data collection connected immediately or later as sufficient knowledge emerges to accounts and contracts for good CRM. This doesn’t necessarily mean Data Cloud but it recognizes the reality of what a data-excessive world looks like. Honestly, all of growing data tables could be implemented in block chain to enforce this… lol.
- Potential to use Data Cloud, Flow, Tableau, DLRS, NPSP or NPC and their customized calculation engines. It would be marvelous to have only one way to calculate, review or do something but that’s just not the Salesforce reality. But the data tables themselves should have nothing to do with any of the analytics. Very solid separation is essential.
- Potential to use the value-oriented features of core or basic marketing (email and web) and phone number (voice and text and recorded message) capabilities since CRM without these at scale is not attractive.
- Built on established objects (people are always contacts, businesses are accounts) well supported and established in core and app exchange. The UI is just too snow-flakery to ignore standard objects.
- Not built on the ideas of limited storage (a very old Salesforce idea who time has come to end) and constantly changing fields being updated or edited by staff or all-knowing integrations of some sort. The facts don’t change so why do we change the records. Just add records and let the computer do the rest. This is essential.
- Built on the idea of ever increasing tables of data which are essentially immutable facts captured by people doing their daily jobs or interacting in normal ways along with the discovery and enrichment of additional records and connections between records that can be added by AI, humans, Data Cloud, algorithms, external data sources, and constituent updates.
- Build around the only scalable and sustainable architecture numbers: 0, 1 and many. Everything else is a compromise and a poor one when it comes to the passage of time.
- Built to allow human and data to select where their focus is in terms of seeing contacts and accounts and underlying records. Humans have reasons to focus on some groups. And the data needs to tell us additional humans or groups to focus on. No one needs to drown in the data. You might imagine someone who joins the company and has NO contacts. Their boss decides what their focus is and assembles for them a set of data that’s relevant for them to work with from the immutable tables, AI or Data Cloud assembles the contacts that are inferred, and they go from there.
This might be claptrap… but in that case… the current nonprofit Salesforce situation will likely kill my CRM implementation within a few years. Managing this transition may be easy. Or it may be the challenge of the decade. We’ll see!
Where do I start? I’m probably going to start by fixing the stupid contact model that thinks where are two addresses (wrong), three email addresses (very wrong), and 5 or 6 phone numbers (actually wrong in the wrong direction). There need to be an unlimited number of each, some marked as no longer valid or no longer preferred. You won’t change a phone number anymore. You’ll capture phone numbers in the transactional content in which it arose, and if a new phone record needs to be added to a contact it will get noticed. Maybe a human as to be asked. Once determined, however, the phone record get’s updated and–to make the UI happy–we’ll also update the existing standard or usual fields… in the background.
How might we get a new phone number? On a check we deposit (not common but still happens), from a call record, from a online donation (rare but some processors have it), from a web form filled in, from a visitor log entry. The focus could be to capture or pull in all of these transactions faithfully. Then let something like Data Cloud or flows notice the overlap. And let something like flows notice new items that need human help. Honestly, we we don’t know, we have to make a business call and ignore or call and find out who it is. But the CRM needs to built to match our real world now.
Let me know how crazy you think I am. Lol. It’s OK!