Friday, 23 January 2015

How-to: A New CRM


[NOTE: some of what follows is actually true. Some is invented for the case study. You can decide which...]

Sometime last year, the current client got serious about the need for a new Customer Relationship Management (CRM) system. Having jumped at Salesforce without really having the skills or the vision to implement it properly, and despite two project re-starts, it had fallen by the wayside.

So we went through the exercise of deciding 'what next': a third restart, to get it right? Buy in another commercial package, go Open Source, or build something in-house?

Trouble is, everyone already knew the answer was '42' but didn't necessarily know what the question was...

Customer relationship management (CRM) is a system for managing a company's interactions with current and future customers. It often involves using technology to organize, automate and synchronize sales, marketing, customer service, and technical support.
Customer relationship management – Wikipedia.

en.wikipedia.org/wiki/Customer_relationship_management

The first practical problem to overcome is defining just what we mean by CRM. How much time have you got? I started trying to do this fifteen or more years ago and haven't beaten it yet.

The term CRM can be used to describe both Customer Relationship Management and Contact Relationship Management and the while the two may overlap, they are not the same thing.

In the wider world, CRM implies a process for capturing leads, identifying prospects, recording pre-contract conditions and the conversion to customer. There is then the ongoing operational use of CRM in servicing, cross-sell, up-sell, and retention of those customers. And what did we have in the current operating environment? Not exactly a full suite of business processes for any of those things.

Now, it's a small organisation; everyone thinks they understand what it does and how it does it. Those would be the business requirements. A set of technical requirements - or constraints - also emerged.

It was acknowledged that the existing Event Management database developed in-house and maintained by an outside contractor was not up to the task of CRM. Its core capabilities being: 'people' - subscriber members, staff, event attendees, web-users; 'organisations';'events' - classes, workshops, conferences, webinars; some capabilities in reports and data exports.

We also had a significant and on-going investment in a web-platform with shopping cart which began out of sheer desperation at the previous Joomla website which was a frazzled, disorganised, jumbled mess, un-maintained, and in management eyes, un-maintainable.

There's nothing like tackling the root causes. And this was nothing like tackling the root causes.

Now if you know anything about established CRM products, you'll know they all try to be the  repository, single point of contact and web-platform ('portal') for customer self-service. Going down that route would mean throwing away both the current database and the new web-site with it's API and starting over.

Salesforce was intended to be that fresh start, but fell at the first fence of taking over the event management function. Even at not-for-profit rates, the cost of licensing, set-up and customisation was a non-starter. It looked like Salesforce had to go.

Would we do any better with the likes of Sugar CRM, CiviCRM or a host of other supported or Open Source products? Where was the technical know-how to come from to implement one of these?

Or could we 'leverage the existing investment?' Translation: make a silk purse out of a sow's ear? Re-build the current database and extend the new web self-service and shopping cart?

So we did precisely what you SHOULD NOT DO in an organisation whose tag-line is 'evidence-informed practice'. We assumed a whole stack of business and technical requirements, weighed up the build-buy decision and opted for door number three. The in-house option.

Normally in the build-buy equation, you wouldn't touch door number three with a barge pole tied to another bargepol, but as I say, there were a whole set of constraints.

Next, we ran a cursory requirements-gathering exercise, pulled a budget figure out of the air, lined up some developer time and fired the starting gun.

So if, at any point, I despairingly ask how we got here, just send me the bookmarked link to this URL.

More on CRM soon... RC

Image credit: StateLibQld 1 112816 Interior of Dalton Brothers Grocery Shop in Ipswich, ca. 1910 [Public domain], via Wikimedia Commons

No comments:

Post a Comment

At least try to be nice, it won't kill you...