nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Opportunity records + Options paper

Mark Palfrey

Hi we are looking at mapping out how to use Opportunity records and our Philanthropic Partnership team have asked the question about a particular scenario which plays out quite often.

Basically they often pull together an "options paper" for a donor to fund multiple projects. The donor then takes a bit of time to consider the options may have a few discussions meetings to then decide on funding one or many. The question is how best to record this process in RENXT using opportunity records? Here are some thoughts:

Options 1:

Have one Opportunity record which they name “Options Paper” or something on those lines. Purpose would be set to “TBC” and then the “Ask amount” would be the total of the project asks together. Issues with this is that if you were to do a pipeline report of how many asks are out there for each project then you could not get this break down.

Option 2:

Have an Opportunity record for each option specifying the Project and the specific Ask Amount. This would solve the issue mentioned in option one regarding pipeline report of asks per project. This issue I see with this comes in the form of the linked Actions. All the conversations with the donor would be about the overall options paper so which Opportunity record would you link these actions to?

Option 3:

A more technical and complicated way of doing it - Use a single opportunity record and utilise Opportunity Custom Fields to capture individual ask amounts for each project. We use PowerBI to do our reporting so I could build these fields into our reporting requirements.

Anyone have any other solutions that could help with this? Are we barking up the wrong tree completely and maybe no opportunity record should be created until the donor makes a decision? But that doesn't seem right either. HELP!

Find more posts tagged with

Comments

Joe Moretti

@Mark Palfrey I am all about keeping things simple since non-profits already have a tendency to make things way too complicated as it is. If it was me, I would wait till the donor decides which opportunities they are interested in and then enter each of the opportunities at that time. SIMPLE is Best, we database people already gave so much against us to begin with. Simple makes reporting things much easier and easier for reporting and pipelines.

Mark Palfrey

@Joe Moretti Thank you for replying to my post. I would love to keep it simple and what you propose is actually an option that I put forwards. However it is part of the PP teams requirements to track these efforts so I am trying to find out what creative ways can be used to manage it using this type of record. The opportunity record that has been setup so far has captured the months of work that has got to this point of the options paper that has been proposed. So they have walked through the qualification, engagement and now at solicitation. With that in mind now do you have any other thoughts or solutions?

Joe Moretti

@Mark Palfrey I do not know what you mean by “opportunity record”, that is stumping me. Is this a record where you put all opportunities? I do not understand this.

Alex Wong

@Mark Palfrey
I would opt for option 3.

thinking from process perspective.. it is ONE opportunity to ask the donor for donation. that one opportunity may have multiple “option” as you stated.

However, the problem will be on your reporting. I'm not sure how you getting your opportunity record into Power BI currently, but SKY API does not have ability to get all Opportunity Custom Fields, it only have endpoint for getting Opportunity Custom Fields 1 opportunity at a time. So this works if you only have a few opportunity record to worry about, but quickly become an issue when you get into hundreds and thousands.

Now, you can of course just export from RE (manually or scheduled via RE:Queue), which will avoid the issue mentioned.

Brian Soucie

@Mark Palfrey I agree with Joe in that ‘simple is best’ but would throw in the qualifier that it should be a solution that makes your reporting as straight-forward as possible.

If it was me, I'd look at a combo of #1 and #2. I'd have the one overall ‘parent’ opportunity that would be used to record all of the actions related to the overall proposal, but I would not include the financial details. I would also then have separate ‘child’ opportunities for all of the individual requests with specific ask amounts, funds, campaigns, etc. If the donor decides to fund multiple options, you could record then stewardship activity against the relevant child record instead of the parent.

Based on the way we do reporting, the above would provide the simplest path forward with no manual manipulation of the data. The pipeline reporting would include only the child opportunities so I would also want to exclude the parent, likely with an opportunity status.

Mark Palfrey

@Brian Soucie thank you Brian that is a great idea and agree that might actually be the easiest option for this scenario we have. I think all the solutions everyone has contributed have been great and hopefully useful for others who may come across this post. I am going to do some testing on each of the solutions proposed from everyone and discuss it with our Philanthropy team next week and see which one works out best. Once we have settled on something I will report back.