CRM Records: Dummy Tricks for Smarter Searches
Search is often a weak link in CRM systems, but users shouldn't have to write a special report just to find one piece of information. Dummy tricks can help fix the problem.
Tue, September 28, 2010
CIO — Earlier this month, I wrote about using a few Dummy records in tables to make CRM systems smarter. This time, we're looking at a different situation: Dummy fields that may be needed in all of a table's records.
In most CRM systems, the Search function is pretty limited. Almost all systems have the ability to do simple Boolean keyword searches, but the results are often too narrow and exclude "obvious" items that the users need. Further, most CRM systems' report engines aren't very smart about having intuitive Booleans for filters that can work on any field in a table.
Putting those "invisible" items into a SearchDummy field can make your reports smarter and searches less frustrating. If you'll again forgive me some more Jeff Foxworthy shtick here, let's walk through some examples:
If You Can't See the Name of a Referenced Object, You Might Need a SearchDummy. Even though the CRM screens and reports present related items as human-readable strings, they are typically stored as a pointer referencing another table (e.g., the "account" field in the contact table is actually a foreign key from the account table). So if users try to search for all the people who work at an account, the result set will be meager or even empty. They don't want to (or may not be able to) write a report just to quickly spot who works at XYZcorp, particularly when they don't remember exactly how to spell the company name.
A SearchDummy field can automatically include the string "XYZcorp" in every relevant contact, opportunity, case, or any other related table that references accounts, so those related records will show up in a search.
If you Can't Search for Pick List Values, You Might Need a SearchDummy. Pick list values are always presented as human-readable strings, but your CRM system may not store them that way. Consequently, when users try to search for "XYZcorp" AND "manufacturing" (the industry/sector pick list) the result set will always be empty. While in theory the users could write a report, why not make the system handle these ad-hoc searches all the time?
If You Can't Search for Numerical Ranges, You Might Need a SearchDummy. While your CRM system surely stores numbers as numerical values, there's no way to tell search for all companies with sales between $100 and $250 million. Some search systems won't let you search for numbers at all (as this can generate some seriously silly results).
You can set up a SearchDummy to flag numerical ranges on a few variables that your users need to screen for. The SearchDummy field will contain strings that users will intuitively use as keywords, such as "$100-250 M revenues" or "Last 90 days." Sure, you'll need to create a cheat-sheet of keywords...but this can be a real time-saver.
