From Our Partners: Making a Database Work for You

Share This Post

This post first appeared on the website of our partner organization, Zacchaeus 2000. Z2K’s work focuses on helping vulnerable debtors and addressing the causes of poverty through individual cases, lobbying for improvements to the legal and benefits system in the UK, and providing training to volunteers and NGOs in helping others in this area. Written by Lilian Lee, Z2K’s IT coordinator, the post gives a great overview of key components of a successful data system implementation. 


I mentioned in my previous blog that we were implementing a casework database system and that I would share how it has improved the way we work. Below are some of the benefits of having an electronic database:

  • The data system enables us to easily assign and manage volunteer tasks. Most of our caseworkers are volunteers, and, depending on their personal schedule, they come in once or twice a week. We made sure the database helps our volunteers manage their cases so there is continuity in the casework. In the past, we used emails and Outlook tasks to manage cases, but this proved inefficient, and there were times when emails and tasks went “missing” in the inbox.
  • The system enhances continuity in volunteer work. The database allows us to assign tasks to a volunteer such that, when volunteers log into the system, they can see their tasks by their own volunteer page. They can also see what other caseworkers have done on the case during the period they were not in the office. Our volunteer coordinator can now easily see all the tasks that the volunteers are working on.
  • We now have a systematic way to manage case enquiries. The database makes it easy to track the progress of the case from enquiry to the client’s first appointment with us by changing the status of the case.
  • Reporting outcomes is much easier. I can now quickly report how many new clients we have, track the results of issues resolved, record how much we help our clients reduce their debt, and so on.


However, a system is only as good as we make it. Here are some lessons I have learned about successfully integrating a data system into the work processes of an organisation:

  • Someone must be responsible. You do need a team or a person to project manage the database implementation and integration. Otherwise, it will not happen. Implementations require change, and it takes time and resources to implement change.
  • Support from all levels is crucial. Everyone in the organisation, from the management to volunteers, must support the project and devote time to the database implementation. We spent hours on requirements gathering, where staff and volunteers had to explain what they wanted the system to do. When the system was implemented, we spent time uploading existing cases, and we had to make time to learn how to use the system.
  • It never ends. Successful implementation is not the end result. A database is part of your work process, and it has to be maintained. Ongoing training on database use for staff and volunteers, constant tweaking to the database so it’s kept up to date with current work processes, rectifying incorrect data input, and producing reports all require work.
  • The database must be flexible enough to adapt to your work processes. I believe that technology is a tool we employ to help us be more efficient, so the database you choose must be flexible enough to enable that efficiency. For example, we always start requirements gathering by thinking about what we want to achieve and report on, and then build the database to suit that need. The volunteer task is a good example. We recognised that most of our caseworkers are volunteers, so we decided on a database that could manage volunteers as well as casework. We did not choose standard out of the box casework system that cannot accommodate volunteers.
  • Good data requires discipline, training, and patience. The user must be disciplined in ensuring the right data is entered into the database in order for the system to work. It’s the same whether it’s a paper based database or an electronic database.
  • The user must be willing to learn. Electronic databases are always improving. There will always be new features that make “work” easier, but we naturally prefer the more comfortable the status quo until we can see how the change will benefit us. Again, someone must be responsible for the database – that person will test new features to see how useful they are and encourage others to use them.
  • Choose a vendor who is able to understand your work. I didn’t realise how important this is until we started the requirements gathering stage where we had to explain every single thing about how our organisation works and how the benefit and legal systems work. Thankfully, the vendor we work with, Vera Solutions, had no problems understanding our requirements and why we do certain things in a certain way. They were able to see what we wanted to achieve and plan the system accordingly.

Related Blogs