People and processes: the inside story of customer relationship management

by Paul Anderson, Intelligent Content on 4 November 2008 , last updated

Archived This page has been archived. Its content will not be updated. Further details of our archive policy.

Introduction

Strictly speaking, customer relationship management (CRM) is a process rather than a particular software application. As the name suggests, it is often used in industry and commerce to manage the relationship between a company and its customers, with the aim of providing a high level of service to the client. CRM often focuses on recording interactions with clients in order to log where there have been problems or to spot opportunities to provide additional services. CRM software automates these processes and aims to allow service providers to provide a more co-ordinated and ‘intelligent’ response to a particular client’s needs.

However, perhaps because of the connotations with commerce there is a widespread view that CRM is really just for sales and marketing teams, and the wider perspective is often missed. In fact, there are many activities that involve handling, supporting and communicating with groups of people and HE/FE is potentially missing a trick by not making use of the increasingly sophisticated features on offer from modern CRM systems.

Within OSS Watch, keeping track of comments and questions from a wide variety of people had been an ongoing issue for some time and it was generally felt there had to be a better way of supporting people and projects. With this in mind, Ross Gardler, Manager of OSS Watch, instigated a project to investigate the role that a CRM system might have within the day-to-day operation of OSS Watch’s own support service. The project involved trialling the use of an open source CRM system over a period of nine months.

In terms of the project’s origins Ross says: ‘The overall context is that we provide support to an awful lot of institutions and individual projects throughout education. We have contact with many people and we need to know, and keep track of, the common things we have to deal with on a day-to-day basis. People suggested the use of a Customer Relationship Management package but at first I questioned whether this was the right thing for us because we are not doing sales.’ However, Ross decided to persevere with the trial, partly because he felt that the team would benefit from the experience of being exposed to the processes of CRM and partly because he was keen to see if adopting a CRM system might impose beneficial structure on day-to-day support activities that may, over time, have developed in a rather ad hoc way.

People processes versus software processes

It might have been expected that OSS Watch would automatically select an open source CRM, but in fact, from the very beginning, the question of closed source or open source was always secondary to the question of will it allow us to work productively within our team, and within our framework? The key factor in the successful adoption of a CRM system is that it underpins the processes that take place within a team when the members of that team are supporting and engaging with users — a process that was mapped out in detail before the pilot started. However, this raised the issue that everybody has slightly different processes and led to the question of do you change the process to fit the software, or do you change the software to fit the process?

Ross cites a common example of the way that OSS Watch tracks development and procurement projects, saying: ‘understanding the needs of our “clients” (for want of a better word) _before _they know that they need our help with a particular issue, is critical. Therefore our process of tracking projects, and the people involved with those projects, is key to the overall task of supporting those clients.’ The CRM system had to be able to support a process of considerable tracking of client projects although the team accept that much of this work, for example, monitoring comments on project blogs, is only really practical if a human does it. Ross says: ‘What I wanted was for the CRM system to do a lot of that tracking for us, so that it’s not as time consuming. [However] it’s also unreasonable to expect the software to be as intelligent as a human in its tracking.’

The way in which OSS Watch has tackled this question is to look at their processes and ask if the way in which a process is carried out is critical and therefore can’t be changed, or if the process can be made to be more flexible and adapted to fit the software.

System selection

At the beginning of the selection process Ross evaluated a number of CRM packages that were available. As CRM systems handle and store personal data about individual people, sensitive issues around data protection and storage have to be addressed. At the time, the general question of holding data off-site was an on-going issue across the University and Ross says: ‘The institution was already looking at whether we could hold data within Google Apps, and that was looking questionable at the time. But that’s less personal than the kind of data we are talking about in a CRM system, which tracks things like a telephone conversation about a specific legal issue within a project, for example.’ This meant that one of the potential solutions, a Web 2.0 application, was rejected quite quickly because of the legal question of whether this kind of data could be held on a server that wasn’t owned by the University.

Of the shortlisted systems, all but one was an open source solution. However, because of the sales-focused language used by CRM systems, the lack of adaptability of the closed source system was a cause for concern. Ross was aware that, if taken up after the end of the pilot, they would need to spend some time adapting the system to display more meaningful language on the screen, and this would mean that they would need access to the code.

Access to the code was also important in order to avoid any possibility of data being locked-in to one particular product or vendor. Ross says: ‘Of course all the closed source companies said “Oh yes, you can get the data out”, but we had no idea of how much it would cost us, because they weren’t prepared to give us their database schemas. With open source, we knew that even if it didn’t have convenient [data] export facilities, we could write them.’ Ultimately, it was this lack of adaptability that meant that the possibility of a closed source system was ruled out.

Of the open source solutions, two were looked at in detail: vTiger and CiviCRM. The latter is aimed at campaigning, non-profit organisations and is therefore not as sales focused as traditional CRM systems. At first this was attractive, but further investigation revealed that it was built on top of a web content management system (CMS) called Drupal, which the team felt might be technically ‘muddy’; they felt they needed a CRM rather than a CMS that could be used as a CRM system.

The eventual decision was therefore in favour of vTiger, which is maintained by a community of developers. Ross says: ‘vTiger appeared to be the one that was most open in its development methodology and therefore if we did want to make changes then we could engage with the development community.’

Implementation and use

Within the OSS Watch team, resistance to using a CRM system was high and the sales language was definitely a part of that resistance. Bearing in mind that vTiger is open source and could have been customised, it would have been possible for the team to change this and adapt the system so that it reflected their needs more closely. However, because this was a pilot, there was a question mark over spending the time needed to make the customisation in case this turned out to be a waste of resources. In the end, the changes were not made and this inevitably led to a lack of take-up among the team. Of a total of six members of staff who could’ve been expected to participate in the pilot, only three took part and only one, Ross, really strove to take full advantage of what the system had to offer.

