Handling multi-year proposals in Convio’s Common Ground

In the process of converting over from Raiser’s Edge to Common Ground, we’re having to make certain configuration decisions that will allow the new system to match our processes and reporting requirements. Periodically, I’ll share some of those decisions and some of the background behind them, plus any interesting concepts they may expose.

Multi-year grants and donations are key weapons in the battle for renewable and reliable revenue for a non-profit. They provide stability to future budget projections, show commitment by funders to the ongoing future operations of the organization and are generally a good thing. As with all major gifts or grants, however, these opportunities require a cultivation cycle and development teams want to be able to track the activities and progress of a proposal over time.

When we record multi-year opportunities, we want to associate the cashflows with the annual campaign in which we expect to receive the revenue, and a significant part of our revenue reporting is based around this. So if I have a $3 million grant which will be paid out over 3 successive years, I need to be able to record the revenue across 3 different campaigns. Additionally, prior to the grant being won, we discount the amount of the proposal based on the stage that it’s in (we use a subset of the default Stage values), and report off of the Expected Amount field. As the proposal moves through the cultivation cycle, we change the stage and expect the revenue reporting to reflect the updated stage. Additionally, we want to associate each cashflow with the appropriate gift designations and solicitors in order to credit them properly.

All of this seems straightforward enough, but as we started to configure Salesforce and Common Ground, we ran into a bit of a road-block:  Common Ground (or Salesforce itself for that matter) doesn’t readily support multiyear opportunities in a fashion which would allow us to update the proposal record as a single entity, yet report on our cashflows in the fiscal year (campaigns) in which we need to. I should note that Raiser’s Edge doesn’t do a particularly good job of dealing with this issue, but we had a solution in place that worked for reporting and used the native RE proposal functionality for managing the actual data.

We looked at a couple of options before settling on our current plan, with an ideal solution being simple for end-users to understand and with a minimum of customization:

  1. Record all multi-year donations as Pledges and use the native Common Ground Pledge and Pledge Installment functionality to create our child opportunities.  Common Ground has a pretty cool add-in (build in Flash/Flex)  to set up future pledge payments, and this would satisfy our requirement to manage dates and commentary on one record (the Pledge) and report on revenue on multiple records (the Pledge Installments, which are Opportunity records).  Unfortunately, there would still be no way to record changes on the Pledge record and have those propagate to the Installments, meaning that staff would need to update both the Pledge and Installment records, and would have to know when to use the Pledge tab vs  the Opportunity tab when entering data.  Additionally, it would add to user confusion with real pledges.
  2. Create a new custom object (Proposal) which would capture the summary type information and commentary.  This would eliminate some of the confusion about where to record proposals, but would lose the functionality of automatically creating the future cashflows (users would need to create the Opportunity records manually) and would still have the issue of requiring multiple updates to different records (which is almost guaranteed to result in some records being missed).  Additionally, extra fields would need to be created to support the grants management process (which already exist on the Opportunity record with the installation of Common Ground).
  3. Use the native Opportunity creation process to create each individual cashflow record and update their data as necessary.  Although this option would use the most native functionality and would have the least customization, it was probably the least palatable option, as we’d lose much of the proposal management benefit that we’re looking to achieve with our migration.

There were certainly other alternatives available, most being variations on the options outlined above. As we looked at the options, we had to weigh making procedures simple for our end-users against minimizing custom functionality and, based on our internal capabilities, have agreed that we’re willing to take on some additional customization in the hope of improving user adoption of the system when we go live.

In assessing our choices, we kept coming back to the need to manage the proposal as a single entity, yet have the cashflow opportunities related in some fashion to the proposal (and ideally have changes in the parent reflected on the child(ren).  In Salesforce.com terms, this would be reflected as a lookup relationship between the parent and child. 

This relationship already exists between the Pledge object and the Opportunity, and would be easy to implement between the Opportunity and another custom object (such as a Proposal object) , so could easily be accomodated for options 1 and 2 above.  Option 3 would seem to be somewhat more complicated, as it requires a lookup to another opportunity (called a recursive relationship in data modeling terms). In traditional database development,  working with recursive relationships can be somewhat painful, but in Salesforce.com, they are no different than any other lookup.  You simply define the field type, pick the object you’re looking up, define the relationship name and how it appears as related lists, and you’re done.  Creating these relationships is an important first step, as it allows an easy way for an end-user to gain access to the child records from the parent or to the parent from one of the children.

Given that we can easily create the recursive relationship between Opportunities, option 3 moved to the front of the queue when it came to evaluating ease of use for our users.  They would be able to always go to the Donations tab (the Opportunities tab is renamed to Donations by Common Ground) for any proposal or donation with the exception of Pledges (which is as intended by Convio).  They would still have to create each of the cashflow Opportunities and assign them to the correct Campaigns, but through the magic of the Salesforce Clone option, they can easily create the year 1 option and then clone it for each subsequent year and maintain the donor contact relationships and designations through the cloning process.  The only value that needs to be changed between the first and any subsequent records is the Campaign, which simplifies the process significantly.

Finally, we want to be able to to update certain fields on the the child opportunity records when the parent is updated (particularly stage name and probability).  Doing this required some simple code, but given that we already have the relationship between the parent and child records in place, doing an update is very easy.  This update could easily be written as a trigger, but we’ve decided to implement it initially as Apex code that will be called by the end user from a button on the Opportunity record.  If we find that we’ve got issues down the line with users not doing the update, we could either change the code to a trigger, or set up a scheduled batch to do the update on a regular basis.  Additionally, we can also look into a process to create the child cashflow opportunities in a more automated fashion (a simple VisualForce page would accomplish the job), but as mentioned above, we’re trying to find the balance between simplicity/maintainability and ease of use.

Some key points to be drawn from this? 

  1. Flexibility of the Salesforce model allows us to adapt the system to our needs using one of a number of approaches.
  2. We can adjust our solutions over time to respond to usage patterns or changing requirements
  3. Maintain the balance between over-automating and ease of use, particularly when launching something new – too much automation puts you and your technical team as a bottleneck in the event that things change, whereas users will tell you where their pain points are.

How are your organizations handling multi-year opportunities?  I’d love to hear what you’ve come up with.

About these ads

5 Responses to Handling multi-year proposals in Convio’s Common Ground

  1. Judi Sohn says:

    Great post as always, Wil.

    We faced similar challenges with our Common Ground implementation.

    We ended up going with Option 1. We haven’t found it too challenging to keep installments in sync with the parent. Campaigns are assigned based on original ask, not when the funds are distributed so the original campaign is fine on the installments.

    Also for us, there is little confusion between “real” pledges and when we are using the Pledge object to handle deferred/multi-year payment. Pledges are nearly exclusively from Households, while multi-year payments are exclusively from Organization accounts. We may have to re-evaluate if the situation changes, but it’s working for now. We also run into a situation where an organization will commit to funding in the last months of a fiscal year, but payment is not received until the following year. So even if there is a single installment, we’ll use the Pledge object in order to book the revenue in the correct fiscal year and then separate from the payment on that gift as it comes in the following year.

    Another step we’ve taken is to use the “Received as Pledge” stage on the opportunity for every pledge (every pledge must have a related opportunity parent, as well as the children opportunity installments) and to use Close Amount to indicate funds as they are pledged, and Amount to indicate funds as they are received. That makes it much easier to separate cash from revenue in our reporting.

    • Will says:

      Judi, that’s helpful to know – I thought about the Received as Pledge step, but felt that it added some extra steps that didn’t actually add much value. Good distinction between individuals and orgs, though we do have some larger individual donors, so things get a little muddled. Given that we’re still in the middle of implementing, we still have the opportunity to shift around if we need to.

      Thanks fro the feedback!

      • Judi Sohn says:

        It’s definitely a bit cumbersome. Thankfully, this is not as common for us as single one-time gifts are. Folks have to take the time to configure the pledge correctly, but then it makes booking the income against the payments easier down the line. I also created ScreenSteps documents to step the users who need this info through the process.

        The value in “Received as Pledge” is that we can have a single matrix report on the Opportunity object that gives us a complete picture of funding commitments for the year, without having to bring in the Pledge object as well. I simply filter out the “Pledge Installment” record type (or visa versa) so I’m not seeing both the original pledge and its payment(s) in the same report.

  2. Hmmm. I have a similar situation, but we’re the non-profit starter pack instead of Common Ground. My client’s sole source of funding is grants and many are multi-year. There was no reason to use campaigns, so I pressed the native Opportunity Product and revenue schedule functionality into service. We have various “grant designation” products, and each product may have multiple review schedule entries. We use a “Opportunities, Products and Schedules” report type to track funding commitments from year to year. So far it’s working pretty well.

  3. I meant to say above that “each product may have multiple REVENUE schedule entries.”

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Follow

Get every new post delivered to your Inbox.

Join 1,071 other followers

%d bloggers like this: