ActionAid UK · Web viewActionAid UK is the largest funder of the ActionAid Federation, and as such plays a key role in the federation’s global fundraising. ActionAid UK is dependent

New CRM system

Requirements document

September 2020

Version 1.0

Commercial in confidence: This document is confidential and is intended solely for the use and information of the organisation to whom it was originally issued.

ActionAid UK – New CRM system – Requirements document September 2020

Document historyVersion Date Author Revision

1.0 4.9.20 Li Ming Chin

Approvals

This document requires the following approvals:

Name Title Signature Date of issue Version

Distribution

This document has been distributed to:

Name Title Date of issue Version

Contents


1. Introduction...................................................................................................................................................................................................................... 1

2. Purpose of Requirements Document................................................................................................................................................................................2

3. Background....................................................................................................................................................................................................................... 3

4. Summary of Project Goals................................................................................................................................................................................................ 6

5. Deliverables...................................................................................................................................................................................................................... 7

6. Functional Requirements................................................................................................................................................................................................12

Functional Req 1 : Support Record & Relationship Management....................................................................................................................................................14Functional Req 2 : Communication Management............................................................................................................................................................................21Functional Req 3 : Child Sponsorship............................................................................................................................................................................................... 23Functional Req 4 : Philanthropy and Partnership.............................................................................................................................................................................33Functional Req 5 : Events and Community.......................................................................................................................................................................................38Functional Req 6 : Legacy.................................................................................................................................................................................................................42Functional Req 7 : Campaigning activity...........................................................................................................................................................................................47Functional Req 8 : Trade Products................................................................................................................................................................................................... 49Functional Req 9 : Payroll Giving......................................................................................................................................................................................................52Functional Req 10 : SMS Giving..........................................................................................................................................................................................................53Functional Req 11 : Lottery................................................................................................................................................................................................................ 53Functional Req 12 : Inventory System................................................................................................................................................................................................55Functional Req 13 : Supporter Contact..............................................................................................................................................................................................57Functional Req 14 : Digital Marketing................................................................................................................................................................................................ 59Functional Req 15 : Source/Product Management............................................................................................................................................................................60Functional Req 16 : Reports & Triggered Workflows.........................................................................................................................................................................62Functional Req 17 : Finance............................................................................................................................................................................................................... 63Functional Req 18 : Data Protection...................................................................................................................................................................................................69Functional Req 19 : AA UK Website and Payment Platform Integration............................................................................................................................................71

7. IT & General Requirements............................................................................................................................................................................................73

Appendix A – Context Diagrams & Process Maps..............................................................................................................................................................81

Appendix B – Elaborations & Examples...........................................................................................................................................................................100

Appendix C – Data Warehouse........................................................................................................................................................................................112


Appendix D – Glossary..................................................................................................................................................................................................... 118


1. IntroductionThis Requirements document sets out the key requirements for a new CRM system for ActionAid UK.

The document is set out under the following main headings:

Purpose of the document, which explains the reasons for the document and how it will be used during the selection and implementation of the new

CRM system

Background, which provides an overview of ActionAid UK’s work and the context for the new system

Summary of project goals, which presents the overall aims for the project including criteria against which suppliers and systems will be assessed

Deliverables, which lists the project deliverables and responsibilities

Requirements:

o Functional requirements, which describes the key processes and other requirements that the new system needs to support

o IT & General requirements

The document is supported by appendices including:

Key process flowcharts

Example documents and reports

All information contained in this document is confidential to ActionAid UK.

Page 1


2. Purpose of Requirements DocumentThe requirements document will be used throughout the project:

During the selection phase: to record the processes and high-level requirements; to analyse the ability of software systems to support the processes;

to prioritise the functionality requirements (considering factors such as priority, cost and time to implement)

During the implementation phase(s): to monitor delivery of new processes and software to support the processes; to record any changes in

requirements; to phase the implementation based on agreed priority for each of the functionality requirements.

During programme review phases to assess whether our requirements have been adequately met

The purpose of the document is to:

Capture requirements

Indicate criticality to project success

Manage changes to requirements

Provide a reference point for traceability.

Page 2


3. BackgroundActionAid UK is the largest funder of the ActionAid Federation, and as such plays a key role in the federation’s global fundraising. ActionAid UK is dependent on systems and technology to deliver the key strategic objectives and the implementation partner will play a key role in supporting our ambitions laid out in our 5-year strategy “Together, with women and girls”.

We are currently running two supporter databases; a bespoke Oracle based system called Infobase, that has been developed in-house over the last 22 years, and Raiser’s Edge, used for relationship management by our Major Donor, Trusts and Corporate teams in our Partnerships & Philanthropy (P&P) department.

We have committed to a new CRM Programme to integrate our disparate systems and to ensure that we have robust Customer Relationship Management (CRM) and Business Intelligence (BI) systems and tools in place. This will allow us to be flexible, innovative, provide exceptional supporter experience, relationship management and provide insight from our data to ensure that we are evidence led and using this to drive our fundraising and marketing programmes.

Our ActionAid UK Strategy 2018 – 2022 and The Resource Mobilisation Strategy commits to embedding a ‘Digital First’ culture into all voluntary fundraising activities. In order to achieve this, we must invest and update our CRM and BI systems and tools. This programme is laying the groundwork for growth to enable this to happen in the next strategy period.

A core part of our CRM programme has been the development of a Data Warehouse. This will provide us with a single source of truth to improve our reporting and decision-making capabilities, and critically to aid in data migration to our new CRM solution. Our Data Warehouse has been built in PostgreSQL and is running on a Linux server.

The CRM programme is being overseen by a CRM steering committee, and led by CRM Programme Manager, with a Senior Responsible Owner representing ActionAid internally. Two CRM Workstream Manager roles have been created to cover Solution Development, and Change, Communications and Engagement respectively. The Workstream Manager – Solution Development will also directly manage the relationship with our implementation partner. The development of our Data Warehouse sits alongside the CRM solution in our Development workstream under this same Workstream Manager.

Page 3

https://www.actionaid.org.uk/sites/default/files/actionaid_uk_strategy_2017.pdf


Child Sponsorship is AAUK’s single biggest source of income at present, and this is also true for the ActionAid federation as a whole. This is a complex area for any CRM to manage, so needs special attention. Additionally, ActionAid International are developing a new global child sponsorship database. The timing of this is imprecise, but testing of data flows and how users can interact between the two systems will be important.

Project Scope

Activities that are in scope for this programme include:

• Contact relationship management with individuals, financial supporters, other organisations, influencers, and suppliers.

• Supporter management

• Production of reports and analysis of data

• Event management

• Management information

• Campaign and appeal management

• Communications and mailings, including bulk mailings to supporters

• Legacy administration

• Marketing automation

• Digital integration

• Lottery management

• Finance and Income processing

• Child Sponsorship commitment management

• Fulfilment

Page 4


Additionally in scope is a change management process to support staff through this programme, and systems change required to deliver functionality and reporting relating to the above activities. Integration with 3 rd party systems that we use for our website, Data Warehouse, Child Sponsorship database, taking payments, contact centre operations, engaging in campaigns, and management of our finances is also in scope, but any unrelated development of those systems isn’t.

Page 5


4. Summary of Project Goals

Programme Objectives

Deliver a new platform CRM solution to replace our existing two databases (Infobase and Raiser’s Edge) and to integrate with our other systems including our Data Warehouse, our finance system (Sun), our international Child Sponsorship database and our website.

The main – tangible – outcomes will be to: Appoint our chosen CRM implementation partner in Q4 2020 Deliver against our detailed implementation plan, overall timings and budget Deliver against our technical requirements specification Successfully complete the migration of data from our data warehouse to the new system Deliver a programme of cultural change that brings users and our wider staff body along with us and allows us to realise the potential of a new

CRM platform Have trained all users and arranged a programme of ongoing training Have in place suitable arrangements for post-implementation maintenance and support

Success criteria

Our success criteria are to have delivered on our programme delivery objectives, plus the key programme benefits that we mapped out in our Vision workshop in June 2020. These are:

Improved income generation opportunities Improved supporter experience More agile in supporting new product development More engaged audiences Improved evidence base/test and learn decision making Improved staff experience Assured compliance

Page 6


5. DeliverablesThe table is to show the key expected deliverables during the lifecycle of the project and to show that the organisation recognises that the project will be carried out in partnership with the chosen supplier. Some of the deliverables will be directly attributable to one of the parties, but some will require their joint input and responsibility.

ID Deliverable Additional Information Provided by

1. Business Analysis and Requirements Definition

1.1 Documented current and future processes with suggestions for future improvements.

ActionAid UK

1.2 Detailed Design (Detailed journey maps, report definitions, integration specifications, external portal design etc.).

Supplier is expected to further the definition work started through interviews, workshops etc.

The supplier with substantive input from ActionAid UK

1.3 Change Management (implementation of new business processes, training, impact and change by office/central team, communications, feedback loops).

Supplier is expected to contribute to and be aware of the associated culture change.

The ActionAid UK Workstream Manager – Change, Communications and Engagement with support from the supplier.

2. Development

2.1 Initial system development, data import, testing followed by iterative build, integration and bespoke development.

ActionAid UK has proposed a 12-18 month implementation to take into account revisions to processes and other change management activities.

The supplier with feedback from ActionAid UK

Page 7



2.2 User Acceptance Testing (UAT), provision of data, all end client provisioning.

ActionAid UK will provide and format all data and content.

The ActionAid UK Workstream Manager – Change, Communications and Engagement with input from the supplier.

2.3 Fully documented set of API endpoints to meet integration requirements with AA website and third party payment platforms.

Full AA website and third party payment platforms integration requirements will be defined separately with the supplier.

The supplier (with support from the ActionAid UK Project team).

3. Data

3.1 Data profiling and data architecture. The source data will reside in our data warehouse

The ActionAid UK Workstream Manager - Development with substantive input from AAUK Head of Data and the supplier.

3.2 Data migration. Import of data from the current systems.

Supplier with data provided by ActionAid UK

3.3 Data exchange with other systems. ActionAid UK Head of Data with substantive input from supplier and Workstream Manager - Development.

4. Testing

Page 8



4.1 Test plan and acceptance criteria Advice and good practice examples expected from the Supplier.

ActionAid UK Workstream Manager – Change, Communications and Engagement, with substantive input from Workstream Manager - Development.

4.2 Testing completed and signed off Workstream Manager – Development and Supplier.

5. Documentation

5.1 Technical system documentation Suitable handover documentation of the service must be provided to ActionAid UK support teams, this must include architecture artefacts, service support documents etc.

Support teams must be part of the handover process.

Supplier

5.2 Online help Supplier

5.3 User manuals/materials ActionAid UK Workstream Manager – Change, Communications and Engagement and Supplier

6. Training

Page 9



6.1 Training collateral (and some delivery) customised by audience and journey.

This will change the way people work, and we would expect a first cut of training by the supplier to the core project team initially. The training will need to clarify new business process as well as tool use.

ActionAid UK Workstream Manager – Change, Communications and Engagement with support from the supplier.

6.2 Training for “Power users”. ActionAid UK expects to provide at least 1st line support services leaving the supplier to play a 2nd and 3rd line and ongoing development role. However, the supplier should define what local administrators / configurers are able to do.

ActionAid UK Workstream Manager – Change, Communications and Engagement with input from supplier and the Workstream Manager – Development

6.3 Training of support team To be trained as part of the service implementation to support and maintain the system.

7. Project Management

7.1 As would be expected: highlight reports, project planning, change/issue management, Supplier’s quality plan, etc. specifics to be agreed when setting up contract.

The supplier project manager will be expected to attend internal steering committee meetings and co-ordinate all planning activity with the ActionAid UK Project Manager.

The ActionAid UK Workstream Manager – Development and Supplier Project Manager.

7.2 Contracts with chosen supplier The ActionAid UK Workstream Manager – Development and Supplier Project Manager.

Page 10



8. Continuous Development

8.1 Ongoing development, release management, backlog/code management.

ActionAid UK expects to continue to develop the CRM post implementation.

Supplier with substantive input from the ActionAid UK Workstream Manager – Development

8.2 Account management, new product features/vendor-imposed change, service desk and technical support.

As well as providing support role ongoing ActionAid UK also expects the supplier to help with product upgrades, new features and general systems management.

Supplier with input from the ActionAid UK Workstream Manager – Development

Page 11


6. Functional RequirementsThis section details the functional requirements for a new system based on the current business processes. Staff expect that the new system will enable ActionAid UK to refine and improve these processes to meet the project aims and success criteria, with the addition of new and different services and initiatives in the future. The functional requirements are supported by appendices (process flowcharts and example documents and reports) where appropriate.

The functional requirements include:

Supporter Record and Relationship Management Communication Management Child Sponsorship Philanthropy and Partnership Events and Community Legacy Campaigns Trade Products Payroll Giving SMS Giving Lottery Inventory System Supporter Contact Digital Marketing Source/Product Management Reports, Selections & Triggered Workflow Finance Data Protection

Page 12


This section also includes general and IT requirements for the new CRM system.

The supplier should provide a full specification for their proposed system, including details of any built-in reports and whether the design of any custom reports is included in the quoted price.

Please list the number of built-in reports, their names and a brief description of the report content.

Suppliers should indicate whether the requirement in each numbered section:

a) Can be met as-stated, using standard facilities within the proposed package.b) Can be met by a minor modification to the package for which there would be no charge to ActionAid UK and no implications for the application of

