IoF Tech Group Conference 2017 & FPS Event

A quick post to say thank you to all the attendees and sponsors for this year’s IoF Tech Conference. We had some excellent speakers and really engaged attendees. The feedback we’ve received has been majorly positive.

The group is now putting on a very interesting event in June; the first opportunity to talk technical details about the FPS with the implementing vendor. It’s on 15th June at 6 pm is with Daisy Houghton of the Fundraising Regulator and Nicky Watson of Syrenis, the company implementing the FPS system.
You can book your tickets on Eventbrite

Space is limited to 100 places, tops, so do book early if you want to be sure of a place. We’ll be providing some light refreshments too. See you there.

I don’t know you people


This post will focus on what needs to be considered when designing a solution for managing GDPR compliant communications and consent in a CRM system. No specific CRM system is in mind here, each environment will have it’s own requirements but the main design points will be common across most CRMs.

I’m not going to go into detail on GDPR but see here and here for some background info. Suffice to say that most CRM systems in place at NFPs will need some updating to store the additional information and manage the new complexities inherent in the stricter data protection regulation.

There are three general areas of a CRM that will need updating to manage GDPR compliant consent and rules; Contacts, Cases and Consent/Comms Preferences.


There shouldn’t be major changes needed to Contacts, just adding security to specific information for compliance (some of this is already required by the existing DPA which I’m sure everyone is fully compliant with….)

  • Any sensitive data must be protected and only visible to users who need to see it. In general, organisations require stronger grounds to process sensitive personal data than they require to process “regular” personal data. This could be achieved with field level security or similar on the relevant fields. Sensitive personal data are personal data, revealing racial or ethnic origin, political opinions, religious or philosophical beliefs, trade-union membership; data concerning health or sex life and sexual orientation; genetic data or biometric data.
  • Clearly identify Contacts that are under 16 years of age as they require additional consent from their parents. 16 is the current parental consent age in the GDPR. However it’s highly likely that the parental consent age for digital communications will be lowered to 13 in the UK to match current regulations. Either way the Contact record must clearly flag children and ensure that parental consent information is presented when needed.
  • The Contact record should show the first consent information that generated the record. This isn’t required specifically by any regulation but it would be helpful to quickly see what the first point of communication was or the source of the Contact, particularly if the Contact came in from an external source.


The GDPR creates some new rights for individuals and strengthens some of the rights that currently exist under the DPA. Therefore the CRM Case system should be updated to cater for the new kinds of requests that supporters can make. My suggested new Case types are:

  • Rectification
  • Erasure
  • Restrict processing
  • Access/data request
  • Objection

The Case record will need to store the details of the request and the actions taken, which should be standard functionality.

Contact Consent/Comms Preferences

Finally the main part of the design. There will need to be a table/entity/record that stores consent information received from or about a Contact. There may be an existing data structure in place, e.g. Communication Preferences, so there will need to be a decision whether to update the existing structure or create a new one. The standard “Allow/Do Not Allow” flags on communication channels in most CRMs will not be sufficient or compliant.

The key parts to recording consent will be:

  • Source of the consent (e.g. staff, external agency, etc.)
  • Time & date the consent was received
  • What the consent was given for or not for
  • How was the consent captured (phone, email, in person, etc.)
  • What language was used in the consent statement/fair processing/data protection statement

The last point is important. You will need to be able to tell what language was used when the consent was captured. For email or post communications you could link the consent record to a template or the specific example of the communication. For phone or in person collection you’ll need a way to store the statements that would have been used at the time the consent was captured.

Consent under GDPR can now cover data processing, so you will need to get consent from supporters for wealth screening and similar processes in addition to the “regular” consent needed for communications.

There is no specification in the regulations to say whether you’ll need to manage consent as “opt-in” or “opt-out”. Either way can work so the system design will be driven by the business decision on that front.

There will need to be a relationship between a consent record and a secondary Contact in order to manage parental consent. As mentioned above additional parental consent will have to be stored for children.

Consent refresh

