Skip to end of metadata
Comment: Migrated to Confluence 4.0
Go to start of metadata

Please comment and edit the below to help improve this draft RFP. Thanks to Michael McAndrew for preliminary comments. 

Draft request for proposals for implementing CiviCRM for Open Rights Group

Project: ORG CRM
Client: Open Rights
Issued by: Michael Holloway, Development Manager, Open Rights Group
Issue date: TBC

Introduction

The Open Rights Group (ORG) is a grassroots technology organisation which exists to protect civil liberties and consumer rights wherever they are threatened by the poor implementation and regulation of digital technology. ORG takes an evidence-based approach to its advocacy work, mixing “inside track” lobbying with grassroots engagement and targeted media work.

ORG aims to be an organisation that is sustained by the people it represents. We have grown to around 1,350 paying supporters, each of whom contribute on average £6/month to ORG's running costs. This funds two full and one part time core staff members. We also rely on funding from grant-giving bodies in order to carry out specific projects.
Goal

ORG is seeking to identify a constituent management system that achieves the requirements detailed below. We will then contract to implement the system, including migration of existing data and staff training. An ongoing relationship to enable further developments and training is also desirable.

Deliverables

  • Secure, scaleable database for personal (contact) details and payment histories.
  • Hosted on one of our own servers. Trusted external parties access via SSH with public/private keys.
  • Constituents should be able to login and edit the details we hold.
  • Import existing contact information from two sources: sqlite db and csv.
  • Support business processes
    • Exporting address and name data as CSV (for welcome packages, voting forms)
    • 'Chasing' i.e. exporting address, name and email to contact late payers.
    • Integration with Advocacy Online; maintain a 'supporter' flag and carry across new
    • Editing personal info on request (address / name change)
    • Profiles should also have a 'contact' status and capacity to add further fields as necessary.
  • Comprehend our 'payment processes' (could use some rationalisation!)
    • A supporter is someone who pays us at least £2.50 per month
    • Others include
      • Donee: made a one-off donation (we promote 'supportership' to these people with a bi-annual offer)
      • Closed: May have started paying by DD or with a fresh paypal sub. Or may have asked us to cease comms.
      • Lapsed / failed: missed a payment within the last three months
      • Lapsed long term: missed a payment longer than three months ago
      • Never paid, pending and unknown: told us they would pay but haven't started. (Shouldn't be imported.)
    • Note this distinction is important because we provide benefits to supporters as an incentive to start and continue donating. These are currently (1) information on our campaign activities; (2) discounts to events; (3) voting rights. But we aim to grow this list.
      • More info on payment processes:  some give monthly / quarterly / annually. And we receive many different amounts. Income usually paypal, standing order or direct debit. But also cash and cheque.
  • Integration with three payment sources to maintain 'paid up' flag.
    • Cooperative bank (cf CSV statements, likely using name / account details as unique identifier)
    • Paypal (cf import via API? Using email as unique identifier?).
    • Rapidata for direct debits (cf although we can configure their reports and they will include email / user ref for use as unique identifer, not available via an API).
  • Facilitate retention work by
    • Report for, at a given time, 'late' payments.
    • Simplify contact procedure by operating a mail module and templates. 
  • Facilitate supporter community growth and targets by reporting on overall number of paying supporters and donations across specified time period.

Procurement Requirements

Developer should expect to work with our volunteer sysadmins and our FreeBSD servers.

Keeping supporter data secure is more than crucial to us.

Budget

We can spend a few thousand pounds in the short term. Please structure quotes to indicate the costs of the different features and – as per our 'follow up' email – how we can build as cheap as possible. Also please project ongoing annual costs.

Labels:
None
Edit Labels

4 Comments