system updates and new releases.c) Can be met by significant and chargeable modifications and may or may not have cost implications (e.g. re-test) on application of system updates

and new releases.d) Can be met by using a third-party product (e.g. report writer, addressing software).e) Can partly be met using standard facilities within the proposed package but there are limitations (e.g. requirement is for multiple addresses per

contact but the software only supports three).f) Cannot be met.

Please provide a separate narrative to explain any responses given as ‘b’, ‘c’, ‘d’ or ‘e’.

Page 13


Functional Req 1 : Support Record & Relationship Management

AAUK records and maintains contact with individuals and organisations that support ActionAid’s causes and campaigns that could be financial (e.g. donation) or non-financial (e.g. sign a petition, enquired about an event). They include, but not limited to the following:

Financial donors Event participants Trade customers Legacy pledgers and givers Lottery participants Campaigning participants Staff of organisations Enquirers Schools Trusts Corporates Government bodies

ID Requires a system that Additional information a b c d e f Supplier notes

FR 1.1 Enables staff to record data about all contacts and involvements supporters have with AAUK at first & subsequent contact. These supporters could be an individual or an organisation; financial or non- financial.

Refer to Appendix B1.1 - Supporter/Organisation Classification

FR 1.2 Supports staff in maintaining a whole picture of the individual/corporate and enables staff to personalise the experience, based on the supporters' needs and wishes.

Page 14



FR 1.3 Ensure the data is captured once, whatever the channel

Including supporting staff in recording data consistently e.g. through mandatory fields, validation of the field in comparison with others and mutually exclusive values.

FR 1.4 Provides a holistic 'at a glance' view of supporters’ basic engagement information (e.g. Type of supporter, donation to date, last 6 months of donation and communication history)

FR 1.5 Supporter Record Creation

requires the following functionalities:

Refer to Context Diagram 1 – Supporter Creation (CD 1.1)

Refer to Process Map 1 – New Supporter Creation (PM 1.1)

Supporters can be created individually, or mass uploaded into the system.

Page 15



FR 1.5.1 Allows selected staff to be able to create new supporters

Other than the typical contact details, the system needs to also allow additional entry of:

Multiple addresses (ability to annotate what these addresses are for)

Foreign addresses Social media handles Date of Birth

FR 1.5.2 Allows mass upload of supporter details with ease. System should not be cumbersome.

Agencies we work with recruiting supporters usually have individualised templates for mass upload

FR 1.5.3 Intelligently check through the First & Last Names and bring to staff attention if names included title or words like Aunty, Grandpa

Words to be checked should be a library that is build up over time

FR 1.5.4 Creates customised template to be mapped with ease based on agency's requirements for mass upload.

FR 1.5.5 Checks for duplication in supporter record and alert staff for intervention. This should apply for all manner of supporter creation.

Page 16



FR 1.5.6 Produces duplication report. Agency who recruit for us are paid by new supporter or new product signed up, the report helps to prevent unnecessary charges made to agency.

FR 1.5.7 Checks that every supporter is genuine, especially when signed up through AAUK website.

A genuine supporter would have made an enquiry, taken a financial commitment, set up a just giving page or corresponded with an AAUK staff.

These sign ups could potentially be held in a holding area till proven genuine.

FR 1.5.8 Allows deletion of a supporter record only if no activities/ donation record has been associated with the supporter yet

FR 1.5.9 Interact with PAF system to ensure accuracy in addresses keyed in

FR 1.6 Supporter with Restriction


Page 17



FR 1.6.1 Record supporters with restriction and is able to have status reflected prominently when viewing supporters' data. (Note: Only the status should be visible. Details of the restriction is only accessible to a handful of staff)

A restriction would limit the way a supporter can interact with AAUK and our products

Supporters under restriction will require manual review by staff before participating in AAUK's product/event (e.g. Lottery)

In essence this requirement relates to an individual in either permanent or temporary vulnerable circumstances.

FR 1.6.2 Highlights any registration/ donation / participation by 'restricted' supporter so that staff can manually process them.

FR 1.6.3 Allows staff that have permission to add, edit and view the details of the restriction.

FR 1.6.4 Captures the following restriction data Date Reason for restriction (Drop down

selection) Who requested the restriction Permanent or Temporary restriction

FR 1.6.5 Sets notification trigger date for staff to review any temporary restriction and lift restriction when applicable

Page 18



FR 1.7 Allows clarity and flexibility in managing relationship between individuals and organisations

Example of relationships are: Individuals are staff of an

organisation An Individual is related to

another individual (e.g. Spouse, Personal Assistant)

An organisation is related to another organisation (e.g. a trustee company that manages a trust)

FR 1.8 Bars certain supporters’ information and only allow access by selected staff. (e.g. P&P donors where extensive research is done on them)

FR 1.9 Link organisation and their associated HQ and departments so that within the CRM we can identify the hierarchical relationship between them.

e.g. If a school participates in an event with us, they could belong to a group of a school governing body. We want to be able to record the event a school has taken. And also, then to zoom out to the school governing body and look at maybe the total funds received from all the schools under the governing body.

FR 1.10 Provides flexibility in identifying and updating the multiple roles a supporter could have. A 'start' & ‘end’ date should be associated with each role assigned.

e.g. a supporter can be a campaigner, an individual donor and works in a foundation that supports AA UK

Page 19



FR 1.11 Amalgamate duplicate records. No data should be lost in the process. The duplicated record either needs to be disabled or deleted. System needs to also capture that the existing record has been amalgamated.

e.g. a supporter may have signed up with 2 different e-mail addresses and over time we realise they are the same person. The 2 records should be combined into 1 record.

FR 1.12 Can identify supporters that are no longer active, give them a 'lapsed' status and cancel any opt-in communication.

FR 1.13 Indicate and capture the date & source when a supporter has 'Gone Away' or is 'Deceased'.

Both groups of supporters may continue to up-keep their regular donations. Records should not be made inactive until financial commitment ceases.

Gone Away supporters are supporters that no longer contactable (e.g. wrong postal e-mail address).

FR 1.14 Map new supporter reference number to old system (Infobase and Raiser Edge) supporters reference number

Page 20


Functional Req 2 : Communication Management

AAUK records all communications with supporters. Communication with supporters could be verbal, written and could take place through various mediums like e-mail, SMS text, phone call, physical letter, social media, inperson meeting, etc. These communication records are two-way; supporters contacting AAUK, or AAUK reaching out.

AAUK will also respect supporters’ communication preferences and will abide by the request unless there are legitimate reasons otherwise (e.g. essential admin).


FR 2.1 Supporter Communication Record


FR 2.1.1 Log all communication (call, e-mail, web chat, letters and etc) against a supporter’s detail and indicate clearly the type of communication and record the date and a synopsis of the communication (if required)

FR 2.1.2 Attaches email and its response threads seamlessly from Outlook 365 and Contact Centre system e.g. Ignite to the supporter record in CRM.

FR 2.1.3 Easily retrieve and read through the communication history

FR 2.2 Communication Preference


Page 21



FR 2.2.1 Record supporters' communication preferences and the channel source (e.g. Website, agency, call in, Just Giving and etc)

Communication preference includes email, phone, text and post

FR 2.2.2 Update communication preferences and record date of change

FR 2.2.3 Prevents any marketing communication to be sent to supporters who have chosen to opt out of communication or to Gone-Away & Deceased Supporters

FR 2.2.4 Records supporter communications preferences in a way that can be selected at channel level, and/or in a more granular way such as areas of interest, or in choosing to receive selected communications

A supporter is only interested in receiving campaign related communication but not donor related communication even though he/she is a donor

Or a P&P donor has a more personalised approach and may not receive generic mass communications.

FR 2.2.5 Able to temporarily disable a certain communication type and reinstate it after a certain date

A supporter could be travelling for 3 months and do not want to be contacted via text.

Page 22


Functional Req 3 : Child Sponsorship

Child Sponsorship is the largest income generating fundraising ‘product’ for AAUK, and also the ActionAid International federation as a whole. AAUK works in partnership with AAI on the child sponsorship programme of which AAUK’s primary responsibility is to find supporters to sponsor children where portions of the sponsorship monies are channelled to the children’s community which is commonly referred to as a Local Right’s Programme (LRP). AAUK requires a CRM that can integrate with AAI’s Child Sponsorship Management System (CSM); to be able to administer all elements of the child sponsorship programme and manages child to supporter (and back) relationships. Hard copy profiles of children to be sponsored are generated by our UK team, and this contains a photo and welcome message from the child. This is then sent to a supporter in their welcome pack.


FR 3.1 Manages all elements of child sponsorship and is able to interface/integrate with AAI’s CSM system for any child profile/status updates and changes.

Data exchange is preferably to be real time or exchanged on demand.

Will be future proofed for potential full API between CRM and AAI CSM

The AAI CSM system is used by countries to manage child sponsorship and its related products and is also a planning tool between funding affiliates and countries.

The AAI CSM system is still under development and is slated to be soft launched in phases in the first half of 2021.

FR 3.2 Child Record


Refer to Context Diagram 2 – Child Record (CD 2.1)

FR 3.2.1 Upload (Sync) child assigned to AAUK for sponsorship from the AAI CSM system. Common fields should be auto populated in the CRM system.

Refer to Appendix B2.1- Child Record

Page 23



FR 3.2.2 Allows ease and flexibility in looking up child records to support any queries responds to supporters; generate reports where necessary

FR 3.2.3 Prevent a child to be linked for sponsorship if:

Status is not at "Active". Profile is greater than 2 years old Welcome Child Message is not

Available

FR 3.2.4 Provides notification alert when children’s availability are running low for a particular country, age and gender.

FR 3.2.5 Check for child record duplication and prevent creation in the event of duplication

FR 3.2.6 Keeps an audit record (time stamped) of child status change

FR 3.2.7 Update sponsorship availability (location, gender, age) on website

FR 3.3 Child Profile Management


FR 3.3.1 Generate child profile through a complex 'mail-merging' system using the child profile content and LRP Information pack

Refer to Appendix B2.2 - Child Profile – Mail Merge System

Page 24



FR 3.3.2 Allows flexibility in designing the child profile; embedding pictures; customisation of layout depending on target audiences

FR 3.3.3 Generated child profiles are kept digitally against the child record and can be reproduced anytime.

FR 3.3.4 Tracks and triggers an action for a child profile update when child profile becomes expired

Refer to Process Map 2 – Child Profile Update (PM 2.1)

Updated child profile content can be over-written. However the old digitalised child profile created previously should be archived.

FR 3.4 Child Messages


Refer to Process Map 3 – Child Messages (PM 2.2)

Child Messages (CM) are received twice yearly from each country. AAUK will check and safeguard the messages before bulk mailing out to the supporters.

FR 3.4.1 Provides inventory support to track and manage child messages receipt and delivery

Refer to Appendix B2.3 - Child Message Inventory Requirement

Page 25



FR 3.4.2 Prevent a child to be put up for active sponsorship if there isn't a valid up-to-date welcome child message & photo against their record. Child messages have a validity of 2 years.

FR 3.4.3 Allow staff to check the status of the child message easily to be able to respond to the supporter if they have a query about it.

Supporters are often keen to know when their next child message will arrive.

FR 3.4.4 Is able to run reports on status, delivery and the quality of child message to both countries and management

Refer to Appendix B2.4 - Child Message (Bulk Mail) Sample Report

FR 3.4.5 Bulk upload scanned copy of child message using OCR to accurately link child message to a child record

FR 3.4.6 Removes unused child messages from the system after 2 years. System should be flexibile enough to change this time period

FR 3.5 Child Media (Photo & Video)


FR 3.5.1 Store all child media received from AAI

FR 3.5.2 Record the date of the child's media received

FR 3.5.3 Archive/delete unused child media for children that has 'withdrawn' or 'deceased' status.

Page 26



FR 3.5.4 Mark media that are used for profile, updates and marketing. Ability to tag what each media is used for

FR 3.5.5 Allows staff to run reports to check the inventory level of used and unused child media

FR 3.5.6 Removes unused child media from the system after 2 years. System should be flexibile enough to change this time period

FR 3.6 Country / LRP Management


FR 3.6.1 Set up Country and LRP information before any child from the LRP can be put into the CRM.

Refer to Appendix B2.5 - LRP/ Country Requirements

FR 3.6.2 Drives the behaviour of child's status depending on the status of the LRP.

FR 3.6.3 Accurately drives the child sponsorship funding financials associated with the LRP.

AAI Funding Source Code which determines how a fund is distributed is held at the LRP level. So, a child who is being sponsored will have his/her donation channelled to the LRP they belong to.

FR 3.6.4 Allows LRPs to be enabled for prioritised marketing. There could be multiple LRPs that will be put up for priority marketing

Refer to FR 3.7.3 for auto matching requirements

Page 27



FR 3.6.5 Has a notification trigger to review LRPs in priority

FR 3.6.6 Records 'replacement LRPs' for ease of sporadic and mass transfer.

FR 3.7 New Child Sponsorship


Refer to Process Map 4 – New Child Sponsorship (PM 2.3)

FR 3.7.1 Update the website on child availability by gender, country and age

FR 3.7.2 Records a supporter's child preference (age, gender, and country). A supporter may sponsor multiple children and thus may have multiple child preferences.

This record will help aid future child match if a transfer happens.

FR 3.7.3 Auto match and link a supporter to an available child in accordance to set parameters. Manual linking is required if staff prefers to match a supporter and a child physically or when auto-match can't be done.

FR 3.7.4 Update AAI CSM system of new supporter record and new child links