Gabriel Hanganu, an OSS Watch team member who took part in the pilot, takes up the story: ‘I joined OSS Watch in November 2007. The CRM had been installed, but at first I wasn’t very impressed, to be honest. So, I asked again whether CRM was the right choice for OSS Watch – it did look to me to be more geared to sales people.’

Gabriel persevered with the system and came to be particularly impressed by things like the bulk emailing functionality, which allowed him to import a list of people’s names from another package in order to email a feedback sheet after a conference. He says: ‘This would have been an operation which was quite time-consuming and repetitive, and the system could help me very much. Now I began to think that we might need something like this.’

This dawning process took several months, though. Gabriel says: ‘I started to become convinced by actually using it. I had been pushed a bit by Ross to use it, but I think this helped, because I realised that once you get over the first difficult steps of getting used to the language and terminology it is using, it can be very useful.’

Getting over this initial ‘pain barrier’ was definitely part of the problem for the pilot. Ross says: ‘[As the project was] a pilot, I’ve been reticent to force people to change their processes for doing this stuff, knowing full well I might ask them to change it again at the end of the pilot scheme. To be fair, all of the members of the team have played around with it a little bit, and have looked at it, but none of them has really persevered enough to get past the point that Gabriel was talking about.’

Ross notes that although support is in some senses a ‘sales’ process in that it provides a service to clients who use it, for some in HE ‘it is a difficult pill to swallow’. He believes that his workflow was improved by adopting CRM because he learned from the processes that were encoded in the CRM system and was willing to map this ‘sales’ process to his support process. However, the pilot has demonstrated that it is very important to be clear as to what your own internal processes are before embarking on the adoption of a CRM. Ross warns: ‘If you look at it before knowing what you want to do, you’ll end up following a traditional sales model, which may or may not fit.’

Pros and cons

With hindsight, Ross acknowledges that the main problem has been getting the team to use the system: ‘I think if we had taken vTiger, changed all the names in it, turned off all the features that we don’t need and showed it to the team six months ago, they’d have been willing to use it. Whereas, having gone in with the sales thing, along with all the stuff that we don’t use, there has been a real problem there. I didn’t think that the rest of the team would have the problem that they had with the terminology because I hadn’t had it personally. Looking back retrospectively it’s an obvious point – but then everything’s obvious in retrospect.’

However, there have also been quite a few small moments of ‘ooh, isn’t this CRM quite cool’, where, for example, one member of the team takes a call and realises that somebody else in the team has already had an email exchange with them, and can catch up. The first significant benefit became obvious when Gabriel first joined the team. Ross says: ‘[Gabriel] was going through his induction process with the team, and I was able to say to him, “Right, OK, in two weeks’ time we’re going for a meeting with project X, just have a look in the CRM system, and you’ll get the background to that project.’ He could then go and see what the project was, the names of people involved, what JISC funding call it came from etc. And if we’d had previous meetings with them, the full meeting reports were there, that kind of thing.’

Next steps

Despite some difficulties adapting what is widely regarded as a ‘sales’ tool, Ross is clear that he sees the pilot going forward and leading to the formal adoption of a CRM, in spite of remaining reticence. In the short term, OSS Watch is continuing with vTiger because Ross feels there’s definitely value in collecting the data they have. They are currently using it for tracking contacts, meetings with contacts and organising events, and are about to start using it on a new funding proposal to the European Union. However, as Ross acknowledges, ‘all these things are collecting different types of data, and all of them, if we want to migrate away, will require us to manipulate it in more complex ways to get it into whatever system we end up with. So it’s fine for a short-term solution [but] the longer it goes on, the harder it’s going to be to move away, even though it’s open source.’

So the challenge for the medium-term is to make a decision. After initially having rejected a CRM built on top of a CMS, Ross is now experimenting with a workflow within a CMS system to see if they can get the same benefits of CRM: ‘The particular one I’m using – its big USP is that is has a very customisable workflow system. So we can just define the workflow without actually doing any programming. I’ve got a feeling that we might kind of build a pseudo-CRM system within our CMS system, learning the lessons we’ve learned using vTiger. This will be a much looser system, which is governed by [just] a few critical points in the workflow and should hopefully get over this problem of some members of the team feeling that their process is being constrained.’

The overall conclusion is that CRM processes, rather than a CRM system per se, are the way to go. As Ross says: ‘We will be adopting something like a CRM system. It may be the one we are using right now – I haven’t rejected it at this point. In a few months I’ll be able to say whether we are going to stick with this one or not. What we go with at that point I hope will be the long-term solution.’

Recommendations for a CRM pilot

  • Map out and be very clear about your own internal processes before embarking on a pilot study.
  • Fit the CRM to these processes and not the other way around, although be prepared for a bit of ‘give and take’.
  • Be prepared to see past the ‘sales’ language of most CRM systems but expect some resistance to it. Identify members of the team who will be prepared to see the pilot through and get past the initial teething problems.
  • Consider the benefits of an open source solution – ability to customize the code and no vendor lock-in.
  • Think about how the CRM will integrate with other key tools such as the Content Management System (CMS).
  • Build up gradually the number of activities and tasks that the CRM tool is used for, in order to get a feel for its uses and benefits.
  • Consider, and review with other institutional staff, the data protection aspects of the pilot.

A more general discussion about open source software procurement in the context of UK Higher Education is available in this OSS Watch procurement workshop report.

Further reading

Links:

Related information from OSS Watch: