Sonny’s got me thinking again
Last Updated on Friday, 3 March 2006 10:53 Written by Steve Friday, 3 March 2006 10:08
Every time I hear from Sonny about Salesforce, I spend the next few hours ruminating about schemas, custom code, and how to model some process in Salesforce. This time it was his comments about prospecting gifts and how he models pledges. After a day of thinking about it, here’s how I understand the process:
- A pledge is really just a stage in the receipt of a gift. It’s when a person has decided to give but hasn’t given yet. It has a fairly high likelyhood of coming through, but not 100%, that’s for sure.
- When a gift gets to the pledge stage it can turn into money in the bank in two ways: the donor could write a single check for the whole amount, or the donor could agree to make installment payments that add up to the full amount of the pledge. Either way, the sum of the gifts should equal the original pledge amount (or close to it)>
- Either way the pledge is fulfilled, it should recurr on an annual basis. The donor should be asked for another pledge/gift a year out from the date of the received pledge
And here’s how I’d model it based on this generic process:
- Gifts and pledges are both Opportunities
- The Gift donation process has multiple stages. There is a “pledge” stage that has a probability between 50% and 80%, depending on how optimistic you are.
- If the pledge turns into one full-sum gift payment, the stage of the pledge is changed to “Closed Won”, and the payment is received. An Opportunity for the same amount (or a little more) is created for one year out with a prospecting probability. This will be a reminder to ask again in a year.
- If the donor decides to make installment payments, a custom field called “pledged amount” is populted with the Opportunity amount.
- A payment schedule is drawn up, and new Opportunities are created with close dates that correspond to the scheduled payments. These Opportunites may have a checkbox checked indicating they are pledge payments.
- At this time, an Opportunity is created a year out for the pledged amount (or a little more) with a prospecting probability. This will be a reminder to ask again in a year.
- Each payment Opportunity is identified as being tied to the original pledge Opportunity. You can’t create a Salesforce relationship between two Opportunities, but we can fake this through the use of S-Controls for creating the payments. We can effectively relate the pledge payments to the pledge.
- As a payment comes in, the existing payment Opportunity is updated to stage Closed Won. The amount of the payment is subtracted from the amount of the pledge, so that the received payment and the remaining amount on the pledge add up to the original pledge. The “pledged amount” field is untouched, keeping a historical record of the full pledged amount.
- This is repeated with each payment, drawing down on the pledge until it is $0, and the payments add up to the original pledged amount. We can’t do this in real time, because we have no access to the “save” event on the payment Opportunity. If we did, we’d just call some code that would deduct the payment from the pledge Opportunity amount. We can do this in batch, on a schedule, though. Every day, or week, all pledges and pledge payments could be reconciled in an S-Control that might take 1 minute to run.
You can see all pledges by filtering all Opportunites with Stage = pledge. You can see all pledge payments by filtering for Opportunities that have the pledge payment checkbox checked.
I think that’s it. I think it holds together. Poke holes in it, and let me know via the comments. I’d love to hear of problems you see, or ideas you have for doing it differently.
Steve,
This is smart. But Sonny’s comment on your recent post to the effect of “prospects and payments are different — but related things” has got me thinking. I think Sonny’s right — these are (in folks’ minds) different business processes that should probably be clearly differentiated in Salesforce. I’m wondering if it might indeed be smarter long-term to use Opportunities for pledges and a custom object for gifts/payments, as Sonny suggests.
Not so much because you *can’t* do it all with Opportunities, but because of the semantic (and usability) confusion that I fear might result from using one strangely-named top-level object (“Opportunities”) to cover two functions that are “top-level” in a user’s mind.
The rest of this, about using Opportunities to track and schedule the plegde payments, I love. It is so cool to see these pieces coming together.
If we were going to break gifts and pledges out into two separate objects, I would do it the other way–pledges would be a custom object, and payments would be Opportunties. Here’s why: 15,000 of the companies that use salesforce handle payments as Opportunities. Because of this overwhelming consensus, any advances to the way payments are handled, and any current and future third party services that do things like integrate with quickbooks, will expect that your payments are Opportunities. If we go down another path, that may be fine, but we run the risk of no longer riding in the powerful slipstream of the larger market. A group that uses custom objects to handle payments won’t be able to pay $500/year to get quickbooks integration. I always strive to use the product as closely to how the for-profit world uses it, to keep these kinds of options open. The challege then comes in meeting nonprofit needs while doing that–not an easy task, but manageale, I think.
That’s a really good point — which, come to think of it, you told me in person, and I promptly forgot.
Good to put it in writing, though.
I can’t believe you didn’t recall that conversation! What, do you have other things on your mind or something?
It’s a big issue for us, but a bigger one for Salesforce.com as a company/platform. They have to move their application forward while not breaking anything for their 15000 customers. Not to mention all the add on products. Since Salesforce.com is an on-demand app, they can’t release a new version and not worry about backwards compatibility. Their new versions have to work with no migration, on day one. I’m glad it’s not my problem.
Steve and Jon,
Sorry for joining this conversation so late in the game (traveling). Steve, your interoperability argument for current and future 3rd party apps is very convincing and has a lot of merit for larger orgs needing accounting integration.
As a whole, integration into third party products is problematic with how NPOs are using SFDC to track revenue. For one, there are always going to be variances to how NPOs use SFDC and out of the box integration solutions will not work (or will work poorly). Second, trying to adhere to a process meant for a commercial/corporate work flow model, does a disservice to nonprofit staff on all levels (data entry…confusing, fundraisers…not aligned) for the sake of technology integration.
I question how many smaller nonprofit would/could afford to take advantage of a integration product into QuickBooks. I think many would like to, but so far the solutions seem more trouble than they’re worth.
2cents
~S
Every client I have talked to has asked about Quickbooks integration–none have actually done it, and I don’t suspect I’ll be doing it any time soon. I think the bigger benefit of minimizing whole-cloth customizations is that as the platform improves, we get to tap into the new features that are added to standard objects.
Take outreach for example. We could do outreach events as a custom object that contacts get related to. That would give us more flexibility in naming, and would make matching a nonprofit work process a bit easier. This, in fact, is how Events are handled in the nonprofit template that Salesforce.com hands out. But you could also handle outreach with the Salesforce.com Campaign object. You can’t do things the way you would with a custom object, but a lot of events could be handled this way. In January, Salesforce.com made some killer improvements to the Campaign object. Now you can take any report of Contacts that you can generate, and in two clicks you can add all those people to an outreach event. So, if you want to invite everyone who gave in the last year to your annual party, just make the report and two clicks later they are associated with the party invite. Incredibly powerful, and I’m using it now because I stuck with the standard object.
It’s always a trade off, and it’s not always clear the best way to go. But my philosophy is to start with the business process of the nonprofit, then try to model those with 100% standard objects. If not possible, I create as few custom objects as possible.
Great points…and make me look at my own customizations and standard object configuration more closely. Thanks for the dialogue.
See you next week in Seattle.
~S
Thanks for your comments, Sonny. It’s great to get your perspective on these issues as you’ve been using Salesforce.com to handle real-world nonprofit buisiness process longer than anyone else I know! It will be great to meet face-to-face.
I am in the “leverage as much of the out-of-the-box package as possible” camp on this. After working at salesforce and implementing the tool for nonprofits for a year and a half now, I have seen many clients get carried away with solving all of their processes by creating far too many custom fields and custom objects.
The problem with custom objects lies in often not being able to create formula fields and reports that cross objects and get you the data you need. I have often started down the road of creating a custom oject for something and wind up scrapping it and building pieces out as custom fields directly within the native object so as to avoid reporting problems as well as get more out of custom formula fields.
Your discussion of pledges is a great example of this. I had originally built Pledge Payments as a custom related list on the opportunity object, only to discover that I couldn’t access the Amount field on opportunities in the caculated field I had created. The client and I decided it was best/easiest to simply build a set of custom fields on the opportunity instead, including the pledge installment #, the due date and the paid date, which allows us to then deduct the pledge payment amount from the opportunity amount to give us a remaining pledge balance.
The one thing folks will quickly discover about salesforce is that there is hardly ever one single way to implement it and the same issue may even be solved differently between different clients.
Oh…I forgot…the thing about QuickBooks integration:
We have a few clients in the process of this but there is one fairly significant problem:
The integration tools out there (eBridge and SalesCentrix) both require that the sfdc set-up be using Products on and Opportunity. This is because QuickBooks functions based on line-items, and the only line-item capability in sfdc is on Products. I have talked to SalesCenrix about this and they currently do not have anything on their road map to change the tool to take data directly from the Opportunity object into QuickBooks. You must use Products.
So this becomes redundant data entry…if you’re entering a $50 donation as an opportunity record, you then have to scroll down and re-enter it again as a Product in order for the QuickBooks integration tools to work. This means bringing Products into the nonprofit equation which is not very palatable when we’re already trying to sell a for-profit tool to these groups.
One more thing on the custom object/related list vs. custom fields on native object issue:
A few of my clients have asked me to go with custom fields on the native object because it is quicker for their data entry staff. If someone is doing a lot of data entry at one time, being able to quickly tab through fields rather than having to save the record and then go down and do another set of data entry on a related list is a big deal. They are absolutely willing to have lengthy page layouts in exchange for data entry speed.
I’ve done enough data entry in my life that I can’t argue with them on this one! It’s not as pretty and cool but it’s easier on the carpal tunnel!
Great to hear your thoughts on this Meghan–it’s kind of the hippocratic oath for consultants: first make no custom objects!
OK, not that extreme. I have some custom objects I couldn’t live without. But not many.
Thanks for the tip on quickbooks integration. I suspected it wouldn’t easily map to what we’re doing, but hadn’t had a chance to look deeply at it.
Hi everyone.
It’s been awhile since the last comment and obviously now we’d be able to find numerous hosted solutions and companies that offer Salesforce and Quickbooks solutions. To add to the list, I’d like to mention a hosted solution by Apatar which previously was best known as a desktop application for intigrating data. Now it’s making the first steps towards SaaS introducing a web solution targeted at data synchronization between Salesforce.com and QuickBooks. You may also want to take a look at it http://www.salesforce.com/appexchange/detail_overview.jsp?id=a0330000005kn33AAA. It’s rather interesting to see if it’s possible for a company to have both a successful desktop and hosted solution))