A list of functional requirements for a potential CRM system follows after interviews with nine people with interest in the Drupal CRM system. These include a CRM for running the congregation of a church, a mass emailer, a real estate business, a large American civic association, a small bank, and a political party. The main problem with current implementation is either that the CRM is not integrated fully with drupal (CiviCRM) or simply that the development effort is too great to create the functionality from scratch.
The nature of the main contact database varies for different organisation. Online business are happy for their contacts all to be users but other organisations require a separate contact entity perhaps with millions of records. Perhaps in the future a contact will be a facebook or twitter user with only minimal information stored in drupal.
The requirements for functionality against a contact entity are listed below for discussion.
Contact Management
• Maintenance of contact data (either as a user or a separate entity) including sophisticated searching and profiling.
• If contacts are separate to users, automatic reference to the contact entity for a new user.
• A good permissioning system possibly based around the concept of ‘ownership’ where each contact is owned by a user (or a team).
• Allow grouping of contacts into a household or a company.
• Registration of contacts against different groups.
• Geolocation of contacts.
• Advanced relationships between contacts (doctor-patient, parent-child/drupal dev-client).
• Contacts can update their own details.
• Access data on a mobile device.
• Social media integration (users are facebook or twitter accounts).
Communication
• Ability to send emails and letters or schedule phone calls.
• Integration with Drupal VOIP.
• Automatic sending out of a template email.
• Addition of incoming emails to contact history.
• Creation of mailshots according to tags and other profiling.
• Mass emailing and recording of whether email was received or opened and so on.
Workflow
• Recording of all actions to created a full contact history.
• Scheduled actions for a particular user to perform in the future.
• Creation of multiple actions for different people as part of a workflow track.
• Concept of a set of actions (a case) all of which must be completed before the case can be closed.
• Ability to have an event scheduled with a list of attendees. In the case of a youth group the attendees would be able to sign in and out of the meeting.
• Ability to have rotas to allocate people against tasks or events.
• Workflow integration with Maestro.
Integration
• Integration with Drupal Commerce.
• API intergration with a web service for retrieving data from the CRM contacts and history into external systems and also for writing data in from an external system.
• Migration for importing of existing data.
• Deduplication module.
• Billing functionality and integration with accounting systems.
• Integration with LDAP.
• Export to spreadsheet and mailing programs.
Comments
Let's concentrate on essentials
Thanks for this. It's got quite a bit of detail!
I'd like people to think about the CRM core and what that might look like. Only very minimal functionality will go in there. What must a CRM have, without which it couldn't be called a CRM? Everything else, while "nice to have", is not a requirement.
Sure, a church might say that without a "religion" field, it's not a CRM. A political party might say without a "voting choice" field, it's not a CRM. Some people would find a CRM useless without LDAP integration. Everyone has different ideas when it comes to what a CRM should have, and that's great.
These "extras" should be separate functionality in separate modules, and rather than providing this by default in the CRM core, the focus should be on the CRM core being flexible enough to accommodate all these extras.
Consider an extreme example: does a CRM need fields for postal address? Not really. You could conceive of a CRM without, so this should be a supplementary module or feature or similar that, if users don't need it, won't be enabled.
Yes, you are absolutely
Yes, you are absolutely right. IMHO the CRM API should just provide the very basic. But all these listed features should be able to be done upon this API. So it's important to think about it.
CRM-API Thoughts
I have documented some thoughts about a possible API at http://groups.drupal.org/node/171454.
It strikes me that there are three important reasons for having an API that is independent of the implementation are:
1. One CRM implementation might need to have drupal users as the subjects and another might have contacts that are independent of the drupal users and we really need to be able to abstract the functionality against either entity. Similarly, activities that record history or future communication need to be associated with contacts or users as apporpriate. I call this abstracted contact/user entity a 'party'.
2. Communication with a 'party' needs to be by email, letter, phone call, fax, twitter, linked in, facebook and so on. We need to abstract these communication methods so that fields of different names will not break the CRM functionality to allow communication to be easily effected against any party.
3. 'Activities' should record history and future tasks to be performed against a 'party'. An abstracted API is required for this to link an activity to any party.
Drupal lends itself to the notion of 'party' as much functionality can easily be implemented against more than one content type and so a 'party' could be a subset of nodes (extended to entities for drupal 7). So three abstractions... party, communication, and activity.
x
x
So what are the essentials?
I guess I'm a little unclear as to the downside of trying to roadmap this project out. Clearly, religion and voting choice are just fields attached to a contact, or party, entity; but what about all of the business processes and workflows that define CRM systems. Without these, CRM is just contact management.
Yes, you're correct that you can find instances where a CRM system may not need to perform a particular function or, for example, attach a postal address to the party entity, but I think it's important to acknowledge from the outset that a preponderance of users will require address fields, then to define how the system may accommodate this requirement, separate module or otherwise.
My feelings are that an
My feelings are that an programming abstraction of the 'customer' is required so that you can easily catalog all the communication methods available (phone/fax/sms/postal/twitter/facebook/email) for use in communication. The actual customer entity and the associated fields can be implementation specific although it would be great to have a standard drupal contacts module (not necessarily the same as users ?). I call the customer/user/contact that that is the C in CRM a 'party'.
A second abstaction (that I call activity) would handle all the workflow and represent a historic or future phone call/email/mailshot/letter and so on.
So there appear to be 4
So there appear to be 4 different initiatives working on CRM stuff at the moment.
Rob (and me) and Joachim:- We're working in Joachim's party module in his sandbox. I think the branding of this is sort of "DropCRM" although we worked on Cloud CRM for a while and then party... I think I'll refer to it as Drop. Me and Rob are attempting to give one day ish a week to this.
Kyle or Citizen Kane with Trellon:- Recently released his code. Is working on it pretty much full time on CRM stuff for some clients.
Allie Micka:- Has the CRM namespace and particularly wants DrupalCRM to work well with other CRM packages. She likes that CiviCRM allows multiple drupal websites to connect to one CiviCRM database and therefore her focus (regarding working with us) is to build this "CRM primitives" idea which is basic data in a CRM organised in a coherent manner so that our different implementations can work with each other.
RedHen CRM:- Don't know much about these guys
We're planning to chat maybe bi-monthly on irc/skype but I think personally, I'm planning to work on this with rob on friday, I kind of want to see if those plans work out before organising chats with other people.
The reason why I say this is because we don't need a completely agreed upon set of base features at this stage. I think its fine for all our different implementations to go off in different directions for a while (As for example, Trellon can't wait, they have to just build it). I also get a feeling that us and joachim are going to aim to build this as a more "framework-ey" thing that could handle lots of different use cases whereas Trellon need something that works.
So that being said, I have an idea of what I want out of a basic Version 1 of a CRM
-> Some UI for Adding Contacts
-> Some UI for viewing and filtering contacts
-> Some UI for taking e-mail addresses and printing them out to be inserted into an e-mail client
-> A Contact Entity that is fieldable
-> A way for a Contact Entity to be connected to a User Entity (although this is optional, this should be automatic with a UI for connecting the two)
I think the step about "Contact Entity" is going to be more of a party entity but we're still figuring that out. The point is, because it is fieldable I kind of think almost nothing is needed for the "basic" entity. We need a User ID and possibly a name (although even names are complicated when it comes to the different ways those could be formatted, so for now I think we'll just have "Full Names" and only the ability to sort by fullnames.) Depending on how this stuff with parties pans out there will be one other thing.
-> Some way for adding "bundles" to the Party Entity.
We want to build it so that it is a framework, whilst (me and Rob) will also built a product out of this framework specifically aimed at the church. The framework would go in some modules. I think the product would be a feature.
EDIT: Will add this for our particularly usecase. Its a list of "Church Management Software" and their features. This is a long way off though!
Thoughts
HI,
I like the ideas that have been floated suggesting that the core "thing" in the CRM is not a data-containing node, but a proxy for one, an "entity". In particular, for me I want the ability for a CRM person to also be a Drupal Registered User, but not be required to be one.
You asked, so my thoughts on CRM core:
There must be a central component / object that "refers" to a person. The details of the person aren't necessarily there, but there must be something there to hook LDAP, DrupalUser, MySQL fields onto. Q: does it have to be "person"? What about other things that are part of a network or hierachy?
There must be a way for person components (above) to relate to other things. Is "group of people" is the right idea here? I certainly think it must be possible to form groups of people. I also think it should be possible for one person to have specific relationship with another - think parent/child, or manager/worker, or doctor/patient for example. Should all relationships be two way? Possibly not... If you had a "friend" relation, and A is-friend-of B, and B is-friend-of C, does that make A is-friend-of C. Not in real life, anyway.
Implementation wise I believe the following are also true for core:
There must be a way for a client-of-CRM module to extend the central component's set of fields. Ideally, the location the data is stored can be different for different fields (so, e.g. LDAP could be used for some, MySQL for others).
I believe it should be a requirement that the location of field data is hidden from modules that might use it. So one module can bring in clients from an LDAP source, and another module that, say, implements an address book node, is oblivious to that: all it cares about is that the fields exist. This suggests that we need to come up with a consistent way to label data (and possibly for modules to ask whether given fields or field groups exist).
I've hinted at multiple layers... a "data access" layer, that enables access to data sources, a "core" layer that implements relationships between things, and some number of layers above that implement editing, viewing etc. note that data access doesn't necessarily mean database: some data may be calculated or inferred.
The above suggests there may need to be:
Common names for data. For example "firstname", "familyname", "date-of-birth".
Groups of fields. For example "name", "address", "contact".
Derived data. An address book module may request access to the "name" and "address" groups, and then request the "fullname" field: this is derived from "firstname" and "familyname" or provided direct, as in the data source. Q: how to edit "fullname" when it's actually "firstname", "familyname". May we end up with read-only fields?
A way for a module to discover what data is present.
A way to add, examine, remove a relationship. I'd suggest relations are named and there can be several relations per entity.
I hope this adds something.
Regards
Ruth
Communication
Communication will also need things like:
a. ability to enter summary of conversations held with individuals or organizations against the node, with date/time, description, etc.
b. ability to enter requests/events in a calendar e.g. for telephone conversation, meeting, lead etc. So the request types will need to be configurable or new content type?
Hello and a question about separate user vs. contact?
I just discovered this discussion last night so I thought I'd chime in.
The CRM's I've built have been for small organizations between 1000 - 2000 members so my experience is limited to smaller numbers as opposed to systems that manage millions of contact records. I've built custom ground up (non-Drupal) CMS's as well as civiCRM/Drupal and narrow focus Drupal + modules CRM's for very small organizations (less than 500 individuals).
I've always considered contact to be core to a CRM and since the user is so well integrated in Drupal, it seemed the obvious choice (to me) to use users as the base for my contacts and then build my CRM from there. Maybe I'm overlooking something but I fail to see an advantage of creating a separate contact entity if most of the functionality I'm looking for is available in the user and I can build it from there. civiCRM has a separate contact within the civiCRM part but in order to do anything meaningful, you have to create a corresponding user record on the Drupal side. One of the attractive things to me about a native Drupal CRM is that the contact could be so well integrated with the core of the framework.
That aside, I'm really interested in seeing what's going on with Drupal-CRM whatever that turns out to be.
I've moved my experimenting to Drupal 7 and have been mashing up experimental CRM-ish apps using: User, Location (user locations), GMap, Location Taxonomy, User Revision, User Diff, some custom location sub-modules and of course views. I haven't been using the Profile2 module but that's because I haven't reached the point where it is useful to me (yet). That said, I have made extensive use of customized profiles with Drupal 6 / civiCRM so that every member of a specific membership type got their own custom page within the website to advertise with so custom profile pages would be a valuable consideration for me.
For a native Drupal CRM, I've been concentrating recently on just the contact part of the CRM. I would like to have separate entities for Contacts, Locations, Employers. I think this means that I'll have to let go of the Locations module because as far a I know, each location record is unique to the user you assign it to and that won't be flexible enough in the long run if we have contacts that share the same address or location.
I would also like to see the CRM, however it comes together have the ability to switch on or off various components as required. For instance being able to sign up for and track "Events" on a per contact ability would be very useful for both contacts and administrators but not every organization needs it so it could be turned off for those who don't need it.
Anyway, that's the state of my thoughts these days about a Drupal CRM. I look forward to helping where possible and seeing how this project shapes up.
Cheers,
Andrew
Hi again awasson, Glad you
Hi again awasson,
Glad you could chime in :) We all hang around on #drupal-crm if you ever want to chat further or skype about anything and I could get you up to speed on whats going on. We have a sort of "charter" here: http://groups.drupal.org/node/179779 and I'm trying my best to keep a state of the CRM found here: http://groups.drupal.org/node/179524 up to date. The reality is these resources are not quite perfect yet, and the state of crm is moving so fast that it tends to be easier to just talk on skype or IRC.
One thing to note is there are 2 things going on here. There is a group of people developing seperate CRM systems and having regular meetings on skype. This is the "CRM-API" group. I am also part of a group of people working on a specific implementation of CRM called the Party module. We are making extensive use of Profile2 but not everyone in the crm-api group is.
I fully agree that one of the advantages of a native drupal CRM is having it integrated into the core framework. (One of the big advantages of Profile2 is it has been built to go into Drupal8, with all the smallcore stuff I dunno if this will happen). Personally all the use cases I have for CRM will have users and what we called "partys" totally integrated. So we're currently working on the system that strongly related users to parties. But once we've had this done it means we can relate users to loads of drupal stuff including customers in drupal commerce, or maybe facebook profile information. It also means that any CRM stuff we build on top of this works just as well for people who want users and parties to be related as for people who want them to be seperate.
Regarding your thoughts on "Locations". I think this is an advantage of our method of relating things. We're still figuring out how much of the "relations" module we use and how much we make ourselves but it means that (with Locations 4.x) you could attach location information to a Location Party type. Users would then be related to that entity meaning if you update information on the location (like a change of address) it would get updated everywhere.
Currently our thoughts (by our I mean the party people) is to build more of a framework or api which means site builders/ developers could put together highly specialised versions of CRM for really specific use cases. So we totally agree with what you said about events.
Again, feel free to come on to IRC and say hello if you want to find out more.
Jamie
Users and Contacts are not the same thing
I think a couple of posts are missing the point about what a contact is compared to a Drupal user.
They are not the same, and I don't think they should be.
A CRM system is about building a list of contacts, which could range from insignificant (from an organisation's perspective) to well worth following up on. They are potential clients or customers.
Drupal users are a whole different thing. They are the people who have some interest in your website, not necessarily your business. Users are there to know who has access to your website on some level.
Mixing the two seems extremely messy to me.
Drupal is only potentially a CRM base due to possibility of the division of different entities. Without that, it would have no base for such a system.
CRM Core deals with this well. Although it contains functionality to synchronize the two, they are separate records which makes perfect sense considering they are separate things.
This is handled well with the leading CRM solutions for D7
RedHen CRM, CRM Core, the Party module, and even CiviCRM handle the separation (and integration) of CRM contacts and Drupal users well already.
RedHen, CRM Core and Party also leverage the Drupal entity and field APIs such that CRM contacts are first class citizens of Drupal that play nicely with Views, Rules, etc.
http://yanniboi.wordpress.com
http://yanniboi.wordpress.com/2013/10/31/partyopoly-intro/
Just thought I should add this.
In Party we create an Entity called a Party which basically acts as a marker for the particular person in real life. We then make everything attach to that party including drupal users, individual profile entities, subsccribers, etc.
This is slightly different to CRM core where there are 2 things that are "synchronised" instead you have 1 thing that acts as a marker and lots of things attached to this.
This becomes particularly helpful with creating views and things. As you can just do views of parties which include parties with users or without for example.