At some point, delius needed a flexible toolkit for Joomla to display (and manage) structured content: concepts related to each other, residing in a variety of data sources, from databases to SOAP APIs. Nothing was available at the time, so we developed one|content

The development of one:content has been fairly slow over the past years, but recently a version compatible with Joomla 3.x has been setup. There are still areas of work to be completed, but frontend functionality is operational. In one project, the need for a REST interface to one:content schemes suggested an extension to one:content for that purpose. This article describes the approach we used, avoiding (true to form) the need for coding.

The objective was to add metadata to the scheme definition to describe which routes would be available for the scheme at a REST entry point. This makes it possible to define routes as you want, provide some REST API parts and not others, use standard one|content authorisation and allow a definition of which attributes should be exposed.

If you're a fundraiser, chances are you're already subscribing to 101fundraising's newsletter. If not, you're missing out on a lot of good insights, and you should subscribe. 

After an intensive period of planning an increase in donor centricity, I ended up writing this blog post on how easy it is to be donor-centric ... or is it? Here's a snippet.

Shifting an organisation towards true donor centricity requires making a fundamental, disruptive change. It’s not a cosmetic, superficial fix to how you write copy, or a matter of more personalisation in your emails. ... It’s very disruptive, because it needs to change the focus of every process, role, task, policy and donor touchpoint to be successful. So if it isn’t painful, you’re probably not doing it right.

The complete post is at 

CiviBanking seems to be doing a great job. As I'm doing my best to process a year's worth of bank statements, the UI is getting tuned. We're still an iteration away from a really superb interface, but it's quite doable. Many thanks to Björn Endres for building a great Ajax-style tool for creating contributions derived from a payment ... even though the UI has changed a bit, it's conceptually real smart. So when I'm done with this initial massive processing run, a real big update is going to hit the GitHub repo. As I will be rolling straight into the next CiviBanking gig, you can bet on more fun stuff coming. 

Over the last few weeks, when I was not processing bank payments and updating CiviBanking, I've been handling customer communications, or rather ex-customers non-communications. Hard to respond to people who ask the same thing over and over, hoping for a different answer -- or to people whose question you really, really cannot answer because you do not know the answer yourself. Which of course in their eyes is not an answer ... but I hope to get that cleared up over the next few weeks.

And it looks like I'm doing the keynote at the Dutch Joomladays again. It's always a great event, and I'll do my best to make it even better!

It's never good to say you are working in CRM. It's boring. It makes people think of long lists of addresses, endless hours of correcting data, lots of manual labour ... so consultants often revert to slogans like 'optimize your customer relations' or 'leverage your market intelligence' to explain why you need to take a look at their product. I wonder if that really works. If I ever did that myself, I apologize.

Solution selling (yes, that's a real discipline) is based on understanding the problem first. No two organisations have the same problem, of course, but they do fall into broad categories with quit a bit of similarity. One of my favourites is processing incoming donations.

Let's assume you get 100 donations (replace donations by memberships if you wish) every month (40 EUR on average, roughly 50 weeks, say 200k per annum). Your weekly bank statement will contain an average of 25 donations, plus 10 other transactions (bills paid, etc). Someone needs to isolate these 5000 donations from the pack and enter them in 'the database'. Reading the name and address info, looking up contacts, creating a new one once in a while, registering the donation ... necessary evil. But have you ever really looked at the cost of this?

Page 2 of 2