FR 3.7.5 Allows flexibility to customise welcome packs for supporters. These packs could take the form of physical or digital mail outs.

The way we manage welcome packs could change over time.

FR 3.7.6 Tracks and ensure 1st payment is received or otherwise trigger a Recovery Process

Refer to FR 17.7- Recovery Process

Page 28



FR 3.8 Other CS Supporter/ Donor Relationship


Most supporters are financially supporting the child’s community they have sponsored. Typically, one child would have one supporter. However, there are peculiarities which we need the system to manage.

FR 3.8.1 Records a supporter paying for child sponsorship for another supporter.

Financial records and Gift Aid will be held against the paying supporter. Supporter/ Child Relationship link against the Recipient Supporter.

Communication to the paying supporter and recipient supporter will vary (e.g. Letters pertaining to payment will be directed to paying supporter, Child Message to Recipient Supporter, Action Aid Magazine to both supporters if they live in different household)

E.g Grandparents (Paying Supporter) paying on behalf for a grandchild (Recipient Supporter).

Page 29



FR 3.8.2 Records family nucleus supporting a child.

There should be separate supporter record for each member of the family.

Child are dual linked to each of the supporters

Child Sponsorship Donation/Gift Aid could be split between the supporters

Communications are often jointly sent and addressed (e.g. Mr and Mrs Smith)

Family nucleus can refer to a couple jointly sponsoring a child.

Note: At the moment, AA UK Current CRM (infobase) do not split family nucleus. They are held under one supporter record.

FR 3.8.3 Is able to 'dissolve the relationship' and maintain a single donor supporter to child relationship. System needs to be flexible to enable the change to pick which supporter continues the 'single' supporter journey whilst the other supporters retains the sponsorship history they had with AAUK.

FR 3.8.4 Manually creates these exceptional supporter relationships by staff.

FR 3.9 Transfer


Refer to Process Map 5 – Child Sponsorship Transfer (PM 2.4)

FR 3.9.1 Manages transfer seamlessly by auto matching a new child to a supporter and generate the necessary communication letter.

Transfer happens when a child is no longer available for sponsorship.

Page 30



FR 3.9.2 Matches a child using different set of criteria in sporadic transfer than that of a new sponsorship

Refer to Appendix B2.7 - Matching aChild to a Sponsor in a Sporadic Transfer

FR 3.9.3 Enables mass transfer in an event of a LRP closure.

FR 3.9.4 Capture the reasons for transfer on the child record.

FR 3.9.5 Generate letter automatically based on the transfer reasons provided by AAI

FR 3.10 Stop Child Sponsorship


Refer to Process Map 6 – Stop Sponsorship (PM 2.5)

FR 3.10.1 Stops child sponsorship automatically when repeated payments fails or manually when a supporter informs us and generates the necessary communication letter.

FR 3.10.2 Update AAI CSM system on changes in child sponsorship links

FR 3.11 Supporter Correspondence & Gift to a Child


Page 31



FR 3.11.1 Records all Supporter's correspondence and gifts received for the child. A supporter may sponsor several children thus, the correct child needs to be associated.

Refer to Process Map 7 – Supporter Correspondence & Gift (PM 2.6)

Action Aid has an anti-gift policy for the child sponsor.

FR 3.11.2 Records that a supporter's letter has been redacted

FR 3.11.3 Records the date of message received

FR 3.12 Supporter Queries and Complaints


Refer to FR 13.3- Case Management for managing queries and complaints

AAI has a separate system that records any supporters’ queries/complaints that require a country response.

FR 3.12.1 Track outstanding responses from AAI System

FR 3.12.2 Saves a downloaded/retrieved copy of the correspondences between AAI countries and AAUK against a supporter

Page 32


Functional Req 4 : Philanthropy and Partnership

Philanthropy and Partnership (P&P) manages high-value donors that give a minimum of £5000/year. These donors can be individuals, trusts/foundations and corporates. Relationship management for these donors is more personalised and often requires a period of research and solicitation before they become AAUK major & principal donors.


FR 4.1 Provides relationship management tools to solicit, cultivate and manage high value donors.

Refer to Context Diagram 3 – Philanthropy and Partnership (CD 3.1)

FR 4.2 Pipeline & Prospect Management


Refer to Process Map 9 – Pipeline and Prospect Management (PM 3.1)

FR 4.2.1 Creates pipelines for the P&P staff to monitor and track the status of their prospect cultivation work.

Refer to Appendix B3.1- Pipeline Status

FR 4.2.2 Tracks the progress and duration of the pipeline stages

FR 4.2.3 Enables the P&P team to interrogate all the supporters' gifts history to identify potential large givers

Page 33



FR 4.2.4 Allows donor/trust/corporate to be identified as follows:

Differentiate donors who are able to give significant donations, but at different tiers.

These donors can be further categorised into "Prospective" (still cultivating a relationship) or "Not Suitable" (will no longer pursue)

Note: Ability to mass change the status.

FR 4.2.5 Generate reports for each pipeline status and its duration at each stage.

FR 4.2.6 Indicate members of staff (known as key-workers) working on the pipeline including additional 'secondary' key-worker assisting on the work.

FR 4.2.7 Include a percentage allocation of work effort for each of the keyworker so that income can be appropriated to their targets

FR 4.3 Engagement Management


Page 34



FR 4.3.1 Sets up and records communication and activities such as phone call, meeting notes, attendance of events undertaken with a supporter.

Refer to Appendix B3.2 - Correspondence & Activities Recording

FR 4.3.2 Links the engagement to a supporter record so that it can be referred back to easily.

FR 4.3.3 Differentiate engagement made as an individual supporter or as a staff member working for an organisation.

e.g. an individual could be a CS supporter and an employee working at a trust. If a call relates to an individual querying about CS, this record should be referenced to the supporter's individual record, however if the engagement relates to business phone call, the reference is made to them being a member of staff to an organisation

FR 4.3.4 Enables one or more AA staff (known as keyworkers) to be assigned as the account holder to a donor/corporate. Keyworkers should be picked up from staff directory

FR 4.4 Research Record


FR 4.4.1 Records research findings made on supporter Refer to Appendix B3.3 - Prospects Research Findings

Page 35



FR 4.4.2 Is able to run queries to pull out for example new pipeline opportunities; reach out to specific donors for emergencies appeal

FR 4.5 Proposal/Ask Record


FR 4.5.1 Records proposals submitted, the status and the financials

Refer to Appendix B3.4 - Proposal/Ask Management

FR 4.5.2 Integrates status updates with pipeline stages. (e.g. a status 'Declined' will trigger a change in the pipeline status)

FR 4.5.3 Allows attachment of proposal document

FR 4.6 Income Recognition, Pledging and Forecasting


FR 4.6.1 Records and reports accurately financial donation and pledges

Refer to Appendix B3.5 - Donation Pledging

FR 4.6.2 Measures sales target for each keyworker

FR 4.6.3 Provides a workflow between our finance team and P&P staff to record major donations coming in and allocate the right financial codes for accurate accounting. Soft crediting should also be made available when recording income.

Refer to Appendix B3.6 - Income Tracking Form

Soft Credit is a record of a donation a supporter did not actually make but has influenced it.

Page 36



FR 4.6.4 Allows staff to indicate on the workflow if the donation is claimable for gift aid.

Unlike typical donations where gift aid declaration is a blanket cover for a supporter, high value donations are dealt on a case basis.

FR 4.6.5 Ability to notify key workers when a pledge amount fails to come through

FR 4.6.6 Provides financial forecasting tool that is able to pull incomes that are regular and ongoing; have been pledged and that are being worked on in the pipeline. 'Proposal' and 'Ask' in the pipeline should have a 'probability' factor rated against them.

Page 37


Functional Req 5 : Events and Community

Events and Community handles 2 types of supporters.

Event supporters raise funds for AAUK through an event they participate like the London Marathon or go on an overseas trip to help build a school. AAUK provides stewardship support throughout the event.

Community supporters are often a group of people that comes together to fund raise for AAUK on their own accord. AAUK supports them with tools, materials, and engaging content.


FR 5.1 Records all events and provides customisable stewardship journey for event supporters, capturing accurately the funds raised for the event.

FR 5.2 Supporters Record for E&C


FR 5.2.1 Captures supporters & their details when they have enquired or signed up for an event either online or offline.

FR 5.2.2 Records clearly a supporter current and past event participation

FR 5.2.3 Builds customised stewardship journey for each supporter

Refer to Appendix B4.1 - Customised Stewardship Journey

FR 5.2.4 Records all communication made with a supporter

Refer to FR 2.1 – Supporter Communication Record

Page 38



FR 5.2.5 Track amount raised by the supporter for a particular event with the ability to break down registration fee, itemised fund raised, itemised gift aids and any other miscellaneous monies

FR 5.2.6 Track & trend supporter's motivation (reason) in supporting AAUK.

FR 5.2.7 Ability to link a supporters third party online fundraising page (e.g. Just Giving) and record the individual funds raised accurately against their record

FR 5.2.8 Fulfil supporters request for Fund Raising Resources and any Running vest though the inventory system

Refer to Functional Req 12: InventorySystem

FR 5.3 Event Record


Refer to Process Map 10 – Challenge Events and First Hand Experience (PM 4.1)

Refer to Process Map 11 – Community and Group Fund Raising (PM 4.2)

Challenge Events are often organised by 3rd party

FR 5.3.1 Records basic events details (e.g. Name of event, Date , Type of event and etc)

Page 39



FR 5.3.2 Records if a fund raising event is raised by an individual or an organisation.

If an organisation, event and fund raised record should not be affected when the managing staff member leaves the organisation.

If there is a federation with multiple subsidiaries raising funds for the same cause, soft crediting will be required between the subsidiaries and federation

FR 5.3.3 Track the total amount of funds raised for an event with the ability to break down the details (e.g. fund raised, gift aid received, registration fee)

FR 5.3.4 Allow documents to be attached against an event (e.g. contract with a travel agency for a First Hand Experience) or against a supporter (e.g. insurance document)

Access to sensitive documentation should be restricted when required

FR 5.3.5 Allows some details to be erased from the CRM automatically post event (e.g. Passport details)

FR 5.3.6 Allows e-forms to be e-mailed to supporters, tracked and collated

This should be possible via outlook or a bulk e-mail provider.

FR 5.4 Indirect Donor


Page 40



FR 5.4.1 Records donors into the CRM and indicate them as indirect donors (if they are new supporters)

Indirect Donors relates to people who have donated to our supporter for an event they are fund raising for AAUK. The donation can come through an online fundraising platform e.g. JustGiving, physical cheques or other means of payment.

FR 5.4.2 Soft credit the donation against the donor’s record and co-relate the same donation to the supporter that has fund raised the amount

FR 5.4.3 Reflect the communication preferences selected by the donor on an online fundraising system (e.g. Just Giving) onto the CRM if we set them up as new supporters

FR 5.5 Generic Events Management


This function is not specific to the events team but will be used throughout the Fundraising and Marketing Teams.

FR 5.5.1 Creates an event and tracks the attendees

FR 5.5.2 Churns out invitation letters/cards, name tags using mail merge

FR 5.5.3 Records guest of an invitee. Guest needs to be associated to the invitee. Note that guest may or may not be in the CRM record

Page 41



FR 5.5.4 Tracks RSVPs and actual attendance to the event

FR 5.5.5 Tracks dietary requirements of all invitees and guests. Flexibility to remove dietary records post event

FR 5.5.6 Allows attachment of documents such as budget, post event evaluation survey

FR 5.5.7 Tracks a donation or uplift to an existing donation related to the event attended

Functional Req 6 : Legacy

There are 2 aspects of Legacy. One is the marketing of Legacy where we try to encourage supporters to leave a legacy for AAUK. The other is the administering of legacies which relates to the process of identifying and collecting funds that have been left to us in wills.


FR 6.1 Records all elements of legacy whether is it a legacy enquiry, intent, pledge or administering a legacy left by a legator to AAUK .

FR 6.2 Record all communications (e-mail, phone, meeting, event) and review the history in association to the case or in-memory activity

Page 42



FR 6.3 Records all contacts, their details and the relationship they have with the deceased. (E.g. Funeral Director, Executor, Next of Kin, person raising the funds in memory of the deceased)

FR 6.4 Allows tasks/ reminder creations for staff to manage follow up actions in association to a case or in-memory activity

FR 6.5 Stores documents received in relation to a case or in-memory activity

FR 6.6 Legacy Intent Pledge (Marketing)


FR 6.6.1 Classify a legacy supporter based on the actions they have taken:

Enquirer (Somone who has enquired about legacy)

Intender (Someone who is keen to leave a legacy)

Pledger (Someone who has left AAUK something in their will)

FR 6.6.2 Record the dates of which a supporter legacy pledge status changes

FR 6.6.3 Record the date when a supporter has become a legator (date of passing)

FR 6.6.4 Capture the intended legacy amount

Page 43



FR 6.6.5 Record gift will pack or any communication sent to legacy supporter

FR 6.7 Legacy Case Administration


FR 6.7.1 Creates a legacy case pipeline to track the status and progress of each case.

FR 6.7.2 Assigns staff to a legacy case

FR 6.7.3 Captures the date and source of new case. Refer to Appendix B5.1 - Type of Dates to capture

FR 6.7.4 Record the type of legacies associated to a case. Note that a single legacy case could have more than one type of legacy within it

Refer to Appendix B5.2 – Type of Legacies

