We’re going to unsubscribe you, unless...

I received a clever email today (at least, I think it's clever!) which has the subject line, "We’re going to unsubscribe you, unless..." At first, because the subject text drew my eye, I thought it must be spam, but then I looked at the sender and realised it was from the British Library (BL), who I am a subscriber to. So why was it clever? Well I think it was smart because of the following:

First, interestingly, "mild panic" set in. (Well, okay, not quite panic, but you know what I mean). What was I going to be missing?! What was I about to be unsubscribed from without me knowing? So I opened the email. And once my heart-rate had returned to normal, I realised it was the BL informing me that because I hadn't opened one of their regular emails for some time, they were going to unsubscribe me unless I specifically clicked on a button to remain subscribed. And I quite liked that. It made me wonder initially why I wasn't opening their emails and if I did really want to continue to be subscribed. So I clicked and did re-subscribe.

Why even do this?
Now, I guess some people might question why the BL bother doing this. After all, each email only costs a few pence to send so why not just keep me on the list. After all, one day I might open it and take some action. Which is how I know many fundraisers see such email lists. The more names the better. Never mind if it isn't really what the supporter is interested in reading anymore, and never mind that the open rate is 0.00-whatever. Just keep sending everyone the emails just in case…

However, personally, I think this is a great exercise in promoting supporter choice, which is something I quite believe in. Surely it makes more sense to only be sending emails to people who want to receive them. Surely it provides a better ROI - after all, even if each email only costs a few pence to send, thousands of such emails will add-up each time they are sent, and they are likely to be sent many times during the year. So the total cost will add up.

And, by getting people to re-confirm their subscription, by definition you have someone who has taken a positive action to remain interested, and that in itself could be an interesting segment to approach. Now you know something more about them. Maybe you could send them an initial "welcome back" email with a particular message or options to take? Maybe they could be allocated a different customer journey? As yet, I haven't received anything like that from the BL but I will wait to see. (I was also slightly disappointed that the email click-through was to a generic page on the BL website rather than a 'Great, thanks for doing that - now have you thought about…' type page).

The Technical SideOf course, to do this, it takes one critical technical thing: an email marketing system (EMS) which can monitor if someone doesn't open an email; and alongside that, a database - whether within the EMS or in a separate CRM - which the marketers can query in order to find out which people they should target with such a message - which people have not opened x emails within the last y months/campaigns etc. And of course, a database where, if I am subscribed to several different emails from the organisation, then it needs to be able to not blanket unsubscribe me but just opt me out of this specific email campaign.
It’s a great example of the digital world with a smart database and with some savvy marketing users coming together to try this out. Kudos to the BL.

Is there any place for the Long ITT anymore?

 

The short answer
No.

The only slightly less short answer
No, except when you have to, such as OJEU or similar requirements.

The Full Answer
Okay, let's address this question properly. First of all, what do I mean by a "Long Tick-box ITT"? Well, pretty much as it sounds: it's when you devise hundreds and hundreds of questions, mostly about functionality, and ask suppliers to respond to your Invitation to Tender (ITT) document by asking them to tick a box which says if they can meet that requirement. Often, this will be a MoSCoW method (or similar): Must have, Should have, Could Have, Won't. (Never underestimate how much IT loves its acronyms and pseudo-acronyms). And then sometimes one asks if they can do it 'Out of the box' or 'with customisation' or 'not at all' - or similar. Thus, the suppliers tick these boxes, you add-up their scores, sometimes weight the questions with more/less importance and hey presto, we have a winner. Or at least a short-list which you can then invite in for a demo.

But it's really not as simple as that. In the first place, suppliers have been known (shock horror) to stretch the truth when ticking boxes and interpret a question so they can say yes they can do it when maybe they can't really... And in some ways, that's understandable as writing such questions so they are non-ambiguous can be difficult.

Plus, completely understandably these days, 'generic' CRM suppliers can probably say with (almost?!) complete honesty that they can do all almost all of a CRM ITT's requirements because their systems have been designed for exactly that flexibility. But that still doesn't mean they are necessarily right for you to buy.

And it doesn't tell you anything about how they would do it, or if they do it well, or if they understand the question and so on. Okay, so some of that can be addressed at a software demonstration but by that point you may have knocked out a good option (supplier) without knowing it, or you might find a supplier is actually completely inappropriate for your organisation or requirements. It's just a non-efficient method.

In fact, the time it takes for this whole process is a looooong time. A long time for you to create the initial document, a long time for the supplier to answer and a long time for you and your colleagues to read all the responses and mark them.

Couldn't there be a better way of using your time? In my opinion, yes. Personally, when I help charities with a procurement, I prefer more 'open' tender documents (aka RFP - Request for Proposal), asking for more expansive responses, possibly with the inclusion of process diagrams and a more interactive approach with the suppliers all round.

And I'm not completely against including a few lists here or there in the RFP of specific requirements which you must have - especially where they are especially important. But I don't ask suppliers to tick each bullet point.

Clearly, there is a lot more to the whole procurement process than just the above - but super-long ITTs? No, not for me. I don't think they help you select the best supplier for you. Which is ultimately what you want.

Should organisations choose a CRM platform before a supplier?

 

With the emergence of the generic CRM systems and the reduction in the number of viable proprietary fundraising databases, an interesting question is arising: should charities now be choosing a CRM platform before even looking at which specific supplier/partner they want?

It is a process which some companies in the commercial sector have already been practising for years. For some companies, they will decide first on whether Salesforce, Microsoft Dynamics, SugarCRM etc are the best fit for them, and only then will they search for a specific partner who can help them implement a new CRM system on that chosen platform.

For charities, however, at least until recently, because the options have primarily been about comparing different proprietary fundraising database suppliers (e.g. Blackbaud, thankQ, Redbourn, ACS etc), this has not been an approach we have taken. That said, there will of course have been some technological decisions: the system must be SQL Server, or it must be Oracle; it must be dot net or it must run on Linux etc. Or even, it should be open-source. And so on. So it's not a completely alien idea.

It's just that with the new CRM systems, the platform choice can be far more "business-oriented"; i.e. if we do decide that platform X is the right solution for us - and if that platform is one of the generic CRM systems - then we now have the choice of talking to numerous companies about how they would implement that, looking at whether we want a templated version or start out-of-the-box, develop in-house or with a partner, and so on.

But additionally, if as a charity you do want to be considering a platform first, you also need to consider the proprietary solution as one of those platforms - and (probably) not just one such solution but the concept as a whole. As I have discussed many times in my blogs, there is no simple right and wrong as to whether you should select a traditional fundraising database or a CRM solution. If you do select a proprietary solution then you will (almost certainly) implement it with that system's software author and that has its pros and cons. If you go with a CRM solution, then using a business partner of that software author (or even doing it in-house) also has its benefits and downsides.

Personally, at the moment, I think choosing a platform first is a difficult approach to take for all but a few, probably larger charities who already have a detailed, well thought through technology plan and IT strategy. Especially at an early stage in a procurement project when you are still trying to understand the differences, the benefits of all solutions, the impact on your organisation and so on. I think there would have to be clear reasons for you to only look at the traditional fundraising databases, or decide not to look at those at all. You might dismiss one option or one supplier etc as you progress your procurement, but I believe you need to understand what all options can offer before going solely down one route. So at the moment that will usually mean keeping them all in the hat until you are ready to shorten your choices to the final few.

The Importance of Report Designers during CRM Implementations

 

On one project I worked on, not long before we were due to go-live, there was some concern that a specific, highly important report could not be produced because of the fundamental, underlying design of the CRM system. And it made me wonder how this could have happened - that such an important factor had not been fully considered until that point. It turned out that the reason was because when the database was being designed, the report designer - i.e. the person who creates the reports, not the software - had not been consulted when they could have provided invaluable input.

When I thought more about this, my first reaction was to think that this should hopefully be a rare occurrence. One would trust that in most instances, whoever was designing the database - whether a person, a team, a company etc - would know the key reports which were required and would thus design the database so that such reports could be created. Plus, in classic systems design, one often starts with asking what reports and information are wanted and thus we work backwards to work out what fields and data need to be recorded in order that such reports can be created.

However, with larger or more complex implementations, with projects with larger teams, and also with the new CRM systems which now offer so much more flexibility with their design, I've realised that such a requirement could easily slip through a hole. It is quite feasible, if the correct person is not consulted, that a database could be designed without true understanding or consideration of some reports. Or perhaps understandably, whoever is designing the database was told by a 'third party' as to what a report needed to show, and thus they hadn't got the full picture.

This issue can also be exacerbated when a charity is implementing a new database where no-one in the charity necessarily has the in-depth experience of report creation on that system. (By the way, in this instance the charity may have to hold their hands up to accept their share of guilt as this isn't necessarily something which should be aimed purely at the supplier...)

So my advice:

• when designing databases, do make sure reports are considered early in the design phase;
• engage the relevant report designers as soon as possible, and if you don't have one in-house then consider contracting one even for a short period to do some 'sense checks' early on; 
• introduce a specific 'report workstream' in the project so that reports, outputs, mailings et al are specifically considered at all times; 
• and don’t underestimate the time or importance of this factor.

After all, if we can't report on the data or get the data out of the database in a useful format, why are we using the database in the first place?

Good Database Managers Know When to Say No

 

It is quite an art saying No. Especially when you are a database manager and your users are continually asking you to do this and that and everything else, and you know that, yes, that latest request is technically possible (as opposed to something just not being possible at all) but, business-wise, data-wise, policy-wise, it is the wrong thing to do...

So, do you say No in such instances?

I applaud any database manager who does say No when they truly believe that it is the wrong approach to take. But it's a hard thing to do. ^†

Of course, what I hope a database manager can say sometimes is, "No, but…" i.e. no, what you are asking should not be done that way, but on the other hand, you can do it this way. And then hope that most users will understand and appreciate that. An example is how someone might ask for a new field or new code table to be added to a database, when you know that it is better practise to extend the use of an existing field/table.

But it's harder when the question doesn't necessarily have such an easy answer. e.g. Can we add a new screen to show data item x to department y… Can we import these z records from another system…

Both may well be possible technically. You might well be able to create a new form so that department y has a specific view of some data, but if that means that they won't see other relevant data which they should be aware of, or if it means it will be much harder to maintain in the future, then you might need to say No. And although you can explain why not, there isn't such an easy answer to what they can do instead - it might just be that it shouldn't be done full stop.

Similarly with importing records from another database. What for? Who will use them and how often? Will those records still be on another database - if so, how will you keep them all up-to-date? And so on. I have seen countless systems littered with useless records which have been added some years ago just because someone had the bright idea of doing this one particular project…

So stick to your guns, database managers. Remember what Zammo said (for those old enough to know what I'm talking about…)

---

† BTW, for any fundraisers reading this, who feel that their database manager is always saying No, then I feel for you too! They might be doing so for good reasons, but it could of course be a bad database you have or even a not so savvy database manager…