Mission
To build a native, functional, usable Drupal CRM alternative within a reasonable timescale and with final approval of as many stakeholders as possible.
Goals
We should try to agree on these as early as possible. They are intended to further explain the mission above and we need to agree on them sooner rather than later.
- Minimal: only features that are necessary should be included.
- Extensibility: it should work with an ecosystem of extensions through robust and easy-to-use APIs.
- Usability: all key users should be comfortable performing their core operations.
- Integration: a number of existing external CRMs should be integratable with it.
- Maintainability: the community must trust in both support and also stability of APIs.
- Granular security: Security infrastructure that allows for view/write/create permissions for CRM entities and fields related to these entities
Constraints:
These could change along the way if we find the direction of the project is wrong.
- Any existing Drupal constraints: code quality, respect for existing hooks and doing it the Drupal way.
- If an existing Drupal project can do it (e.g. Views, Profile2) then let's try to integrate with that instead.
- Usability is defined by the success and "feelgood" factor of key user journeys, not by general accessibility of functionality to the user.
- What counts as required should be relevant to the end user, not the developer. Out of the box, the CRM must be usable, not just functional.
- API functions are sacrosanct after a release; they need to be documented, with code snippets for ease of use.
Targets
These might change dramatically as we develop the specification for the project. We should try to always be happy with the milestones we achieve, and when we plan to achieve them.
- Model layer defined in the core architecture complete
- Maintain basic contacts and address details
- Concrete deployment mechanism
- Export contacts as a vCard and one other format using entirely "ecosystem" modules
- Handle new activities and scheduling future reminders
- Build at least two "ecosystem" modules on the APIs which reliably integrate with external services
*Provide clear documentation on setup, integration and expansion to grow the use and involvement in the betterment of the module(s)
Further specification
Desirable functionality
*The ability to track enter information and journal the changes to information about individuals and other entities in the CRM (e.g businesses, organizations, families)
*Individuals do not need to be Drupal users
*Allow for the building of relationships (Steve Kessler is a member of the Kessler Family and is the owner of Denver DataMan is a volunteer for Teaming 4 Technology)
*Integrate with Drupal to track any type of interaction that a Drupal user does
*Provide a framework for other modules to track and provide information about individuals and other entities
*Track activities and create calendar items out of interactions
*Granular security that would allow only specific users to interact with specific entity records and fields in a record
*Provide the ability to export in common formats like vCard and iCal
*Integrate with Drupal Commerce
- Please add!
Expected end-user types and examples
*Sales teams
*Single person sales (one person Drupal shops)
*Organizations with membership
*Organizations without membership
*Schools
- Please add!
Likely use cases and scenarios
I have added a few here but they are not complete. Please help flesh these out and add more.
*A sales team uses the CRM to be able to add contacts, track interactions, define relationships between members of a company team and the individual and the relationship that individual has to organizations, companies, other staff members etc. This team needs to tie that information into information gathered from the social graph with sites like Facebook, Twitter and LinkedIn as much as possible. They need to not only be able to edit information and pull reports but they also need to be able to visually see how people relate to each other and organizations relate to each other. These users need a fast easy to use system that works on all of their devices. These users also need to be able to extend the functionality to add specific functions related to their sales process.
*Single person sales in for example a Drupal shop will need to track similar information to that of the sales team.
*Organizations will need to be able to track constituents, how they are related to each other and other groups. For example Josh is a volunteer at XYZ site and Sally is the volunteer coordinator at ZYX site so there is a connection between Sally and Josh and a connection between both of them and XYZ site. Organizations need to be able to track various types of opportunities that go well beyond a single sale. They may need to track grants they are working on, grant recipients, or other related projects.
*Organizations with membership will want their members to be able to add and edit their own profiles and maybe be able to see more information about their connections with other members. This is why granular security is so important. Membership organizations will want members to be able to be part of sub-groups. For example I am a member of the main group but I am also a member of this sub-group. This means that there needs to be different levels of access to support this. This may just be OG but it focuses on the fact that things that happen in OG need to be tracked and reported on.
- Please add!