FR 6.7.5 Records all income, expenditure and estimates associated with a case element (type)

Depending on the type of legacy, the way of estimating/forecasting expected income is different.

FR 6.7.6 Allow changes to estimate figures. Changes should have a date stamp and reasons recorded

FR 6.7.7 Mark out all legacies that are contentious with clear reasons being recorded and assign a risk level. Estimates of these cases should not be used in any finance forecast projection/ calculations until we receive final estate accounts

Page 44



FR 6.7.8 Indicate all cases that are confirmed by executor or we have received final estate accounts so that accrual of income can happen.

FR 6.7.9 Records income restriction and allocate them accurately.

FR 6.7.10 Record added value income with associated date and reason for value add

Added value income are additional income received or reduced expenses as a result of case handler’s pro-activeness (e.g. Challenge and reduce legal fees; Negotiate for better property price)

FR 6.7.11 Forecast legacy income based on a set of adjustable formulas.

FR 6.7.12 Record when the case was last reviewed and the actions taken. Set the next review date if required

FR 6.7.13 Allow timeline view of activities that have taken place for a particular case

FR 6.7.14 Stores assets and estate information and their value.

FR 6.7.15 Builds report such as HMRC Tax reclaim, Accrued income, forecasting (notifications and income received, analysis and income summaries reports)

Page 45



FR 6.7.16 Closes a case when all legacy income and the necessary paper work has been received and completed.

FR 6.7.17 Deletes case files after case is closed for 10 years.

Refer to Functional Req 18: Data Protection for details

FR 6.8 In Memory Giving


In memory giving relates to donations that are raised in honour of the deceased.

FR 6.8.1 Classify a supporter that is either an ‘in memory donor’ or an ‘in memory deceased’

FR 6.8.2 Record an in-memory giving activity and their type

FR 6.8.3 Record the individualised and total amount raised for a particular in memory giving.

FR 6.8.4 Ability to link to online giving page (E.g. Just Giving)

Page 46


Functional Req 7 : Campaigning activity

AAUK works with our campaigners to raise awareness and take actions on issues AAUK has embarked on. These actions can range from signing a petition to messaging your MP, or actively attending, or arranging, awareness-raising or protest events and activities.


FR 7.1 Records campaigners & their detail when participating in AAUK led campaigns

Refer to Context Diagram 4 –Campaigns (CD 5.1)

FR 7.2 Interacts with 3rd party sites like Engaging Network (via API or file downloads), the uploading of information should be seamless and require little manual intervention

FR 7.3 Campaigns and Actions


FR 7.3.1 Records all campaigns that AAUK have undertaken

FR 7.3.2 Assigns actions that will be taken in a campaign

Campaigners support AAUK by taking an action like signing a petition, write to MP, attending a workshop.

FR 7.3.3 Allows ease and speed in recording and tracking the various type of actions taken by campaigners

FR 7.4 Action & Action Level


Page 47



FR 7.4.1 Create a library of actions

FR 7.4.2 Assign action level to each action (e.g. Signing a petition will have an action level of 1; whereas E-mailing a MP will have an action level of 3) )

FR 7.4.3 Allows actions and their level to be changed with reasons and date of change captured

FR 7.5 Campaigner Activity Level


Each campaigner is assigned with an activity level. Activity level helps AAUK in selecting the right campaigner to partake in a campaign event.

FR 7.5.1 Uses an algorithm to automatically assign an activity level to a campaigner. These algorithm takes into account how often a campaigner has taken an action and what actions they have taken.

FR 7.5.2 Allows changes to be made to the algorithm

Page 48


Functional Req 8 : Trade Products

AAUK sells merchandise on our website including physical cards for Christmas and a “Gift in Action” virtual gift product in which we may need to print personalised messages before sending them out.

Gift in Action are “virtual gifts” which showcase some of the ways we work with and support communities across the world.


FR 8.1 Manage product orders that come through (web, phone or paper order) and have as much an automated process to follow through the fulfilment

Refer to Process Map 12 – Trade Products (PM 7.1)

FR 8.2 Sync with website for orders made on the website to ensure order payment and fulfilment comes through; pricing is correct and inventory levels are kept updated

FR 8.3 Sends out purchase acknowledgement e-mail for web order and attaches card download when required

Downloadable cards are PDF format - complete with personalisation information and message from the online order form

FR 8.4 Internal Order Form


FR 8.4.1 Caters for a form for staff to use to put in orders that come through phone call or paper order

FR 8.4.2 Looks up supporter information and inputs the correct information such as address

Page 49



FR 8.4.3 Allows search and selection of existing product and check for inventory level

FR 8.4.4 Capture personalised message (if any)

FR 8.4.5 Capture recipient address, name (if any)

FR 8.4.6 Record payment details (only for paper order)

FR 8.5 Takes in the web order and the internal order form and feed in to one fulfilment pipeline for staff to work on

FR 8.6 Tally the product being ordered and reduce it from inventory automatically

FR 8.7 Print the card out accurately taking into account both the product message and the personalised message

FR 8.8 Print out invoices for item purchased to be sent out to supporters that purchased the item

FR 8.9 Send out e-mail through the fulfilment system to inform purchaser that items have been mailed to recipient.

FR 8.10 Sort out card prints, address labels, invoices systematically to reduce logistic handling and errors

Page 50



FR 8.11 Allows flexibility in changing the format for product write up and the layout of messages

FR 8.12 Trade Product Management


FR 8.12.1 Captures basic product data e.g SKU, price.

FR 8.12.2 Ties in with the inventory system to manage all elements of a trade product

FR 8.12.3 Records if there is an occasion behind whythe gift has been purchased (e.g Birthday, Thank you)

FR 8.12.4 Report on the sales of a particular product

FR 8.12.5 Manages products that are being discounted by capturing the type of discounts being applied and the value it has been sold

The type of discount could be a % discount or a buy 'x' number get 1 free offer.

Page 51


Functional Req 9 : Payroll Giving

AAUK work with agencies for payroll giving.


FR 9.1 Records payroll givers that come through payroll giving agencies

Refer to Process Map 13 – PayrollGiving (PM 8.1)

FR 9.2 Uses either API or files upload to automatically generate new payroll supporters and record payments coming through

FR 9.3 Links the payroll agency, their reference number to our Supporter Reference Number

FR 9.4 Have means to manage anonymous supporters that have no names nor contact details.

FR 9.5 Tracks lapsed payments and removes supporters as regular payroll giver after 3 lapsed cycles

FR 9.6 Re-establish payroll payment link that has broken when required

Necessary for lapsed supporter wanting to payroll give again.

FR 9.7 Associate the payroll giver to the company they work for

FR 9.8 Record and soft credit any payroll matching between the payroll giver and their company

Payroll matching is when the company full or part match the amount donated by their employee.

Page 52



FR 9.9 Capture any admin charges associated with the payroll give

Functional Req 10 : SMS Giving

AAUK works with agencies on donations that comes through SMS. The requirements stated are purely for SMS supporters and payment records and does not pertain to SMS marketing.


FR 10.1 Records SMS givers that come through SMS giving agencies

FR 10.2 Uses either API or files upload to automatically generate new SMS supporters and record payments coming through

The unique identifier for SMS supporter is mobile number.

FR 10.3 Have means to manage anonymous supporters that have no names nor address details

Functional Req 11 : Lottery

AAUK lottery is registered with the Gambling Commission and runs weekly lottery draws every Thursday.

Page 53



FR 11.1 Manages the lottery draw and records the supporters that participate in the draw.

Lottery costs £1 per entry per week, which equates to £4.34 per calendar month, £13.02 per quarter or £52.08 per annum.

FR 11.2 Assigns unique play number to the supporter based on the number of plays he/she have each week.

If a supporter enters 2 plays each week, he/she will have 2 unique play number.

FR 11.3 Manages & accounts for lottery pool monies received separately from the rest of the donation.

FR 11.4 Allows supporter's entry into the lottery draw only after the second monthly payment has been received.

This is in accordance to the one month cooling off period set by the lottery commission.

FR 11.5 Accounts for supporters' 'financial commitment' into future lottery draws

A supporter can pay 3 months into advance into the next 12 draws. Or could pay £5 a month instead of £4.34/month, the additional £0.64 will be accumulated over time for another play.

FR 11.6 Uses a Lottery Commissioner compliant Random Number Generator (RNG) to pick the winners

RNG can be off the shelf which integrates with the CRM.

FR 11.7 Name the weekly draws with running number. E.g. Draw 1175, Draw 1176

Page 54



FR 11.8 Keeps track of: - The number of plays being entered weekly.- Total draw fund that was entered weekly

FR 11.9 Splits the total draw fund into

75% - AAUK to receive 25% - Prize Fund to winners

FR 11.10 Automatically calculate the prize fund for the winners

1st Prize - 50% 2nd Prize - 20% 3rd Prize - 15% 4th Prize - 10% 5th Prize - 5%

FR 11.11 Generate letters automatically to inform winners of their win.

FR 11.12 Transfer prize monies back to the winners’ bank account automatically.

FR 11.13 Have a clear overview of a supporters play commitment, draws they have entered, draws they have won

FR 11.14 Withdraw a supporter from lottery draw when a supporter stops playing.

Functional Req 12 : Inventory System

Page 55


The inventory system will help to keep track of products we have for Trade Merchandise ( Functional Req 8) or to manage supplies for Events (FunctionalReq 5).


FR 12.1 Record all products' inventory level

FR 12.2 Records the product sent to a supporter with the ability to view this information both on the supporters’ page as well as inventory page

FR 12.3 Allow for stock to be drawn out by staff for internal use

E.g. issuing t-shirt to staff to support an event; printing error on a Gift in Action Card.

FR 12.4 Trigger a notification when a particular product runs low in stock. The stock level trigger should be adjustable for each product

FR 12.5 Ability to indicate if a particular product has been phased out

FR 12.6 Record stock replenishment. Ability to mass upload if required.

FR 12.7 Allows for stock adjustment when the stock level in the system is different from the physical count

FR 12.8 Has a loan system for some products. (e.g. collection tin that can be returned and re-issued out)

Page 56



FR 12.9 Has a clear trail on loaned products capturing dates; duration it has been loaned out and with which supporter

Functional Req 13 : Supporter Contact

Supporter Contacts are our ‘call-centre’ staffs that respond to telephone, email and social media enquiries.


FR 13.1 Embed the contact centre system into the CRM (or vice versa) such that there is automation link between the two systems to: - allow ease of access to supporter data - emails exchanges are recorded seamlessly into the CRM

Currently AAUK uses the Mitel Ignite system to manage calls/e-mails from supporters and the public. Web chat is also functionality that is possible through Ignite and may well be tested by AAUK.

FR 13.2 Supporter Contact staff should be able to create new supporter, take payment, cancel payment for any products offering (e.g. Child Sponsorship, Donation, Gifts in Action)

FR 13.3 Case Management


FR 13.3.1 Allows staff to create cases when there are follow up actions required for a supporter

Page 57



FR 13.3.2 Assign severity rating to a case (High, Medium, Low)

FR 13.3.3 Tracks stages of a complaint (e.g. Complaint just received, Complaint to be managed by management, Complaint being escalated to FR regulator)

FR 13.3.4 Allows cases to be assigned to a dedicated staff or forwarded to other departments

FR 13.3.5 Traces all communication and response pertaining to the case

FR 13.3.6 Creates reminder or notification to action on a case

FR 13.3.7 Allow cases to be closed when issues are resolved

FR 13.4 Categorise cases and communication record (e.g. Complaint, Compliment, Child Sponsorship) for ease of reporting and reference. Categorisation should be easily expanded.

FR 13.5 Enables a 3-way integration between CRM, Call Centre system & PCI compliant telephony payment system to ensure secured payments can be taken over the phone

Page 58



FR 13.6 Is able to cater for future digital communication mediums like webchat, social media & instant messaging chats

FR 13.7 Supporter Contact staff should be able to create new supporter, take payment, cancel payment for any products offering (e.g. Child Sponsorship, Donation, Gifts in Action)

Functional Req 14 : Digital Marketing

We currently use Dotmailer as our bulk email platform, Sprout to manage our social media, plus disparate systems and quite a bit of manual processing to manage our Digital Marketing activity. We are actively seeking efficiencies in this area and the opportunity to integrate new functionality.


FR 14.1 A bulk email/ SMS platform that meets detailed requirements around: user interface, user management, list management, reporting, data integration, data security, hosting, support and maintenance, to be scoped at a future point. Key requirements are highlighted below in FR14.1.1 through FR14.1.7

To be scoped in more detail at a future point

FR 14.1.1 Ability to automate supporter email/SMS journeys

Page 59



FR 14.1.2 User can select/import a dataset into email/SMS tool

FR 14.1.3 Responsive content templates can be pre-loaded

FR 14.1.4 A/B tests can be set up with different content/templates

FR 14.1.5 Pre-set/automated email/SMS journey can be launched

FR 14.1.6 Triggered journey process can be set up in advance based on supporter action/inaction

FR 14.1.7 Performance measures can be reported on: open rate, delivery, clickthrough rate, etc

FR 14.2 Social Media management platform allowing us to schedule, publish, monitor, manage workflows, listen (including sentiment analysis) and report.

To be scoped in more detail at a future point.

FR 14.3 Action taken/provision of data by a supporter can generate a retargeting ad

FR 14.4 Web forms can be integrated/embedded into our Drupal website

Functional Req 15 : Source/Product Management

Page 60


