creating a fundraising pipeline / donor prospecting

[Michael McAndrew]

Hello folks,

This is an initial 'how would you do this in civicrm?' type post, which I'm making because I'm interested to know if others have been here before and if people have ideas suggestions on how this could be approached.  I did ask this at the fundraisers focus group at the woolman sprint, to see if people had much experience in this, and the answer from a few was along the lines of "we've thought about it / would like to do it but don't have any experience with it".  But hey, that was only 20 people, and also, I do remember hearing that PTP were doing something that sounds kind of similar using survey, but anyway...

I think this might point to the fact that although CiviCRM caters well for online/mass fundraising, it doesn't have so much out of the box for institutional larger fundraising endeavours (a quick google of raisers edge pipeline bought up a few results including a book on google, and not suprisingly salesforce pipeline bought up a fair amount).

Basically, what we want to do is add funders to CiviCRM and track opportunities with these funders.  The funders will move through the fundraising 'pipeline' going from level 5 to level 1 in a way that is somewhat similar to sales and leads, I presume.

We want to do a couple of things:

1) Track general research on funders
2) Track opportunities with funders - who is involved with the opportunity, which opportunities are hot or not, what stage the opportunity is at, and what the next moves are which each opportunity.
3) An organisational wide forecast on the amount of money that is in the pipeline broken down by fundraiser, income type, etc.

1) and 2) seem reasonably straightforward.  We can model 1) with different contact sub types and 2) with cases and case custom data.

At first I was thinking that we should do 3) with contributions but on reflection, that doesn't seem like the right approach for the following reasons.

Forecasting is different from accounting. One is predicting how much money will come in and the other is accounting for what did actually come in. This organisation wants to do forecasting by quarter.  Trying to turn quarterly estimates into actual bits of money that have come seems like it would be tricky.  I have a limited amount of financial knowledge but in the accounts packages that I have seen forecasting is treated separately from accounting which seems to back that up.

In this instance, we want to record how much we forecast to receive in each quarter broken down into various programmes.

Lets say we have 10 programmes and 12 quarters (for the next three years) that is 120 boxes to fill in.

That presents some interesting questions for both the display and reporting on the data.  Do we create 120 custom data fields? or maybe a new forecast entity which we attach to case and add fields like quarter and programme to?

It probably wouldn't be too hard to create a CiviReport that was built of either of these two.  I wonder what the best way of injecting this data to the case is? PageRun and PostProcess hooks?

OK - this question seems like it is rapidly outgrowing a single forum post. I'm interested to hear people's thoughts at all levels.

Thanks,
Michael

[Michael McAndrew]

so it seems like not many people have done this yet.  We are going ahead using a case type.  Happy to let people know how it went when the time comes.  Might do a presentation / blog post.

Michael

[Owen]

We're close to trying this, in a similar "level" base, we need to define what those levels are though.

These are all stages but one does not necessarily follow another

Expressed an interest
Donated
Volunteered
Regular giver
Organised event
etc...

I was going to use CiviCase, but need to think a bit longer about how to define them.

Hadn't considered forecasting from the pipeline, interesting idea.

[Michael McAndrew]

Hey Owen,

Thanks for the reply.  This NGO is London based so I'd be happy to share with you what we come up with and pick your brains for your good ideas as well

Michael

[FadeOUT]

Interesting stuff, that's not dissimilar to the kind of thing I'm trying to put together (Also in UK, BTW). Most of our donated income is from grant-making trusts, many of whom have regular windows of opportunity for applications for funding, so it's a matter of going through the process with each Trust for funding that we require. We've broken the process down into quite a few distinct stages - I've just got to get the system together to effectively model it all.

The tricky part is that they want things like total funding for a given project to be totaled up regularly and (this is where it really seems to be stretching the capabilities of CiviCRM) tracking a tally of spending against a particular project code.

[Owen]

Michael,

Sounds good, feel free to email me about it :obowden@beatingbloodcancers.org.uk or see you at CiviCon or

FadeOUT,

We've not used CiviCase yet, the first case we'll put together though is for the grant application process, we're just getting the Grants Officer here to put together his workflow.

[Michael McAndrew]

Maybe this is something we should get together to talk about at CiviCon.  Not sure quite if this is a session, put potentially / definitley a BOF.

Michael

[Owen]

Sounds good lets BOF (or should that be flock?)

[Michael McAndrew]

cool - i've created this session: http://london2012.civicrm.org/sessions/fundraising-pipelines-civicrm

[FadeOUT]

This sounds like an interesting discussion... What's a BOF??

[Owen]

BoF #
Birds of a Feather. An informal discussion group. Unlike special interest groups or working groups, BoFs are informal and often formed in an ad-hoc manner. BoF meetings are common adjuncts to planned "sessions" at Drupal Camps and at Drupalcons

http://drupal.org/glossary#bof

[FadeOUT]

Ah..! Thanks 

[Michael McAndrew]

The tricky part is that they want things like total funding for a given project to be totaled up regularly and (this is where it really seems to be stretching the capabilities of CiviCRM) tracking a tally of spending against a particular project code.

That is definitely a requirement these guys have as well, although I think that for this first stage, we might draw the line at when the opportunity is successful - just to keep the scope limited.

I'm wondering what kind of prep we should do for this BOF - to make sure we get the most out of it, etc. We are at the implementation stage and by CiviCon we should have a first draft ready to go which we could demo.  I might also be able to get the client along.

I have a few google docs that we are using to define and develop this.  I could potentially make those public or transfer our learnings onto a wiki page.

How are you guys approaching this? any ideas on how we could collaborate? 

[FadeOUT]

I'm at that awkward asking people what they want / figuring out if CiviCRM can do it without making massive, time-consuming changes / figuring out how to get CiviCRM to do what I want stage. I think that the bulk of the information storing capabilities necessary are there in CiviCRM for the taking, it's just a matter of throwing together some XML, adding some custom fields and tidying things up with some custom templates. Getting running totals out, etc, is much more of an issue...

Which makes me think that perhaps there's a requirement for a more generalised "CiviProject" module for managing spending of money on larger projects (among other things). I'm sure there are enough different organisations who could use a simple spend management tool. I must check CiviGrant to see if it could usefully be adapted for internal spending (I have no idea at the moment) as an alternative to an entire new module.

As for collaboration - as long as we keep an eye on this thread, perhaps just chucking back and forth a few of these ideas is a good start?

[Owen]

At LLR we've got two distinct case frameworks that I'm thinking about :

1) Grant/funder application

2) Individual fundraiser walk up

1 is easier than 2 to build in Civi for me, as our Grants officer has supplied me with his procedure for applications, should be fairly easy to XML it. 2 requires more buy in and defining from a larger section of the organisation.