Monday, October 5, 2009 - 18:03
Written by

Let's hear it for Rayogram and their hospitality to the CiviCRM community by hosting the New York City Meetup last Thursday! We accomplish so much using all of our electronic tools but there is still a kind of creativity that happens so much more efficiently in real time, face to face. One of the breakout groups at the Meetup was with persons interested in talking about CiviPledge. I left energized and excited about improving the tool that we all share. Some of the highlights of our conversation were:

  • What is the role of pledges in organizations and CiviCRM?
  • How should we handle pledge payments?
  • How should we communicate with our members about their pledge payments?

One of the persistent questions is, "What distinguishes a Pledge from a Pay-Layer Contribution or a Recurring Contribution?" We really kicked that around at the break out table and I can now clearly articulate the difference and why it's important to many of us. Pledges are distinguished from Pay-Later or Recurring Contributions by the need report and track the amount pledged before contributions are received. This can be critical data in order to decide if a project is feasible or what resources will be available for projects or ongoing work.

Examples might include:

  • Pledges to a capital campaign: do we have enough to build?
  • Pledges for next year's operating budget: do we have enough to operate?

There is a lot of common ground between these three from a software perspective, which I think is why there's been some confusion or pondering about the distinction. The code that enables recurring contributions should be shared with CiviPledge so that members can authorize recurring payment of their pledge. The same organization that has run a pledge campaign may still have a donor offer recurring contributions at some other point.

We also need to change the way that we handle contributions linked to pledges. All of the organizations at the table last Thursday would gladly accept a pledge payment of $23 even if the expected payment was $25. Rather than calculating a complete schedule of pledge payments, perhaps what we need to do is continue to relate contributions to their pledge but simply track the remaining balance, date of next expected payment (for reminders) and the amount of the next expected payment (balance divided by # of payments remaining). When pledge payments are made, especially self-service payments, this amount could be displayed in an editable field, forming a suggested rather than a fixed amount.

So if your organization could or does use pledges as part of its revenue stream, have a look at the revised CiviPledge Roadmap, then log onto the Forum and tell us how to improve it. Could you or your organization contribute developer time or funding to improve CiviPledge? Let us know about that in the Forum too!

Filed under