CiviCRM Community Forums (archive)

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

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.

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.

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

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

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

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? 

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.