Karuna Trust

Karuna Trust is a Buddhist organisation which has funded philanthropic projects within India since 1980. These projects include literacy classes for adults, slum kindergartens and educational hostels.

Before appointing thankQ, Karuna used a combination of DOS based ALMS and Visual ALMS to manage donor and mailing processes. Grants allocation and management was handled separately, principally through the use of spreadsheets.

Karuna wanted a fast, user friendly, cohesive interface that was powerful enough to handle large amounts of data. Karuna chose standard thankQ functionality with a few bespoke modifications, adding grants and payment processing modules to handle and integrate other business functions.

Karuna is a small-medium sized charity working mainly in India with some of the world’s most impoverished people coming from the Scheduled Castes and Scheduled Tribes. In 2009 we raised a total of £1.5 million, of which about £850,000 was donated by individuals. Our main fundraising method is collecting Standing Orders and Direct Debits door to door, so our CRM system is critical for managing our relationships with our 7,500 regular donors.

We also use the CRM to track donations, claim Gift Aid, produce mailings, and control the Direct Debit claim process, so it has to be right. Furthermore we use the software to process/manage our overseas project partners, international grant payments, institutional funding and legacies. This means that the CRM (along with our separate accounts package) is really the core data source for our whole organisation.

The process started as a result of a strategy review with all staff and trustees. I made a presentation about the need to strengthen our internal administration to enable the charity to grow. As a smaller organisation our way of doing things was based around spreadsheets and separate systems, including CRM data being stored in email clients, email itself, our donor CRM and another CRM product. As the charity grew so did the number of contacts and the complexity of our spreadsheets! The reporting capabilities of our donor CRM were also extremely limited. This meant that we were spending all our time getting data into and out of many different sources – some of which involved manual collation. As our activities became more complex the amount of administration to keep track of them all was starting to grow exponentially.

I proposed a complete systems review, with the promise of being able to produce up-to-date reports at the touch of a button. If it were any more difficult than that we were doing it wrong. This process of course was a monumental task and is still ongoing in several areas. It involves a degree of technological change, and because it affects nearly all areas in a working charity it needs to be done in phases rather than as a rip-and-replace operation. The most major phase, which we have now completed, was to upgrade the CRM.

Our CRM was nearly 8 years old and had not been reviewed or worked on it since the Go-Live date. Given the amount of bespoke work we wanted, it was going to cost us nearly the same to upgrade as it was to switch to another supplier. We did not take the decision lightly. The key advantages of upgrading were that we had a great relationship with thankQ, less re-training would be needed and the shortcomings in the old version seemed to have been redressed. We did not in the end carry out a tender process. The upgraded version delivered what we wanted at a reasonable cost, and for that reason, along with our close relationship with thankQ, it made sense not to delay.

thankQ runs a user group each year and I would highly recommend taking the time to go to this type of event every year if available. Seeing newer versions of the system in action along with networking with other users about how they do things - their gripes, and their triumphs - we get an ongoing sense of how we can improve in practical terms and an influence on the future direction of the product.

During the specification phase I tried to bring our business processes into line with the new CRM as far as possible. This minimised the amount of bespoke work needed and hence development costs. We purchased a new server and asked thankQ to install their standard product on it so that I could really experiment with the capabilities of the system before committing to a fixed specification.

The upgrade process went live just one week after the provisional project plan said it would. I spent a lot of time testing and discussing issues with thankQ. We had a one month period using the old database as the live system and the final release of the new database as a test system. Once we were happy enough to go live thankQ re-ran the data transfer. Having our new server at this point was great. It meant that we could just leave all the old system behind, knowing that it was still there if needed.

Technologically speaking, the main learning was that not upgrading fairly regularly is a false economy. Leaving it so long made migrating some of the data more tricky than it might have been. We had some entirely bespoke functionality in the old version that we rebuilt on top of standard functionality in the new version. This means that future upgrades will be far quicker (and cheaper) in terms of development time.

I did a lot of overtime during this period. The main cause was that we did not anticipate what a huge impact the changes would have upon the resources available for activities. We sent a newsletter out to our supporters a few weeks before and of course cheques were pouring in at the time we were trying to do the upgrade. We also had a door to door campaign going and a phone campaign starting two weeks after the live date. It is possible to run activities during an upgrade, but in future I would want to leave 6 weeks either side for all but the most essential activities.

The technological change was easier than establishing a change in culture. In order to automate our systems we need our data to be accurate, complete, and entered in a timely fashion. This can sometimes set up a conflict between the method a member of staff feels is the quickest way to do their job, and the method that will be of most benefit to the charity overall. For example, when adding a contact to the database it is tempting to add only the details that seem necessary. Whilst this may be an expedient way to process donation forms, it means that when we want to later establish the gender balance, or age demographic of our donors we simply cannot do it without going back to each record and amending it. With hindsight this requires the management team to be fully on board and involved in the process, which is the major mistake that I made.

Whilst our management team was behind the process in theory, I sometimes found it difficult to engage them fully in the process. As team leaders I really needed their input on key specification decisions. When it came to the testing phase - and even after going live - I found that some things that had been agreed in the specification phase hadn’t actually been considered as deeply as they might. As a consequence we needed several last minute changes which cost us over and above the estimated cost. If I were to go through this process again I would involve the management team far more in the process of producing a detailed specification. As it was I asked questions when needed, when I should have given demos and asked how they saw things working. I also did too much to try to keep to the project deadlines, rather than letting the management team motivate themselves and each other by realising the consequences of delay. Most of the time I met one to one with people; I would now insist on having a weekly session with the management team to check on progress and issues.

After going live, the training really helped to increase buy-in. Once people were able to design and run reports there was a degree of excitement about new possibilities. I really wish that I had done more demonstrations, or asked thankQ to come and demonstrate to the whole team. The formal training was of course just the beginning. I am now running workshops and tutorials to help bed-in the database, and bit by bit we are really starting to make a difference to how we work here in the office and to how we communicate with our supporters, fundraise and support projects overseas.

With the upgraded CRM, reports that used to require an hour of data manipulation in Excel are now delivered direct to the user in real time as soon as they log in. We can log emails to a supporter direct from outlook, and scan incoming letters direct from the CRM. We have only just begun to explore the potential of mailing our donor base with letters tailored to the individual on the basis of any database field. In the old version we were using perhaps 75% of the features, and having to find workarounds for many features we needed but didn’t have. That really was telling us that the solution wasn’t working. People would come to my desk saying “we need to do this new thing”. I would reply “it can be done, but it’s complicated”. Now people ask me and I say “well, you can do it in one of three ways... ”.