AAUK currently has a cumbersome 'campaign/source code' process that we use to identify how an action came about from a campaign/source. Example of which is: a donation (action) due to an email (the source) received.

The current source coding comprises a combination of financial data and campaign information, as well as the communication channel, and it is not very effective when drawing reports to measure success. It’s also not very well understood by users, resulting in inaccurate application of the process, and incorrect reporting We hope through the development phase, the supplier will help us identify some industry best practices. The requirements set out here are very basic and will need development.

AAUK currently do not practice classifying programmes or initiatives we have like the Child Sponsorship, London Marathon. Moving forward, we would like to work around the concept of managing ‘Product’ and have a means of tracking performance, how a product came about; reason and when it was decommissioned.


FR 15.1 Source & Campaign Management


FR 15.1.1 Creates and stores campaign/source code and the associated data

FR 15.1.2 Tracks the outcome through campaign/source code and produce meaningful reports to measure success and outreach

Outcome could be anything from giving a donation, enquiring about AA, join a campaign or event, lodge a complaint

FR 15.1.3 Allows staff to request for campaign/source code through a work-flow form which either requires approval or triggers notification for actions.

FR 15.1.4 Manages the campaign/source code to allow amendments and close inactive source code

Page 61



FR 15.2 Product Management


FR 15.2.1 Creates and records all fundraising products. Possible things to capture are: Date of creation, Description of products, Financial coding associated to product, Cost of development, Date product is decommissioned and reason.

FR 15.2.2 Track and measure the outcome of a particular product's performance

FR 15.2.3 Allows staff to request for fundraising product creation through a workflow form which is to be directed to relevant teams for approval

FR 15.2.4 Sends e-mail notification to inform relevant department/staff that a product code has been approved/ rejected

FR 15.3 Manages the product library to allow amendments and decommission products

Functional Req 16 : Reports & Triggered Workflows

Our expectation is that reports/queries within the CRM functionality should be simple and straight forward to aid staff in their day to day work.

Page 62



FR 16.1 Allows staff, in line with their access level, to interrogate/query the database and produce reports quickly and to monitor dashboards.

Refer to Appendix B7.1 - ReportingLevels

FR 16.2 Provides an interactive, customisable dashboard so that staff can monitor key activities/tasks that are happening; major donations that have come through; pipelines overview and etc.

FR 16.3 Allows staff to create their own reports through intuitive build tools

FR 16.4 Provides the ability to record and report on agreed KPIs

FR 16.5 Allows staff to build simple workflows to drive automated processes that could trigger:

communication (e-mail, post, potentially sms) sent internally or externally

notification alerts actions to be taken reports to be generated and sent

The build module should be visual and intuitive to use.

Functional Req 17 : Finance

AAUK requires a robust system that integrates with our Finance Accounting system (SUN). It is expected that incomes are recognised accurately through automated processes as much as possible. The system is also able to support regulatory requirements that needs to be adhered and abided to.

Page 63



FR 17.1 Manages all elements of income received and is able to interface with the Accounting System (SUN) daily, ensuring that the cut off of the items being updated is correct

FR 17.2 Records and reports donations/financial grants accurately against an individual or an organisation.

FR 17.3 Stores & retrieves all finance transaction documents clearly against supporters' record. These documents should be easily retrievable for checks and audits.

e.g Direct debit from, letter supporting a donation, trade purchases and etc.

FR 17.4 Income Management


FR 17.4.1 Integrates with payment services/platform & 3rd party payment gateway via API or ETL system to ensure seamless process of income.

Refer to Appendix Payment Services /Platform

The CRM needs to be able to manage new addition / changes and removal of payment services / platform easily.

FR 17.4.2 Records regular or single donations that come through Paper Form

FR 17.4.3 Cash batch non electronic payment (Cash, Cheques, Postal order).

Page 64



FR 17.4.4 Automate the process of income receipt, requiring little or no manual intervention by:

Allocating income to the correct financial codes and other coding (e.g source code, product code)

Allocating income to an individual supporter or an organisation so that we know the financial commitment history of our supporter

FR 17.4.5 Allows income to be reversed in an event of error with reason and date captured.

This will include any refund made to supporters.

FR 17.4.6 Record soft crediting of income and is able to visually identify them. Care to be taken on soft crediting to ensure double accounting will not happen in reports.

FR 17.4.7 Query and print out reports to aid in daily and month end reconciliation

FR 17.5 Direct Debit


FR 17.5.1 Store supporter's direct debit deduction date Direct Debit Deduction happens on the 1st, 7th or the 15th of each month

Page 65



FR 17.5.2 Automatically send letter to supporter who has started or reinstate a lapsed direct debit payment with AAUK

FR 17.6 Payment Holiday


Regular donation that require a payment break by supporters. Payment can be through direct debit or credit card.

FR 17.6.1 Put direct debit / credit card / sms payment on hold

FR 17.6.2 Put an reinstatement date to reactivate direct debit /credit card / sms payment

FR 17.6.3 Record reasons for payment holiday

FR 17.6.4 Sets notification/ reminder in-case staff needs to contact supporter to confirm reinstatement of payment

FR 17.7 Lapse Payment & Recovery Process


FR 17.7.1 Manage recovery process via e-mail, phone calls (via agency) and post

FR 17.7.2 Automate the recovery process as much as possible

Page 66



FR 17.7.3 Clearly shows the stage of each recovery process, communication method, reporting success and drop off rate

FR 17.8 Gift Aid


FR 17.8.1 Claim Gift Aid in accordance with the declaration made by the supporter

FR 17.8.2 Records a supporter’s Gift Aid status and provides an audit trail for any changes.

FR 17.8.3 Sets notification/ reminder to reactivate 'Hold' status.

FR 17.8.4 Sets date to change 'Temp' status to 'Withdrawn.

FR 17.8.5 Allows split in Gift Aid claim Necessary when a couple jointly sponsor a child and would like to claim the gift aid separately.

Page 67



FR 17.8.6 Stores all Gift Aid declaration proof against a supporter whether it is a physical paper declaration, confirmation of Gift Aid posted out as a letter, or e-mailed.

System should highlight any supporter that do not have proof stored against their record when their Gift Aid status is reflected as "Active" or reactivated back to "Active" from a "Withdrawal" status.

Gift Aid declaration is applicable for all future donations. Reinstatement of Gift Aid from a withdrawn status require new Gift Aid declaration proof.

FR 17.8.7 Alert staff when Gift Aid Status is "Active" whilst supporter has an overseas address

FR 17.8.8 Differentiates incomes that cannot be claimed for Gift Aid (e.g. Registration fee)

FR 17.8.9 Creates and produces Gift Aid tax claim reports to be submitted to HMRC

FR 17.8.10 Accounts for gift aid that are claimed specifically for a project/programme where gift aid received may become restricted

FR 17.8.11 Delete Gift Aid Records 6 years after the last Gift Aid claim of the individual. Duration should be adjustable in case HMRC changes the time period.

FR 17.8.12 Allow Gift Aid rates to be amendable in case HMRC changes it.

Page 68



FR 17.9 Deeds of Covenant


FR 17.9.1 Record existing deed of covenant and make claim to HMRC.

Deed of covenant are tax relief scheme that existed prior to 2000.

FR 17.9.2 Cancel the individual deeds over time as supporter stop making deed payment or convert to gift aid.

FR 17.10 Gift Link


Gift Link allows supporters to increase their regular donation year on year pegging it to inflation rate.

FR 17.10.1 Records supporters that have agreed to gift link.

FR 17.10.2 Send letter/e-mail automatically to supporter before the next 'anniversary' payment to inform them that inflation increment will take place for their regular donation.

FR 17.10.3 Adjust the regular payment figure automatically at the 'anniversary' month

FR 17.11 VAT


FR 17.11.1 Allows some income to be identified for VAT repayments (e.g. Registration fees for events)

Page 69


Functional Req 18 : Data Protection

AAUK requires a system that can meet legal requirements regarding fundraising and communication preferences. ( Refer to FR 2.2 – Communication Preference for more details.)


FR 18.1 Data Retention


FR 18.1.1 Allows personal data to be erased when a supporter has chosen to protect their data or reaches the end of the data retention period

Personal data are names, contact details, date of birth, bank and card details, social media record, communication history and relationship link to other supporters

FR 18.1.2 Records the reason behind the data deletion (e.g. Supporter request or data retention policy enacted)

FR 18.1.3 Produces a list of where personal data/ communication are held for staff to review and select which data are to be erased.

FR 18.1.4 Allows post code to be anonymised by retaining sector information for future market/campaign analysis purposes (eg AB12 3DE to be reduced to AB12 3)

FR 18.1.5 Retains transaction data when personal data are deleted (e.g. Retain donation amount and date but bank details can be removed)

Page 70



FR 18.1.6 Flags and prevents data to be deleted for legal purposes (e.g. Gift Aid requires Name, Address to be retained for at least 6 years from last claim)

FR 18.2 Data Process Restriction


FR 18.2.1 Records a supporter's 'rights' in how we manage their data and build restrictions around them. Note: a Supporter may have more than one rights exercised.

E.g. Object to being included in any internal analysis, Object to profiling for philanthropic interest

FR 18.2.2 Captures the date when the request is made, a text field to type in what the supporter has agreed to and where changes have been applied

Functional Req 19 : Website and Payment Platform Integration

AAUK currently receives most of its donations via its website and online payment platforms Stripe and Magento (RealPay) which are integrated with the current CRM. AAUK requires a CRM that can integrate well with the website and payment platforms without detriment to user experience and website performance.


FR 19.1 Offers flexible, efficient and highly performant options for 1, 2 and 3-way integration with different systems depending on requirements and dependencies.

e.g. CRM, website, payment platform

Page 71



FR 19.2 Can seamlessly integrate with AA website following best industry practice which would result in a consistent and unified user experience on the AA website.

e.g. any forms which need to be integrated with the website would need to adhere to the standard set by the existing AA UK website, including accessibility, look and feel, and responsive behaviour.

FR 19.3 Able to keep the integrated systems in sync at different intervals and using different methods, as appropriate.

e.g. scheduled or real-time integration; transactional or batch, etc.

FR 19.4 Provides a fit-for-purpose and efficient data transfer between the CRM, the website and third party payment platforms.

e.g. Real-time or scheduled integration should not visibly contribute to website page load or technical performance of the site.

FR 19.5 Can support regular updates to integration endpoints and hence is scalable, well-structured and well-documented.

FR 19.6 Provides a website and payment platform integration which is easy to maintain.

Refer to Appendix B6.1 - Payment Services / Platform

Functional Req 2

Page 72


7. IT & General Requirements


IT 1 Access, inputting, searching data


IT 1.1 Allows for a flexible hierarchy of different access privileges and different profiles for different groups

IT 1.2 Provides the ability for staff to search for and view supporters and other contacts across the whole database

For those with the relevant authorisation

IT 1.3 Supports access and updating of data using mobile phones and tablets

For example, at events

IT 1.4 Has the facility to access information remotely, including the ability to update records and add notes, and for the information to be updated in real time

IT 1.5 Has easily configurable validation tools for data entry (e.g. spell check function) including the ability to cross check different fields.

IT 1.6 Allows staff to scan documents and save the data against records

For example, gift aid declarations

Page 73



IT 1.7 Provides a uniform user experience regardless of location

i.e. London office, Chard office, homeworkers, ‘on the road’

IT 1.8 Ability to use OCR to input data

IT 1.9 Ability to support European language characters

IT 2 System requirements


IT 2.1 Can run on the following environments (OS agnostic):

Windows 10, Windows 365 Mac OS iPhone OS & Android mobile operating

systems

IT 2.2 Supports commonly used browsers e.g. Google Chrome, Microsoft Edge, Apple Safari, Firefox.

IT 2.3 Can be used to accommodate different types of user e.g. light use, reports only, volunteers and regular/heavy users

Suppliers should outline their proposed licensing model.

IT 3 Cloud storage


Page 74



IT 3.1 Runs on both Microsoft Cloud and AWS Cloud. The different storage and compute options available in cloud solution must be explained.

Cloud SaaS service to be explained and shown.

IT 4 Capacity


IT 4.1 Supports a minimum concurrent user base of 150 staff across all access devices (desktops, laptops, tablets and smartphone devices) without any degradation to end-user performance, and needs to be able to scale substantially beyond the user numbers stated in the volume statistics section, should that be required in the future.

Also allow user numbers to be extended if necessary, without significant degradation of performance

IT 5 Localisation


IT 5.1 Has regional localisation based on UK standards including date and time formatting (e.g. DD/MM/YYYY); the system must allow for the automatic adjustment of UK daylight saving changes.

IT 6 Availability, resilience and disaster recovery

Page 75



IT 6.1 The requirement for user access to the CRM system should be assumed to be 24/7.

The system should be able to achieve an operational availability of >99.995% uptime for user access.

It is expected that there may be a requirement for access to be restricted or for there to be downtime during periods of system maintenance/software updates or system backup – planned and agreed in advance

IT 6.2 Suppliers should indicate whether they can provide options around working offline or in circumstances where there might be poor network connectivity for mobile device end-points.

IT 6.3 A complete data backup must be performed every 24 hours without interruption to availability of the system to users.

Backup needs to be undertaken at the transaction level to ensure system can be rolled back in the event of a cyber attack, such as ransomware

IT 6.4 Suppliers should indicate what options exist to support Disaster Recovery in the event of a system outage on the primary infrastructure platform.

IT 7 Security/user access/authentication


IT 7.1 Supports tight integration with ActionAid UK’s preferred existing user authentication method of Active Directory.

