Do fundraisers ever really create queries themselves in fundraising databases?

 

Almost all fundraising/CRM software suppliers promote the fact that a key benefit of their system is that fundraisers and “end users” – i.e. non-database/data-savvy/IT staff – can create their own, especially ad-hoc, queries and reports. And I have always wanted to believe this – and often I do! But is it really the case? Surely it must be possible in 2012 – mustn’t it?

Yes, sometimes
In some organisations I have worked with, it does happen. It tends to be in smaller charities where they don’t have much of a dedicated database/IT team anyway, or where an organisation is fortunate that they have got a fundraiser who “really gets databases” and is comfortable with queries and reports, and who can thus do such work. But sadly, this can be rare.

But it does depend…
Of course, much of this does depend on the complexity of the query required – the question the fundraiser wants to ask – the reason for the question and of course the ease-of-use of the software itself. I know a number of packages where to do comparatively simple queries, many fundraisers are indeed able to use the software’s query/report functionality to do this. And if it is a comparatively simple question such as, say, How many individuals live in London, or how many people have given a donation in the last x months, then that is viable.

Of course, the more pedantic of my readers will – quite rightly! – point out that even that requires some thought; e.g. what if a database stores multiple addresses for individuals, do we really want all individuals, what about deceased/gone aways, and do we mean all donations, what about regular givers/legacies… and so on.

The problem is, it is always about the data
And there-in lies the rub. There are of course many such questions which we should ask about so many of these seemingly simple queries/reports. There is a need to think about this, there is a need to know the data and coding structure on our database, and we do need to consider why we are asking the question at this time. If it is to get rough counts then maybe some of the exclusions matter less (or maybe not…). But if we are producing a report for the Director of Fundraising about income from last year then we need to ensure that we know what we are producing is correct.

And I haven’t even started on the need to add a second variable to a question. E.g. find me everyone who has given a donation last year and who lives in London or Leeds. How many fundraisers and end-users really understand Boolean logic and truly know their ANDs from their ORs. And then of course we have nested brackets…

Some software can help
E.g. simple templates, ‘query-by-form’ (rather than a separate query module), cut-down versions of field lists; and parameters are always useful. i.e. many times a fundraiser wants to ask a similar question on different days but just change the city name, the amount in the donation value field etc. So data people can create a standard query for such a request but include a parameter in the query - so when a fundraiser runs said query, they are prompted to enter the city/donation amount etc on-the-fly without having to 'get under the bonnet' of the query to do so.

But it still comes back to the data…

Hence the central data team
All of the above is why so many organisations still have a central person/data team to create these queries and reports. Because the database/data person does understand these points and therefore, as long as they understand the question the fundraiser is asking (another point altogether…and shows again my point of the need for "bridgers" in our sector) then they should be able to create such queries/reports easily enough. I also know a few organisations who have a ‘data’ person in a fundraising team such as Direct Marketing, so that they can specialise in such requirements. 

Or is your organisation different?
Prove me wrong - please! Leave comments below about how you or the fundraisers/end-users in your charity do create new and even semi-complex queries or reports. I'm sure there's plenty of people who would love to know.