It is highly likely the most difficult part about designing a solution to manage GDPR consent will be bringing your existing data up to compliance. There is a lot of supporter information in CRM systems across the sector that doesn’t have the required level of detail. You’ll have to decide on how you want to refresh or discard those records so care will be needed when creating the design to make the upgrade/migration as easy as possible.

For advice or further information about designing a consent management system in CRM or on managing a supporter consent refresh please get in touch via the contact form or email me.

And finally,

In related fun check out the webcast of the ICO Fundraising and Regulatory Compliance Conference on Tuesday Feb 21st. The event venue reached capacity very quickly due to “high demand”, which is unsurprising. Hopefully the webcast will cover a lot of the conference, I’d expect it to be well attended.

Also, Saturday the 28th Jan is Data Protection Day, I’m not sure how to best celebrate Data Protection Day, maybe an unbreakable piñata with contact info inside? Any ideas on how to best celebrate this important holiday please let me know.

The FPS is also coming. I’ll have a post for dealing with that, once we get any useful technical information on the service.

As always comments, questions and requests are always welcome

The Ideal Condition

This blog will be focusing more on the design of CRM system solutions than on project management (though there will some of that stuff in future). With that said let’s start at the best place for CRM design; the end.

When a CRM project kicks off and all you have are the initial requirements and expectations the first thing to do is to start at the end; think about what the ideal system would look like when it’s all over. The tender documents and project initiation will have some of the info but what you need to think of is more generally what kind of CRM system you think would be ideal. For example would it be a highly bespoke system? Would it be primarily supported by the in-house team or by a vendor? Would it have a high level of automation? Which team(s) will be using it most? Will there be lots of forms for different teams? etc. The goal here is not to get definitive answers to these questions but rather to set up your thinking for the next step in the process; the design kick-off meeting.

As early as possible schedule a design kick-off meeting with the project principles and discuss what the goals for the system should be. This shouldn’t include discussions about project time, resources or costs. Rather it’s a high level discussion about how the design process will work and what the overarching goals for the system are. Topics to discuss are:

  • What can be supported by the CRM team post-live (JavaScript, reporting, customisation, etc.)? It is important to know what the CRM team can support so you don’t design a system that they cannot maintain.
  • Should core functionality be used wherever possible or create custom solutions? This is a tricky question to answer at the start of a project but generally you want to get agreement on whether to keep with what comes “out of the box” as much as possible and change business processes to fit or the reverse; to create custom solutions in CRM to fit existing business processes. Every CRM project will have a mix of each but at this early stage if you can get a preference on which way to go it will help guide the later design work.
  • Should the CRM try to automate business processes where possible? Or should the goal be to have simple processes and forms that the users can manually use?
  • Which people & teams will be the primary users of the CRM? If there is a conflict later about resources or design which group should get priority?
  • Who will sit on the design authority group? This is critical, the design authority will be responsible for reviewing and approving the work and any issues encountered. The group must include the CRM manager or primary user who will be responsible for the system post live. The design authority should not be made up of only consultants, vendors or temporary project team members.
  • Finally, what would success look like? In a general way what would the project team consider a successful CRM to be (other than on time and cost!)

After the discussion create a design briefing document that formalises what was discussed and agreed. The document shouldn’t be too long winded, you aren’t trying to create a technical design here (also it would be far too early for that!). It is also not a straitjacket for the later design process, the decisions made on the discussion topics are there to inform the rest of the project. They are to be the best intentions and goals, it is very likely that some of them will be broken as the project progresses. One certainty about a CRM project is that things change. The ideals and goals gathered at the start may not all be relevant by the end. The design brief is intended to set realistic initial expectations for the design process and as a reference point for when the actual work starts. It will also serve to formalise the review and approval process with the design authority group.

The purpose of this exercise is to get an idea of how the CRM should go before you get far into the project and the opportunity for foresight disappears. This should make the design process easier and give some structure and insight for when conflicts or resource constraints occur. Travelling is much easier when you have an idea where you are going.



Page 1 of 41234



Phone: (+44) 074 1215 7299