Multi-factor authentication (MFA) should be supported

Page 76



IT 7.2 Supports a flexible and granular security model to enable the protection of sensitive data, while extending role-based security access to users across the organisation. Data/transactions should include end-to-end encryption throughout the system as well as on tablet, smartphone and other devices.

IT 7.3 System should allow single sign on as per Active Directory

IT 7.4 Web-based functionality must meet Level AA of the Web Content Accessibility Guidelines (WCAG) 2.0.

IT 7.5 Defines security patching procedures.

IT 7.6 Secures any personal identifiable information (as defined in GDPR) in transit and at rest.

IT 7.7 Allows data and system access based on role and uses industry accepted standard of security for both communication and identity storage.

IT 7.8 Complies fully with AAUK IT Security Policies. Further details can be provided on request.

IT 7.9 Provides a full audit trail of system activity to be maintained.

Page 77



IT 8 Integration


IT 8.1 Open API’s/RestAPI’s/Web Services using industry standard protocols should be available to allow for the creation of deep, automated integrations with other systems that ActionAid UK uses.

IT 8.2 Can synchronise with Office 365

Attaches email and its respond threads seamlessly from Outlook 365 to the supporter record in CRM.

Allows documents from Office 365 to be attached to supporter record in CRM.

Syncs tasks, and appointments set up between Outlook 365 and CRM.

IT 8.3 Integrates with the Data Warehouse Refer to Error: Reference source notfound

IT 8.4 Any imports/exports should be undertaken via an API with minimal manual intervention.

IT 9 Attributes


Page 78



IT 9.1 Allows flexibility in creating attributes to a supporter record.

IT 9.2 Allows reason, requester of attribute to be captured.

IT 9.3 Allows attributes to be mass assigned/removed when required

IT 10 Audit requirements


IT 10.1 Records all accesses and transactions performed (whether by a user or another system) and stores them in a log providing an audit trail of who did what and when.

IT 10.2 Logs and time-stamps all external communications and data changes against User ID to ensure that changes can be tracked and audited.

IT 10.3 Traps and logs failed logon access attempts or multiple attempts to perform unauthorised system functions.

IT 10.4 Provides the ability to monitor and audit performance within the database e.g. that information has been recorded properly, process followed, completion rates, etc.

Page 79



IT 11 Support arrangements


IT 11.1 There needs to be an IT Support model, to include SLAs for:

a) Service levels supporting RPO, RTO defined in NFR_003

b) Service levels supporting Priority1, P2, P3 scenarios

c) Support delivery (2nd, 3rd line, etc)

IT 11.2 The supplier should be able to provide system support during normal IT support business hours (8:30am – 6:00pm Monday to Friday).

Suppliers should also indicate what out of hours / weekend support options could be provided.

Page 80


Appendix A – Context Diagrams & Process MapsThe context diagram (CD) and process maps (PM) chart are appended to support the user requirement.

The context diagram illustrates at a very high level how interrelated modules within the CRM system and 3 rd party system could potentially interact.

The process map is an example set of standardised business processes which it is proposed the new system should support.

Context Diagram 1 – Supporter Creation (CD 1.1) Context Diagram 2 – Child Record (CD 2.1) Context Diagram 3 – Philanthropy and Partnership (CD 3.1) Context Diagram 4 – Campaigns (CD 5.1) Process Map 1 – New Supporter Creation (PM 1.1) Process Map 2 – Child Profile Update (PM 2.1) Process Map 3 – Child Messages (PM 2.2) Process Map 4 – New Child Sponsorship (PM 2.3) Process Map 5 – Child Sponsorship Transfer (PM 2.4) Process Map 6 – Stop Sponsorship (PM 2.5) Process Map 7 – Supporter Correspondence & Gift (PM 2.6) Process Map 8 – Supporter Queries and Complaints (PM 2.7) Process Map 9 – Pipeline and Prospect Management (PM 3.1) Process Map 10 – Challenge Events and First Hand Experience (PM 4.1) Process Map 11 – Community and Group Fund Raising (PM 4.2) Process Map 12 – Trade Products (PM 7.1) Process Map 13 – Payroll Giving (PM 8.1) Process Map 14 – Finance Recovery Process (PM 18.1)

Page 81

Envisage it to be an automatic process from the

CRM system

Likely a manual process that may or maynot interact with

the CRM system

Mix of manual and automatic process from the CRM

system


Context Diagram 1 – Supporter Creation (CD 1.1)

Page 82

Phone Call

Supporter via Agency

Supp

orte

r via

Web

CD 1.1 – Supporter Creation

New Supporter(Check for

duplication)

Sign-up Data

Acknowledgement Letter (Auto)

Payment System

Card

Det

ails

Finance

Direct Debit - 1st Payment

Success / Fail

Supporter

Web

AgencySupporter Admin

Sign-up Data Contact Details Payment Type (Direct Debit / Card) Gift Aid Details Recruitment Method (Code) Other Product Information

Uploader

Supporter

Paym

ent S

ucce

ss

AA Staff

Supporter

Sign

-up

Data

Sign

-up

Data

Telephony Payment(PCI)

Initi

ate

Paym

ent

(if a

ny)

Ackn

owle

dgem

ent

Lett

er (A

uto)


Context Diagram 2 – Child Record (CD 2.1)

Page 83

CRM System

CD 2.1 – CS – Child Record

Child RecordSupporter

Link

Child Profile

Avai

labi

lity

Valid

ity

Child Message

Avai

labi

lity

Qua

ntity

Valid

ity

Supporter CorrespondenceChild Media

(Picture / Video)

Availability

Quantity

Validity

AAI CSM System

Child Information

Supporter & Child Link

Child Profile

Child Media

Child Message (Logistic)

LRPLRP needs to exist

before child from that LRP can be created

AAUK Web


Context Diagram 3 – Philanthropy and Partnership (CD 3.1)

Page 84

CD 3.1 – Philanthropy and Partnership

Donor

Organisation

ORStaff

Empl

oy

Supporter

Research

Proposal

Record Engagement

Phon

e ca

ll

Emai

l

Mee

ting

Even

ts

Info

Network Web

Other Sources

PipelineDonation

Amount

Stages

Date

Link

P&P Activities

AAI Contract Management System


Context Diagram 4 – Campaigns (CD 5.1)

Page 85

CD 5.1 - Campaigns

Campaigner

Engagement Network,Workshop and Etc

Campaign Activities

Action Level

CRM System

Actions

Communication Medium

(E-mail, Phone call)Send Communication

Campaigner Record


Process Map 1 – New Supporter Creation (PM 1.1)

Page 86

PM 1.1 – New Supporter Creation

Supporter sign up on web

Individual supporter sign up through AA staff

Agency recruit

Create customised template before

hand to be given to agency

Retrieve and mass upload csv file in to

CRM

Create record on CRM by staff

Upload record on CRM automatically

Is there duplication?

Yes

Is there financial commitment?

Transfer financial commitment to the existing supporter

record

Yes

No

Handle donation as per existing

suppoter

Delete record

No

Is there financial commitment?

Check for Comms Pref, Gift Aid & Gift Link (when

applicable)

No

Kick-start welcome journey depending on

product taken.

Yes

E.g. Child Sponsorship has its own welcome pack journey

which is different from a Marathon runner.

Check for duplication by

system

Check for legitimacy by Finance Supporter created

Usually one-off donation via online

Single, Regular, CS, GiA, Ambassador Network,

Events

Mass supporter sign up through AA

Upload record on CRM by staff

E.g. Event

Automatically send acknowledgement

letter

Supporter created

These are typically Events, P&P, Campaign supporters

Sign up from Web?

No

Is supporter genuine? Delete recordYes No

Yes


Process Map 2 – Child Profile Update (PM 2.1)

PM 2.1 – CS – Child Profile Update

Check Child Profile Validity

Is child sponsored?

Is profile < 2 years?

Stop

Yes Yes

No No

Update child status to Awaiting

Profileaand alert with notification

Await for child profile update from

AAI

Do not need to send trigger to AAI CSM system as it has an automatic profile update

mechanism

Is child > 12 years old?

Update child status to Retiredaand

alert with notification

Yes

No Is profile updated?

No

Yes

Update child status to Profile Creationa

and alert with notification

Stop

Sync/Download child profile from AAI CSM system

Create Child Profile and save digitalised copy to child record

Update child status to Activeaand alert

with notification

Page 87


Process Map 3 – Child Messages (PM 2.2)

Page 88

PM 2.2 – CS – Child Messages

Receive hard copy CM

Check and update on system for any missing, damaged

CM

Review all CM and redact as necessary

Gone Away supporter do not need physical CM to be

redacted

Send CM communication

package out

Prepare & print tailored supporter

communicationSTOP

Prepare and send report on CM bulk mail feedback to

countries and management

Upload redacted CM & replace

original

Download digital CM in our system

Digitalised Child Messages available on AAI CSM system

Receive Notification on e-mail via AAI

CSM System

Child Message Approved?

(on AAI CSM System)

Recollect child message

No

CM that requires redaction will be approved.

Record reason for redaction


Process Map 4 – New Child Sponsorship (PM 2.3)

Page 89

Yes

PM 2.3 - CS - New Child SponsorshipFi

nanc

eSu

ppor

ter A

dmin

Supp

orte

r Con

tact

New Child Sponsorhip via Website or Mass Upload

Automatically link a child to a sponsor

by system

Is supporter new?

Create basic supporter record in CSM system via API

Update CSM system on the new link via

API

No

Send 1st Welcome Pack

Welcome Letter & Child Profile

1st payment received?

No

Trigger Recovery Process

Recovery process

successful?

Send 2nd Welcome Pack

Trigger Sponsorship Stop Process

No

Yes Yes

Send Welcome Pack Stop

Welcome Letter, Child Profile & Child Message

Letter & Child Message

New SupportersThis process assumes new supporters are already created in the system. (PM 1.1 –Supporter Creation)

LettersWelcome Pack letters are system triggered communication.

These letters can be differentiated (e.g. preference not met; existing supporter; receipt of payment after recovery process)

Is link successful?

Manually link a child to a supporter

No

New Child Sponsorhip via Phone Call

Yes

Key in supporter bs preference parameter

Automatically suggest child by

system

Is supporter happy with child

choice?

Search for child manuallyNo

Yes

Manually link a child to a supporter

& Take Payment


Process Map 5 – Child Sponsorship Transfer (PM 2.4)

Page 90

PM 2.4 - CS – Transfer

Transfer

Is transfer sporadic?

No(Mass)

Receive update notification from AAI CSM system

Yes Is transfer reason cDeathdb

1

Yes

1

Automatically search for suitable

childNo Can a match be

found?

Check with AAI-Country for a child

No

Can a match be found?No

Prepare communication

package

Yes

Send package out

2Yes

Customised letter with transfer reason & Child

Profile

2Transfer Child to UK CRM from AAI CSM

System

Manually link the child to the supporter

Automatically link child to supporter

Ensure Child Profile is generated

Call Supporter to explain Transfer

Manually search for an available child

Manually link the child to the supporter

Prepare & send communication to inform supporter about LRP closure

6 months before closure

Indicate new LRP in system for

replacement

Automatically match new child to

supporter3

3

If supporter canbt be reached, we will pick a child

for the supporter

Record reasons for transfer


Process Map 6 – Stop Sponsorship (PM 2.5)PM 2.5 - CS - Stop Sponsorship

Payment Ceased

Informed by Supporter

Already gone through recover process but

supporter is not contactable

(PM 18.1 – Finance –Recovery Process)

Automatically unlink the supporter to the

child

Unlink the supporter to the

child

Indicate reason for stopping

sponsorship

Generate letter to confirm cancellation

via e-mail/post

Ping AAI CSM sys to unlink child to

sponsor

Does child profile need updating?

PM 2.1 – CS –Child Profile

Update

Change the child status to cAwaiting

Profile/CM b

Yes

No

StopVerbal Recover Process

via e-mail, phone call, post

Change the child status to Hold aand

place a 3 months notification alert

Did supporter re-establish sponsorship

after 3 months?

This is only for phone call. Email and Post do not have a

recovery process.

No

Relink child to supporter and

establish payment routine

Stop

Yes

Request for new Welcome Child

Messageafrom AAI

Is child > 12 years old? No

Change child profile to cRetired b

Ping AAI CSM sys to unlink & retire child

Yes

Stop

Page 91


Process Map 7 – Supporter Correspondence & Gift (PM 2.6)

Page 92

PM 2.6 - CS - Supporter Correspondence & Gift

Receive Correspondence &

Gift

Record receipt in system

Is it correspondence

?

Generate letter stating gift policy

No(Gift)

Donate to Charity Shop Stop

Review correspondence for

safeguarding

Record redaction in CRM

YesYes

Sent via email or post

Is redaction required?

Generate letter informing supporter

of redaction

Record Correspondence on

AAI CSM System

No

Send Supporter Correspondence out

via Bulk Mail PlanStop


Process Map 8 – Supporter Queries and Complaints (PM 2.7)

Page 93

PM 2.7 – CS – Supporter Queries and Complaints

Supporter raise a query or complaint

on child sponsorship

Log issue on CRM System

Does issue needs to be escalated to

AAI?

Log resolution actions in CRM Stop

No

Log issue on AAI CSM System

Yes

Is response satisfactoryResponse recevied

No

Respond to supporter & log in response on CRM

Close case on AAI CSM System

Is response satisfactory?

No

Yes

Close case on CRM system