Hide/Show Comments

  1. Jul 05, 2010

    Matt Burkhardt

    I've always found data importing to be the most troublesome component.  Can you give more information on the quality / status of the data to be imported?  In addition, could you please note whether you are currently tracking individuals only or individuals, households and organizations and if they are marked in the files appropriately.  Can you also give the current volume / number of records of the data to be imported.

    Thanks,

    1. Jul 06, 2010

      Michael Holloway

      Thanks for the reply and the question.

      We've got <2k records to import. They're individuals only so no worries about marking in that sense. 

      I guess its easy enough to import the contact and name info. But imagine the difficulty will be importing data on how people are paying. Presumably it'll be different for each payment source (DD / SO / PP) and will need to include at the very least amount / frequency / source?

      Thanks for any more advice you can give.

  2. Jul 07, 2010

    Erik Hommel

    I agree with Matt on the import, especially if a specific import script has to be developed and the quality of the source data is not 100%. I would recommend adding priorities to your needs, based on the fact that you have a limited budget. Also, do you have any volunteers around your organization that could perform some site management actions and possibly learn some basic CiviCRM management/customization stuff? In the RFP I do not see anything that can not be done with CiviCRM, but I do see some parts which will require some customization.

    Take a step by step approach, where you do the most important stuff first, that will also allow you to build up a relationship with whatever party is going to support you and find out if it is a match.

    Succes!

    Erik

  3. Jul 07, 2010

    Michael McAndrew

    Hey there,

    Lobo and I chatted about this on IRC. Edited highlights at the bottom of this comment.

    A here is a little bit more about importing contributions and payment providers.  CiviCRM provides a framework for writing payment processors: http://drupal.demo.civicrm.org/civicrm/admin/paymentProcessor?reset=1.&nbsp; The advantage of writing an integration for a payment processor, esp. for direct debit, is that you would be able to take advantage of CiviCRM's ability to automatically ask for / process recurring payments behind the scenes and to deal with payment frequency.

    AFAIK contribution imports isn't able to handle recurring payments in a very sophisticated way

    There are of course some things you would have to import manually (probably in batch for SO via http://drupal.demo.civicrm.org/civicrm/contribute/import&reset=1 or individually for cheques cash http://drupal.demo.civicrm.org/civicrm/contribute/add&reset=1&action=add&context=standalone) because there isn't the possiblity of employing an API.

    Civi makes it easy to an extent - have a look at the contribution import - you can specify things like 'payment instrument' (DD, cash) but it might involve manipulation of the CSV before importing (not very elegant), and payment frequency would be importable as a custom field, but employing that custom field in your workflow would require extra customisation.

    There are a few UK orgs that are requesting DD integration and we have a code sprint coming up in October.  We could focus on DD integration at that sprint.

    Here's the transcipt of the conversation:

    [18:05] michaelmcandrew: dlobo - have been talking to ORG about their requirements (ORG ~= UK EFF http://en.wikipedia.org/wiki/Open_Rights_Group)
    [18:05] c-c-m left the chat room. (Ping timeout: 248 seconds)
    [18:06] michaelmcandrew: i encouraged them to post their requirements on forum and wiki for some community feedback in case you have a mo to look and see what you think ... http://forum.civicrm.org/index.php/topic,14469.0.html
    [18:07] dlobo: michaelmcandrew: cool, if u were not aware EFF is also looking at civi
    [18:07] Geddeth joined the chat room.
    [18:08] dlobo: wow, on our wiki
    [18:08] colinsagan joined the chat room.
    [18:08] michaelmcandrew: yeah - i think i might have been   i would really like them to take on Civi and I think that to make it work for them they need to develop a direct debit payment provider
    [18:10] dlobo: seems like their budget is not very high for what they want?
    [18:10] dlobo: (depending on how few is few)
    [18:10] michaelmcandrew: yeah - on ur wiki - openness is the way to go  i have given them a fair amount of advice but i thought 'community' could help also because of the small budget
    [18:11] michaelmcandrew: yes - i agree that it might not be enough (and am wary of taking on project that is under-funded) but thought that a discussion would be the best way to establish if this will work
    [18:12] c-c-m joined the chat room.
    [18:13] dlobo: integrating different systems, just takes a lot of time and energy, IMO
    [18:13] dlobo: (and a lot of hours)
    [18:13] kthomas_vh joined the chat room.
    [18:14] michaelmcandrew: i agree, and ultimatley often not worth it
    [18:14] michaelmcandrew: if there is a better alternative
    [18:14] michaelmcandrew: e.g. developing a direct debit payment processor
    [18:15] michaelmcandrew: which is what i have been encouraging them to do - thought it might be good for them to discuss this in the open / hear some alternative views
    [18:15] kwixson joined the chat room.
    [18:15] michaelmcandrew: there are a few other UK orgs that would be happy to collaborate around DD payment processor, i think, which is probably the right approach IMO
    [18:17] kthomas_vh left the chat room. (Max SendQ exceeded)
    [18:18] kthomas_vh joined the chat room.
    [18:20] You left the chat by being disconnected from the server.
    [18:21] You rejoined the room.
    [18:23] dlobo: michaelmcandrew: main issue is do any to the direct debit folks have an API
    [18:23] dlobo: both the german and rapiddata dont seem to have a nice clean API
    [18:24] michaelmcandrew: some of them do, yes, but like you say, rapidata don't.  So the options are to switch provider (which all orgs I talk to aren't keen on doing, or possible talk to rapidata about providing an api
    [18:24] michaelmcandrew: orgs don't like switching provider because of the admin overhead
    [18:25] michaelmcandrew: but because all providers use the DD standard, it shouldn't be too hard to switch (at least it could be done invisibly for the client)
    [18:25] michaelmcandrew: *the end user)


Creative Commons License
Except where otherwise noted, content on this site is licensed under a Creative Commons Attribution-Share Alike 3.0 United States Licence.