[Peter Gulka]

I just had a meeting with a couple members of the Development team in my department. We have 2 opposing schools of thought when it come to prospect identification that I would like your opinions on.

SCENARIO: in Canada due to privacy laws we cannot use services like PropsectPoint or WealthPoint on corporations or private companies. Any info we get we need to dig up ourselves. We get lists and directories of companies in particular sectors that contain only basic contact information, and what area of a particular sector they belong to. We have been tasked with inputting these lists as constituents in RE so we can start the process of research, identification, and assignment to our Development officers. Obviously there are resource issues when presented with a CD directory with 35,000 Canadian companies on it.

We have created an automated scoring system that is based of data that exists in a constituent record (source of the prospect, past giving history, gifts to other orgs, etc), but since it is based off data in the system, blank records get no score or low score.

Here's the debate:

OPTION 1: Enter all 35,000 companies as constituents. They become "placeholders" and we add tidbits of info here and there. The scorecard will gradually get increasing values as the volume of information grows.

OPTION 2: We develop some kind of pre-qualification system that happens before a record goes into RE. That way if 4,000 of the 35,000 go in we have some assurance that they are not just going to sit there and stagnate.

The problem with OPTION 2 is that at some point someone needs to decide what goes in and what doesn't. Early on we need some way to say "X is a good candidate as a prospect but Y is not."

The concern of our Advancement Services manager who heads up research is "What if one of the 31,000 would have been a gold mine but we made the wrong decision? Better to capture them all and have some stale records then miss one"

Any thoughts?

[DrewAllen]

First, no matter which way you do it, there is a possibility that you may miss the "gold mine". Even if you import all of the records, you still need to allocate your resources to do the research on them. The choices you make in this allocation could cause you to overlook a "gold mine" regardless of whether this allocation occurs before or after the import.

Second, your database isn't static. Just because you don't import a particular record today, doesn't mean that you can never enter it into your system. If you find a "gold mine" that isn't already on your system, you can simply add it at that point.

I think that you will gain a lot more by filtering the records before importing them into the database.

Drew

[Peter Gulka]

That's what I think too. The question then becomes HOW do we filter records before they get into thesystem? Someone has to ultimately decide "this record goes in but this one doesn't".

How is that decision made?

[RobertWild]

I agree - you do need to filter it prior to RE. Perhaps in something like an access database to hold all the data, and use that to manage it. As for filtering, I'd look at develop a wholly new ratings system - ie: If they engage in philanthropy = 1 point, philanthropy to your sector (eg: Education) 2 points, philanthropy to related sectors 3 points, philanthropy to your institution's specialty = 5 points, and anything at 5 points or more goes into RE. Just as a possibility.

[Melissa Siobhan]

I definitely think that the research is in order but if you research a company and find them not to be a good prospect I think that should go into the database. Maybe just so someone don't repeat the research later when they don't see them in the database - or so you can intentionally re-research after some time (3-5 years) to see if their prospect status changes (find that gold mine). I think knowing that you don't have enough information on a company to score them using your system IS data and should be in the database.

I'd vote for having them all in the database to track this information - but then that's just my 2 cents.

[RobertWild]

Good point Melissa, however (speaking for myself) I'd be a little funny about having several thousand records in the system for potentially both a long time, and little reason.

I guess that you could always have the 'dead' records as being inactive...

[Peter Gulka]

"dead" is too hard a term. Hibernating might be better in our situation. We undertake very large, project-specific fundraising campaigns.

Company X might not be a good fit for the Centre for Business we are trying to fundraise for right now, but 2 years from now when we start fundraising for the new Centre for Health & Wellness, they might be at the top of the list.

[RobertWild]

Hm.. as that's the case, then I'll change my position / recommendation and agree with Melissa - probably the lot should go in RE, with relevant flags wherever you decide to put them for the ones not researched.

[DavidZ]

I would tend to agree with Robert. The worst I can imagine is having another database to administer with everything it entails. If you have a separate list/database outside of RE, there is a risk that somebody else will enter the constituent not knowing the existance of this list. In that case you start getting duplicate information and all of a sudden your potential goldmine information is split over two databases.

David

[coffeebug]

however, can you imagine trying to maintain around 30,000 "dead" or "hibernating" records, hoping their addresses haven't changed, their contact info has remained the same, they haven't merged with any other records!!

I think that I'm with Drew on this one. If there's a record that needs to be added in the future it can be added then. Why add 35,000 records (which no one realises won't be an import, it will me ME adding them all manually) when that means I will have no stronghold on all of those records while they are in limbo.

I would much rather maintain a smaller, more accurate, precise, tangible database than one that is stacked full of records that we may likely never use or by the time we use them they are incorrect and have to be re-researched again anyway.

Am I wrong for thinking this?

[Melissa Siobhan]

I think that no matter where the data is stored it needs to be maintained with up to date addresses and contact information so why one place and not the other?

If I had them in RE I would be able to use AddressFinder to keep their addresses up to date. If they were merged with another company we've found that keeping the old name in an alias makes searching on the old name feasible.

Why wouldn't they be imported? That seems like a huge hiccup and necessary for that volume of records (even if reduced to only 2,000-5,000 good records). I can't imagine that the data can't be converted to (or gotten in) an importable form. If I were you I wouldn't even consider the project at all if it can't be done using import.

[Peter Gulka]

if we try and import them, what about the duplicates? Our duplicate search is beyond ridiculous. I think ours sepcifically is broken in RE.

[DrewAllen]

Quote:

Originally Posted by Melissa Siobhan

Why wouldn't they be imported? That seems like a huge hiccup and necessary for that volume of records (even if reduced to only 2,000-5,000 good records). I can't imagine that the data can't be converted to (or gotten in) an importable form. If I were you I wouldn't even consider the project at all if it can't be done using import.

I'm with Melissa on this. I wouldn't consider this if there weren't a way to import the information, even if there were only 2,000 records. What format was the data delivered to you in?

Drew

[Peter Gulka]

we're gonna meet in a couple of hours and have a look at the data on the CD. I don't know what format it is in.

[coffeebug]

It's not a format I've seen before. But it is some sor