Yes

Download response from AAI CSM to

CRM system

Stop


Process Map 9 – Pipeline and Prospect Management (PM 3.1)

Page 94

PM 3.1 – P&P – Pipeline and Prospect Management

Is prospect in the CRM?

Create PipelineOpportunity

(Stage 1)

Create supporter record

No

Yes

Research opportunity /

prospects (Stage 2)

Engage prospects(Stage 3 & 4)

Identify prospect

Do we need to work on a proposal?

Is there a realisation of

ask?

No

Do we continue to pursue

opportunity?

Yes

No

Indicate cNot Suitablebon Supporter Record

No

Work on ProposalYes Proposal successful?

No

Record all activities (email,

meeting) against the supporterbs

record

Record findings

against the supporterbs

record

Interrogate CRM database for potential

prospects

AYes

Record proposal success

(Stage 7)

Will prospects provide future opportunity?

No

Close Pipeline

A

Yes

A

Close Pipeline

Yes

Is grant/fund restricted? No

Fill in Income & Pledge Projection

Workflow form

Yes

Close Pipeline

Record on CMS system &

Generate FSC

Prospects refers to donors/corporates that have potential to give.

Opportunity refers to grants/monies that have potential to be asked.

E.g. RBC is a intermediary for several private client. RBC will be a prospect to cultivate. Opportunities refers to the various grants available through RBCbs clients portfolio. Each pipeline refers to an opportunity we are going after.

Ref to CMS if any


Process Map 10 – Challenge Events and First Hand Experience (PM 4.1)

Page 95

Communication journey will be tailored depending on supporter bs payment fees & funds raised.

PM 4.1 – EC – Events with Fund Raising Targets (Challenge & First Hand Experience)

Supporter signs up for an event

Is vetting Required?

Vetting successful? Yes

Yes

Inform Supporter

No

No Is supporter self-funded?

Set them up on a communication

journey (Triggered)

Set them up on a simplified

communication journey

YesReceive monies at

one go or periodically

Participate in Event

A

No

Send final comms and feedback (if

any)End

Check for Registration Fee

Track if Fund Raising Target as been met

Communicate with Supporters

periodically via e-mail or phone

Send welcome journey pack & FR

resources (if required)

Link crowdfunding page to supporters b

event

A

Create Record PM1.1 –

Supporter Creation

Is supporter new?

Yes

No


Process Map 11 – Community and Group Fund Raising (PM 4.2)

Page 96

PM Ϯϰ – EC – Community and Group Fund Raising (School, Corporate, Individual)

Supporter register for a FR initiative

Set them up on a communication

journey

Receive monies at one go or

periodically

Send final comms and feedback (if

any) after FR Initiative

End

Send welcome journey pack & FR

resources (if required)

Link crowdfunding page to supporterbs

FR initiative(if any)


Supporter Creation

Is supporter new?

Yes

No


Process Map 12 – Trade Products (PM 7.1)

Page 97

Supporter purchase product online

PM 7.1 – Trade Products

Receive and record payment

automatically

Is supporter new?

Create RecordPM 1.1 -

Supporter Creation

Yes

No

Product Variation 1) Web Download : No physical mail out required. Message and card will be e-mailed to purchaser.

2) Card Only : Mail card out as it is. No personalised message required.

3) Personalised Card: Personalised message printed on card and mail out to intended recipient.

Are the cards web

downloaded?

Supporter purchase product via call

Supporter purchase product via paper order

Receive payment (PCI Compliant)

Is supporter new?

Create RecordPM 1.1 -

Supporter Creation

Yes

No Record product order into form

Payment to be recorded if via paper order

Send acknoledgement e-

mail and include card download

Yes

Stop

Is there personalised

message?

Print Invoice out

No

No

Send order acknowledgement

e-mail

Yes

Send Cards out with Invoice

Update inventory Stop

Print cards out with personalised

message

A

A Send card outEmail to supporter that card has been

sent out to recipient

Personalised message cards only come through web

order

Stop


Process Map 13 – Payroll Giving (PM 8.1)

Page 98

PM 8.1 – AQ – Payroll Giving

Receive payroll giving from agency

Is there new supporter?

Yes

Is there contact details?

Could be via Upload or API

No


Supporter Creation

Yes

Create anonymous recordNo

Record payment Stop

Is there lapse payment? No

Yes

Has it been 3 cycle? No

Remove supporter link as a payroll

giver

Yes

Create both supporter contact & company contact

(if required)

Are there changes in

details?No

Amend Records

Yes


Process Map 14 – Finance Recovery Process (PM 18.1)

Page 99

PM 18.1 – FIN – Recovery Process

Lapse Regular Payment

Send customised interactive

email to supporter

Child Sponsors, Regular Givers will receive different emails

Did supporter respond after 5

days?

Yes

Available supporters telephone number &

consent?

No

Send list for recovery to AgencyYes

Continue with payment?

Update supporter record to break

product & payment link

Stop

No

Payment detail changes?Yes Update Details YesA

Web interactive or mass upload (agency)

A

Agency update with response

A

Did supporter respond within 4

weeks?Yes

Agency update with cNobresponse

received

No

B

Available e-mail address & consent?

Yes

No

Send customised e-mail/post to confirm reinstatement & detail updates (if required)

StopYes

No

Available postal address?

B

No

Send letter to supporter to call

Supporter ContactYes

Did supporter respond within 4

weeks?

No

YesUpdate details on CRM by Supporter

Contact

Stop

Is this the 3rd e-mail contact?

No

BYes

Was there e-mail consent? No

CNo

C

Is this the 2nd post?Yes

No

Send 2nd e-mail Yes

Was there e-mail consent?

C

No

D

D

Yes


Appendix B – Elaborations & Examples

B1 Supporter Record and Relationship ManagementB1.1 Supporter/Organisation Classification

To be able to maintain a full picture of any supporters’ details, relationship, and engagement.

B2 Child SponsorshipB2.1 Child Record

The following fields are required but not limited to:

Description RemarksChild Reference NumberNameAgeGenderLRP LRP the child belongs to. LRP must already be set up in the

system. Country & Region Country the child belongs to. Country must already be set up

in the system. Ability to self-populate given LRP information.Date Joined Date the child ‘joined’ AAUK Type Marketing/TransferStatus of Child Active – available for sponsorship

Away – put aside for external marketing (e.g with agency) Sponsored

Page 100


On Hold – Put on hold (require an activation date with reminder)

Awaiting Profile/CM – Waiting for profile or child messages from AAI

Profile Creation – Child is with us, profile is in the midst of being created

Withdrawn – No longer available for sponsorship (require reasons to be stated)

Retired - Child is not sponsored and reach the age of 12 Deceased

Supporter LinkSponsorship/Transfer History Show sponsorship & transfer historyNotes Column for free text.

Ability to date stamp and record who made the comment.

B2.2 Child Profile – Mail Merge System

Child profile text comes from 2 sources:

LRP information pack that is provided by AAI at the start of LRP commencement Child profile content (CPC) that is provided when a child is assigned to AAUK

The CPC would likely be a csv file with predetermined fields that are the same for all children. However, it is the LRP information that will drive the text on the child profile.

The mail merge system also needs to be able to manage gender pronouns (him/her) and is able to pick certain text based on conditions (e.g. age driving education information).

Sample of how mail merging should function:

Code Type ExplanationYellow Child Name Picked up from child profile content (CPC) Red Pronoun Picked up from CPC that the child is female.Green Family Home Paragraph 3 refers to home information. CPC will indicate

that the child stays in a ‘Zinc’ type home. Then LRP information will dictate the write up in green.

Someone who stays in a mud home will have a different write up.

Someone who stays in a Zinc home from a different LRP will have a different write up too.

But someone who stays in a zinc home in the same LRP will have the same write up.

If someone who stays in a home type that isn’t in the LRP information pack then a generic Paragraph 3 will be displayed such as ‘homes in the village are predominantly made of XX’

Blue Education This is a conditional text based on CPC information

Page 101


whether the child goes to school and what age they are.

E.g Age > = 7 not attending school; Age >= 7 going to school; Age <7 not attending school, Age < 7 attending school will warrant different text.

The remaining texts are consistent for that LRP. Each LRP is unique and will have a different write up.

BEFORE AFTER

Sample of a finished child profile. (Do note that this is how a child profile looks like now but would like flexibility in changing the layout or create more personalised profile addressing to the supporter.

Page 102


B2.3 Child Message Inventory Requirement

A child may have more than one child messages in their record. For each child message record we need to track the following:

CM Batch Number Digital Copy saved Approved date Date it is sent out from Country Date it is received from AAUK Indicate if CM has been:

o Redacted Ability to pick reason for redaction

o Rejectedo Missing

Date send out to supporter

B2.4 Child Message (Bulk Mail) Sample Report

B2.5 LRP/ Country Requirements

The following are required for Country / Country Region Set up

Country Name and Country Code (aligned with AAI)

Page 103


o Preferably created on a sperate table so that when Country Region/ LRP is set up, country can be a drop down list.

o Start/End Dateo Inactive Tag (can only be made inactive when all associated Country Regions are

inactive)

Country Region Name and Country Region Code (Aligned with AAI)o Preferably created on a sperate table so that when LRP is set up, country region can

be a drop down list. o Start/End Dateo Inactive Tag (can only be made inactive when all associated LRPs are closed)

The following are required for Country / Country Region Set up

LRP Name and LRP Code (aligned with AAI) Country/ Country Region (pick up from drop-down list) Status

o Drop down list

Status RemarksActive LRP is active. Phase Out

3 years phase out. Children with ‘Active’ status within the LRP will be automatically put on ‘withdrawn’ status.

Indicate new LRPs which will ‘replace’ this LRP when managing transfer.Could have more than one LRPs.

On Hold

Children with ‘Active’ status within the LRP to have their status put ‘On Hold’ with an reinstatement date to be reviewed.

Closed

LRP closed. No active sponsorship link available.

LRP Start Date Funding Source Code associated to the LRP LRP Closure Date Capture Reason for closure LRP for preferred marketing (tick box enabled)

B2.6 Matching a Child to a Sponsor

In a new sponsorship, the system must be able to automatically match a child to a sponsor according to the following parameters:

Supporter preferenceo Age o Gendero Country

LRP prioritised for marketing (if enabled) Child message & photo availability Child profile

o FIFO – Profile that has the shortest shelf life left

Page 104


Note: Every child’s profile has only 2 years shelf life before it needs renewal

B2.7 Matching a Child to a Sponsor in a Sporadic Transfer

In a sporadic transfer, the system must be able to automatically match a child to a sponsor according to the following:

Find a child from the same LRP preferably the same gendero If the LRP is being phased out look for a child in the ‘replacement’ LRPs

If there isn’t an available child in the LRP, find a child from the same Country preferably the same gender

In both scenarios, child profile must be available In both scenarios, pick the child’s profile that has the shortest shelf life left

B3 Philanthropy and Partnership (P&P)B3.1 Pipeline Status

The 7 stages of pipelines are as follow:

Stage 1 – Identified Stage 2 – Researching & Evaluating Stage 3 – Trying to Engage Stage 4 – Prospect in Engaging Stage 5 – Read to Ask/ Preparing Proposal Stage 6 – Proposal Submitted/Asked and Waiting Response Stage 7 – Successful

B3.2 Correspondence & Activities Recording

The following are required but not limited to:

Description Remarks Subject TitleType of Activity Ability to classify the following:

Task E-mail Phone Call Video Conferencing Meeting (Face to Face) Events Instant Messaging (e.g. Whatsapp)

Category Categorise the type of activity further. E.g. Kick off Call, Follow up Call.

Flexibility in creating this list is required. Date / Time / DurationLocation of MeetingAttendees Ability to pick up names from CRM, Staff Directory, or simply key in

a name if they are not in the CRM/Active Directory. Notes

Page 105


Attachment Ability to attach document to an activity recordB3.3 Prospects Research Findings


Description RemarksDate researched Able to chart when research work was done

KPI reporting GDPR – need to delete data within 30 days if cold

prospectPrimary Source Indicate how we got to know the prospectResearch Sources GDPR – able to point to where we got research data from.

Prospect Research Notes Free Text to key in information about prospectsPhilanthropy History Ability to record

Month/Year Amount Recipient Name

Interest Area Ability to select from a category of interest area. (e.g Education, Poverty)

The categories need to be easily managed and build up.

Geographical benefit Selection Geographical Interest Country & Region

Rating – Ability to give Rating using Alphabet Rating – Contactability Rating using NumberRating Summary Totals numerical ratings (Alpha Numeric)Emergency funder Yes/No/UnsureComment/Analysis Free Text for additional notesBelow list unique to Corporate requirements:Factory list Free Text; if possible to be able to include weblinksMemberships Free Text; if possible to be able to include weblinksModern slavery statement Free Text; if possible to be able to include weblinksCorp foundation Yes/NoControversies Free Text

B3.4 Proposal/Ask Management


Description Remarks Name of ProposalDateStatus Drop down menu to pick the following status:

Proposal Preparation Sent & Waiting Decision Accepted Declined

Page 106


Declined & Accepted Alternative No Response

Capture Date when status has changed Type of Gift Drop down menu to pick the following type of gifts:

Co-Financing – Multi Year Co-Financing – Single Year Multi Year Regular Annual Gift Single Year and Etc.

Amount AskedMatch Amount (if any)Date AskedProbability factor % chance of winAmount GivenCMS Ref Reference on Contract Management System

B3.5 Donation Pledging

Donation pledges could be committed in various form. The system needs to be flexible enough to record them for accurate projection.

Fixed amount over a certain period Fixed amount allocated by % over a period Regular amounts with no end dates Donors matching an amount that AAUK raised (in this case projection may be required) One-off donation

B3.6 Income Tracking Form

Page 107


This is the current income tracking form that should be replaced with a digital workflow form in the new CRM.

B4 Events & CommunityB4.1 Customised Stewardship Journey

Illustrates how two London Marathon runners will have very different journeys. The one that comes through the charity will need to be vetted first, registration collected and ensure that fund raising targets are met. Whereas a runner who manage to get a balloted place from the organiser itself will require a much simpler stewardship journey and may receive fewer communication from AAUK.

This customised stewardship journey will have different triggered communication for the supporters; different trigger notification for staff to manage the supporter.

Page 108


B5 Legacy B5.1 Type of Dates to capture

For each legacy case, there are a few dates that are mandatory to capture which should be provided for each case.

Date of Death Date of Last Will Date of Probate Date of Codicil Date of Notification Date of Case Closed

B5.2 Type of Legacies

Each Legacy type will have their own estimation calculation

Type of Legacies Estimation MeansPecuniary Estimated figure is provided by Smee & Ford Notification, Will or

notified by Executor. Conditional cases should be indicated clearly and will not be

accrued. Reviewed yearly

Specific Estimated figures provided by the executor. Allows for % deduction to account for expenses Reviewed yearly

Residuary Estimated figures provided by the executor. Allows for % deduction for accuracy in projection Conditional cases should be indicated clearly and will not be

accrued Reviewed yearly

Life Interest Trust Estimated figure is provided by Smee & Ford Notification, Will or notified by Executor.

Allows for % deduction to account for expenses Life tenant presence will determine if case should be accrued Case to be reviewed every 3 years

Discretionary/ Estimated figure is provided by Smee & Ford Notification, Will or

Page 109

Description Challenge Event: London Marathon

(Charity Place)

Challenge Event: London Marathon

(Self-Ballot)Means of Fund Raising

Fund Raise Self or Fund Raise

Registration ü(VAT)

-

Vetting ü -FR Target ü -FR Amount ü üRunning Vest ü ü


Income Trust/ Royalties

notified by Executor.

B6 FinanceB6.1 Payment Services / Platform

Following are list of current & planned payment services/platform that would require integration:

Access Pay/BACs – Direct Debit HSBC – Standing Order Stripe – Credit / Debit card, Apple Pay, Google Pay PayPal IVR telephone Payment – Credit /Debit Card Just Giving – Online fundraising platform Virgin Money – Online fundraising Platform Agencies – Payroll, SMS, tele-marketers

Note: The payment services /platform may change at the time of development

B6.2 Gift Aid Status

The following are assigned to track supporter’s Gift Aid declaration status:

Status DescriptionActive Gift Aid declared. Claim is active and live.Hold Gift Aid declared but hold and claim till reactivation.

(Reminder/Notification required)Temp Gift Aid declared but claim to proceed till a certain date and then withdraw.Withdraw Gift Aid claim stopped and no longer active.NA Gift Aid has never been declared or a supporter has indicated ‘No’ to gift-aidDonation Led Supporter will inform AAUK on the gift aid status & value for each donation.

B7 ReportsB7.1 Reporting Levels

It is expected that the CRM is able to perform Level 1 type of reports and feed into the data warehouse to support level 2 & 3 reports

Functionality Source Who Example question

Level 1 Basic querying and selecting of data

CRM All staff Show me a list of all the supporters who have signed up for the London Marathon

Level 2 Parameterised Power BI reports Standard reports Show me the

Page 110


management information reports

pointing at data warehouse

created by analytical resource but are interactive so all staff can change key fields eg. Event, type of supporter etc.

income raised from the London Marathon by year over the last 5 years

Level 3 In depth data analysis, data modelling, data visualisations

Power BI, querying and visualisation via SQL, Python etc. using data warehouse

Senior analytical resource in data warehouse team

Show me the probability of an eventer going on to participate in other types of support for ActionAid and what is the tipping point in terms of asks resulting in a positive outcome

Page 111


Appendix C – Data Warehouse

C1 What is the ActionAid Data Warehouse?

Like almost every other organisation of any size, ActionAid uses many computer systems, many applications, to operate its business. Many of these applications have their own data stores. The data stores hold much of the same data, but in different formats and using different technologies: databases, spreadsheets, text files, XML files, and in external data sources that may be accessed using APIs or by downloading files.

ActionAid, like other organisations, needs to look across all its data sources, so that it can carry out analyses to improve its performance in many areas, including fundraising, campaigning, supporter relationships, delivering to its beneficiaries, and reporting to official bodies.

Collecting data from many source systems, for each report, is extremely inefficient, so the Data Warehouse exists to pull all the data together. The data warehouse stores the combined data in a structure that represents what ActionAid does, rather than being focussed on supporting just one function, as each application is. Reports then become simpler and more consistent.

Each of the applications has its own version of the truth and that means there are inconsistencies. The data warehouse automated load process applies rules to resolve these inconsistencies and give the most reliable single view of the whole data landscape. The rules are developed painstakingly as the automated load process is developed, with input from interested parties to get the best compromise.

Every application also has data quality issues of its own. The impact of these is compounded when data is combined from several not-entirely-reliable sources. (Most sources are over 97% reliable, but the few percentage points of error cause disproportionate extra work.) It is the job of the data warehouse automated load process to resolve these issues too. First, these issues have to be detected, then the data warehouse team has to find the most effective way to resolve them. Ideally data quality issues are resolved in the source systems, delivering benefit to the users of the source systems and to the users of the data warehouse. Where this is not feasible, more painstakingly-developed rules are applied in the data warehouse to clean the combined data before making it available to users.

When all this is done to the best level achievable with the resources available, then the data warehouse becomes a trusted source for reporting, as well as being one that is easy to use.

Page 112


The process of loading data into the data warehouse, and keeping it up-to-date, is through tested, automated scripts, with no human intervention. It runs every night, loading data as at the close of business on that day.

The data warehouse does not update any other system, although information from the data warehouse may be used by the owners of the source systems to improve the data that they control, using the applications that own and maintain their source data.

C2 What the Data Warehouse Does and Does Not Do

In order to get the best performance and functionality from the operational systems and from the data warehouse, and to minimise costs, there must be a very clear separation of responsibilities. Without this separation, duplication of effort and inconsistency of data spread throughout the systems.

Operational System (for example the CRM)

Data Warehouse Reason

Automates and assists in the operation of ActionAid.

Captures new data about current activities, usually as they happen. (An example would be registering a new supporter).

Has ultimate responsibility for the data it collects and manages.

Is the only source for data that comes from multiple applications.

As a result, the Data Warehouse is the best source for organisation-level and cross-functional reporting and analytics.

This also makes the Data Warehouse the best source for data to populate new applications, such as the new CRM.

Building and maintaining links from each application to all the others that contain relevant information would be very costly. Costs would be incurred by applications not only in dealing with multiple interfaces, but also in resolving differences.

Is the System-of-Record for the data that it collects and processes. For example, a formal audit of donations would be carried out in the CRM; not in the data warehouse, because the CRM will be the entry point for all donations.

Is never the System-of-Record The data warehouse always derives its data from operational systems, not from interaction with supporters. etc.

When checking critical data one should always go back to the system that captured it.

Has full control over data entered and should apply relevant validation to ensure that the data is correct and that it links correctly to other records.

Is never used to update an operational database.

This means that the data warehouse must not be used to plug gaps in operational system functionality. Instead, the operational system must be enhanced to cover any needed functionality that updates the operational system’s data.

The data warehouse cannot reproduce, and keep up-to-date, all the validation that each operational system should apply to data it captures. Any attempt to do this would be very costly, and never perfect.

Page 113


C3 Interfaces Between Data Warehouse and CRMC3.1 Before CRM Goes Live

Before the new CRM goes live, the data warehouse:

collects data from the old systems restructures this data into a data model that reflects the operations of ActionAid, rather than

the functions of any one application combines data from multiple existing applications cleans the data in various ways

o applies consistent formatting ruleso discovers inconsistencies between systems and facilitates resolution of these

inconsistencieso detects invalid values and fixes them automatically where possible, or refers them to

ActionAid staff who can fix them in the source systems, or help to develop rules to fix them.

The data warehouse will then have the best consolidated version of ActionAid’s data. This will clearly be the best source to populate the new CRM initially.

Page 114


C3.2 After New CRM Goes Live

The cutover to the new CRM will coincide with the decommissioning of Infobase and, Raiser’s Edge. The departmental applications that are decommissioned will be those that are simply patches to overcome shortfalls in the functionality of Infobase, caused by the increasing difficulty of keeping a 22-year-old system up-to-date, with minimal resources.

The major source for the data warehouse and several of the less significant sources will therefore disappear and the feed for data that has come from those sources up until cutover must immediately be replaced by a feed from the new CRM.

C4 Data Flows between the CRM and the Data WarehouseC4.1 Implementation Approaches

The data flows between the CRM and the Data Warehouse will be defined by the CRM project.

There are many methods of achieving these data flows. Some of these are more costly and some are less so.

Method Direction Cost Description

Direct SQL access, read-only

Data Warehouse to CRM

(data migration)

Low The data warehouse creates the data in an agreed set of database tables, in a schema or database defined by the CRM project. The CRM reads these tables to populate its own internal database.

Direct SQL access, read-only

CRM to Data Warehouse

(after cutover)

Lowest The data warehouse reads data from the CRM tables. No impact on CRM development work. Minimal impact on CRM operation; tables are read at night when the system is quiet.

Page 115


Method Direction Cost Description

“csv” files Data Warehouse to CRM

(data migration)

Low Each file will contain the data requested by the CRM project.

The data warehouse creates the files and puts them in a defined place where the CRM can read them.

“csv” files CRM to Data Warehouse

(after cutover)

Low Each file represents a table.

The CRM creates the files and puts them in a defined place where the data warehouse can read them.

“XML” files Both directions High Not recommended

“API” Both directions Highest Not recommended

C5 Working Together – The Data Warehouse and the CRMThe Data Warehouse and CRM projects fall under a single CRM programme of work that is overseen by our Development Workstream Manager. We have talked about the separation of responsibilities. At the boundaries of those responsibilities the two projects work together to ensure that the interfaces work for both parties.

This means agreeing the mechanism for each direction and then agreeing the precise data specifications.

The data specifications must identify every file, database table or message, and the content of each of those objects:

the object format (database table, csv file, XML file, API message) the name of every field the meaning of every field1

how fields are identified in the data feed (by position in the record, or by name) the data-type of each field, including maximum length, number of decimal places for

numbers, format for dates and timestamps whether the field is mandatory or optional valid data ranges or lists

Having worked with the Infobase data we have data profiles for each table from Infobase that we are using. We have used those data profiles to inform further research into each field. We will do the

1 Such documented meanings are often useless, such as “Supporter surname: the surname of the supporter”. Useful information would be “may contain one surname, or more surnames if donations are from a small family group, a grandparent and grandchild, for example”. The meaning should be useful or blank if it is completely unambiguous.

Page 116


same for other sources - first Raiser’s Edge and then any others that need to have their data represented in the new CRM.

This information should be useful to the new CRM project and is completely open and available to the CRM team.

C5.1 Data migration

We are planning for the Data Warehouse to be the vehicle for data migration to our new CRM platform. The Development Workstream Manager will oversee this process, working closely with both the Implementation Partner, and the Data Warehouse team. We are keen to utilise the expertise of our chosen Implementation Partner to ensure that this is a successful exercise, as we know that Data Migration is one of the most critical and risky tasks in this type of programme.

C5.2 Nightly Data Feed from the CRM to the Data Warehouse

The CRM supplier must make it possible for the data warehouse to collect all the CRM data, every night. The possible mechanisms are described in Data Flows between the CRM and the Data Warehouse.

The volume of ActionAid’s data is small enough that we have been able to copy full data sets every night. It would be acceptable to receive changes only. This would make the transfer of data much smaller and therefore much quicker. However, detecting changes, and ensuring that none are missed, adds complexity that is not necessary. Using computer power that otherwise would be idle at night-time is a lower-cost solution.

Page 117


Appendix D – Glossary

Term Meaning AAI Action Aid InternationalAAUK Action Aid United KingdomCMS Contract Management System

System used by AAI to manage restricted funding contracts

Note: Not to be confused with Web CMS – Website Content Management System

CPE Campaign, Policy and EngagementCS Child SponsorshipCSM Sys Child Sponsorship Modernisation System

New CSM System is used by AAI to manage CS on a global levelFA Funding Affiliates

Countries that raise fundsFSC Funding Source Code

AAI codes for restricted funds

IG Individual GivingDonor that gives less than £5k a year

LRP Local Rights ProgrammeA group of communities that AAI support within a country

MG Major GiversDonor that gives more than £5k a year

NK System Old child sponsorship system that will be phased out end 2020. Replaced by CSM system

P&P Philanthropy & PartnershipPG Principal Giver

Donor that gives significant sum of moneyRE Raiser EdgeSupporter Anyone that supports AAUK whether financially or through other meansWeb CMS Website Content Management System.

Note: Not to be confused with CMS – Contract Management System

Page 118

Documents

ActionAid UK · Web viewActionAid UK is the largest funder of the ActionAid Federation, and as such plays a key role in the federation’s global fundraising. ActionAid UK is dependent