Customer Relationship Management (CRM). Tiki does not currently offer a CRM feature.
For you conveniance I have created a pdf version of this wiki page, the pdf does include additional diagrams and table schemas, you can download the file from here contacts.pdf (478k) and CRM DB SCHEMA (97k)
The aim of this project is to create a set of CRM/ERP features for tiki, these will include a contact manager, relationship manager as well as various contact based activities such as Calls, Notes and Tasks.
Key Features
The core CRM functions will be built on the contacts module and will leverage form existing tiki features, such as:
At the heart of a CRM, ERP and many other groupware solutions are people and companies, therefore we plan to start by building a contacts system, similar in concept to outlook and then build on this with additional CRM functionality.
The Contacts Module
The contacts module will be based on relational entities, where an entity can be defined as a person, or organisation (company, school, family etc). The relationship between entities is M:M in that a single entity can have relationship with any other entity (for example eSTEVE->rFather->eAaron or eJoe->rEmployee->eSi3-LTD).
Contacts will provide the following key features
Important Note: Although the activity functionality is key to a CRM it is not deemed part of the contact module/application/feature, but should be implemented as a separate tiki feature. I will probably use trackers for this, although it would be nice to create some kind of shared scheme/table. This would allow me to list all the entries in the table base on my contacts id [Source (e.g. contacts) | Source Record id| Destination (e.g. trackers) | Content Id (tracker 21)]
Good news finally we think we have a db structure to work with, any comments about the design would be appreciated as it is a bit of a compromise, in that we have broken third normal form (duplicate attributes) but for performance reasons. The design was intended to be flexible as possible in-order to allow ldap mappings, in that all entities (people, organizations) and their units (departments, holiday home) could be defined using attribute sets. However after some testing we came to the conclusion that the performance hit would be to great on large data sets, so we duplicated primary attributes in the entity table. It is also questionable whether or not we should have separate tables for attribute sets and relationships, the main difference being other entities can participate in relationships. Referee to db section for information on how to obtain the schema and software.
The project is really still in the design stage, so please feel free to contribute. We intend to get the core contacts working over the next fee weeks, and will start implementing additional CRM features once the contacts module is stable. At this stage is CRM functionality is not part of the tiki CVS, once the feature is functional it will be left to the core tiki developers as to whether they want to distribute CRM as part of tiki.
Just me at the moment but eveyone is welcome!
I hope when we start providing some tangible code that some of the more talented tiki gurus will provide help, code etc.
I think mose will be involved at some point and also hope to enroll the expertise of Ben. who kindly left this note: FYI - We have created a fledgeling CRM module (more Sales Force Automation) and integrated it with Quickbooks. We track Customers, Sales Reps and Leads. Ben Tallman
Their are many groupware and standalone php based solution that offer some of the capabilities that will be present in tiki CRM, here is a short annotated list of some of the solutions I have played with.
Please see LDAP
The addition of relationships make that database design more complex than originally anticipated, which in turn is going to makes csv, vcard and ldap import/export more complex.
Watches (uid | event | object | hash | title | type | url | email)
ActionLog (Create | Delete etc) ModifiedOn | PageName | User | IP | comment
ProgCont (pid | contentId | publishdate | data)
This section describes the current database design for the CRM engine. The schema was created using DBDesigner4 which is available form http://www.fabforce.net/products.php the XML data file is available Contacts.xml (96.56 Kb) and can be used to directly create and modify the database tables.
The following ERM show the high level relationships between the tables.
The following section describes each of the entities show in the erm.
The entity table is used to store the primary contact details for either a person (default when imported) or Organisation (e.g. company, school etc.).
Primary details include
Design Notes: The entity table was designed to for speed, in most cases all the properties that make up an entity can be defined in this table, with the exception of entity attributes which vary depending on primary purpose of the system. Additional units (address and phone numbers), email and url’s can be defined at any time, however when creating these we must ensure that a primary unit exists (properties from this table) before creating a new one, if they do not we must create it before creating the new unit. This is required in-order to allow the primary (this table) properties to be substituted with new properties by setting the primary flag.
We did toy with the following concept, but decided that the performance hit would be too high, by replacing the entity definition (currently first last middle name) with a single description/name field and move the (first last middle name etc) into the attributes table. This would allow the system to be extended with any number of new entities for example projects etc. Although this type of definition is very flexible it is at this point deemed to abstract to be comprehend easily, even by the system developers.
The unit table is used to holds an entities paper address and phone contact details as well as providing a link to one or more, email, and url entities. Each unit has a name that describes the unit (e.g. Home, Office, Beach House, Sales Dept, etc.) and should be viewed as a container-link for url, emal as well as to other entities (relationship and roles) which have defined attributes.
Note: in the future we may replace the unit definition with a single description/name field and move the fields into the attributes table. This would allow the system to be extended with any type of unit definition. Although this type of definition is very flexible it is at this point deemed to abstract to be comprehend easily, even by the system developers.
Provides a list of email address and associated parameters for each email address, such as usePlain Text, use public key etc. Email will display a dialogue to select the primary email address; it’s setting as well as a list of other email addresses for this contact entity.
Note: could use tiki_user_email table for this.
Provides one or more url details, including any login id and password required to access the url. The url will display a dialogue to select the primary url (e.g. website), it’s account and password information, as well as a list of other website for this contact entity.
Note: This would be the ideal place to store net meeting and other real-time connection information. We could use directory Links (aka featured links) for this feature. Directory could be extended with comments, attachments and a picture to represent the category and or site. User_bookmarks is should be integrated with directory. Tiki_category_sites used by directory should be renamed directory_sites_category as it appears to be part of tiki categories. We could extend the directory with uid and password and use the directory instead. Although we may have an issue with updates as directory cats are assigned directory admin?
The synchronization table holds the information required to connect to external systems in-order to exchange packets of information between distributed entities.
This table will also be use to hold the configuration information for the following:-
Note: for additional comments please refer to comm servers and crm folders. We need a method to store and schedule ldap imports/exports/updates as well as any RSS/RDF feeds we wish to establish for crm-entities.
The crm_unit_url table also serves a very similar role. IMO the best thing is to create a similar solution to tiki-send-obejcts but with the addition of an interval setting and perhaps a name and description field. We also want to be able to select multiple servers for communications for each crm_folder.
Note: tiki currently provides similar functionality in the following features, it appears that many of these could be merged into a single comms lib.
tiki_dsn – requires login information
tiki_rss_modules –
tiki-send-objects - used for articles (received-article) and wiki pages(received pages)
tiki-send-blogs
tiki-rdf-xxx when it becomes available
tiki_admin_external_wiki
tiki_newsservers
Provides a means to allow each folder to be synchronized with one or MORE systems.
Attributes are simply a set of user-defined fields that can be associated with an entity as well as each of its units. Each attribute set can also be associated with one or more participants in-order to form links between entities; these relationships are described using attributes.
The role definition table is based on the tracker table and is used to define a role and its attributes.
The role definition table is based on the tracker table and is used to define a role and its attributes. Definition allows you to add, remove and configure a relationships attribute set, for example.
Type: org/person
Entity (FN) Name:
Compartment/unit: N/A, ALL, Select
Role:
Attributes Field 1: value
Attributes Field 2: value
Attributes Field 3: value
Attributes Field 4: value
Attributes Field 5: value
Attributes Field 6: value
The role field’s table is based on the tracker field’s table and is used to define each of the attributes associated with a role.
Note: need to extend the current table to include
Type: chkbox, option, listbox, multi-chkbox, mulit-opion
Data Source (if gathered from another module)
Select Query:
Update Query:
The role instance table is based on tracker item table and is used to map the field values to a specific role.
Note: may add notes and attachments tables in future.
Provides a list of entities for this relation id.
The activities table is a link table that links items stored in other tiki tables, and is used to store all of the actives for this entity; the default view mode is chronological order. Activities can be assigned to other users and reminders sent to that user.
CRM Folders provides a convenient way to group entities and can be mapped to tiki user groups. Preferences and permissions can be applied on a folder-by-folder basis.
Note: When importing records we need an option for automatically creating accounts base on the above. Also refer to Tiki User Groups and Permissions.
Tiki categories will be used to classify instance objects (e.g. a specific crm entity), we should allow the user to assign an entity to one or more categories. This table provides a lookup list of the tiki categories that this contact has been assigned to and is used to assign a single contact to one or more tiki categories. Categories can be used in association with folders, for example you may wish to define a folder for partners and add the contact information for each business partner, each partner can then be associated with one or more categories, for example life insurance, mortgages etc.
Note: we should be able to set permissions for categories for example who can view meeting, birthday, phone call, travel time, sick, on vacation, private, etc.
The global preferences table will hold configuration information that is global in nature, this table has yet to be refined.
Issues, Possibilities and Comments
The following table are not show, but may be included later
Other tables of interest
Tiki_wiki_attachments
Tiki image
Tiki files
Tiki comments
The following table are not show, but may be included later
How do we add crm as a tiki section?
Determine telephone call location based on ip location, this presumes that all number are entered in the correct international format. We also need to add the following: Dialing prefix (e.g. Calling Card #)
The following block/modules can be used to navigate contact entities and can be assigned in the same ways as tiki modules.
Maybe?
The global view is nothing more that a header with a number of command which are consistent across all views
Commands Global: The following commands are available from the list view
The list view is used display, sort and find entities, there are currently four tabs one for each of the following lists [People | Organizations | Relationships | Activity]. The administrator should have the option of specifying which fields are included in the list view.
Each list will provide the functionality to select and manipulate multiple, entities can also be sorted using any of the fields defined. Some field values may have shortcut links, for example if the email field is shown you can click on the email address which will launch the email app as specified by the contact preference.
Each list page will have a footer which will display the current page, number of pages, page 1…n, first, last, next and previous as well as the number of records and the first and last record currently display on the screen. The record creation date and the record last modified by xxx on date. May add link to select all.
The properties view is used to navigate and edit an entity and its associated properties. This screen(s) is split into two regions (top and bottom) the top region is used to display the entities properties (details, events and relations) and the bottom region is used to display the entities activity in chronological order (notes, tasks, calls etc).
Figure 1 - Mockup Example Screen
Person’s properties are split over four tabs, primarily to allow space for the activity log to be shown.
Note: Where are we going to put the entity notes (a single notes field) and digital ids (public key). Notes are specific to this contact and are not linked to activity, the main reason they are included is so information is not lost when importing contacts. However this field may be useful if you want to add notes about this contact e.g. take station road train to Bakersfield and wait for Fred. Alternatively we could create a note item in the activity list for this contact and mark it as the primary/sticky note!!
The summary view provides a read only view of the person. The view is a combination of user-selected data from the other tabs, details, events, relationships and other.
Provides the details for this person
Events are simply a convenient way of adding and viewing calendar events for a specific contact and will use the existing tiki group calendar, and can be used to define activities such as:
Meeting/Appointment Request/Schedule
Forward as iCal *.ics (add attach .ics)
Used to view and define relationships for this contact, relationship can be defined as
Creating new relations involves specifying the following instance information
The Relationship definition screen allows you to define the relationship role along with the attributes for this role. Attributes are based on tracker fields are there is no limit to the number of attributes allowed to describe a relationship.
Example Sale opportunity could be defined using the following attributes
Organization screen layout follows the same conventions as found in the person properties. Organization properties are used to define the various attributes that describe the organization, such as department’s etc. People may be linked/mapped to each department or roles but the details of that person are store in the person.
The events property view will follow the same conventions as those found under both people and organizational events.
The relation’s property view will follow the same conventions as those found under both people and organizational relations.
CRM & email: I'm no expert on CRM, but I've used a CRM program for a few years. It automatically files incoming emails along with the corresponding contact records (ie whichever record has the sender's email address). It's very convenient to view all the email correspondence with a particular individual.
With that in mind, the CRM module should be able to do something like this:
(1) Great document and great start.
thanks for your imput, this is the kind of stuff that will make it CRM/ERP work! I am currenly working on a revised page, which will incorp you comments!!
(2) Here is a start to a list of closed-souce competitors:
(3) There are fairly large differences between the top three and the bottom three in the above list. The top three focus on small-to-medium businesses and the bottom three focus on medium-to large businesses. I think Tiki CRM/ERP should be focused to target one set or the other.
We still need to do some work on defining the boundaries between CRM and ERP as there is an ERP group. However I belive Tiki CRM will traget the first three, at least for now. I firmly belive tiki will mature into a solution which can compete with the bottom three over time (probably the next 12-18 mths), and hopefully we drag expand CRM functionality as tiki grows.
(4) I think integration with other CRM/ERP/groupware applications needs to be thought through, particularly for small businesses who use standard off-the-shelf packages (i.e. Quickbooks) to manage their businesses. Tiki CRM/ERP should be able to share information with the likes of Quickbooks, MS Money, etc.
I agree, and I know Ben Tallman has created a CRM module (more Sales Force Automation) and integrated it with Quickbooks. However I do not think his code is GPL.
Saying that I think Quickbooks intergration should be part of the ERP tiki group, and this project should focus on CRM features. I am in the process of updating this page to reflect this.
(5) Another great feature is the ability for Tiki to tie itself into voicemail systems so that we could "see" our voicemails and access them through Tiki. Tiki could link itself into our cell phone or landline accounts. Some functions could be:
I like these ideas and would like to include them as CRM functions! I think the i think you can nav a voice mail system with dftm tons, but have no idea on how to download/record voice messages from a browser, it would be easy to save a binary blobs and addd comments and notes etc!
lets think ..... any ideas?
CRM and EMAIL perfect.
With a little rewiring of what is already in Tiki a basic CRM is attainable immediately.
These are my thoughts:
1. Streamline Database Integration for these modules in this order:
a. user/group/category
b. bookmarks
c. contact information
d. marketing production info/notes
e. email correspondance/folder
Reason:
DB integration in to one DB table/template for bookmark/user/contact/marketing/email info will allow you to streamline data in ONE SQL entry per user/contact/company editable by MANY forms. Why have a seperate DB for Bookmark and Contact? If the Bookmark will end up being the Contacts Web URL?
Every time you enter a Bookmark or Add USER....
a form is delivered that will allow you to enter:
Bookmark (company URL)
Category
Group
User (customer)
Contact Info (phone, addy, email, custom fields, "web url" is BOOKMARK)
Market/Prod (Galaxia Integration, File Gal, notes, Consultant, Newsletter)
Email (All Email related to this User/contact in it's own specefic folder)
CRM TEMPLATE:
Conglomerate above mentioned modules in to ONE FORM browsable with little tabs leading to contact info, marketing info and emails.
As follows:
Category-Group-User-Contact_Info-Market/Prod-Emails
NAVIGATION:
1. CATEGORIES : Click on one category "California"
2. GROUP : Click on a specific group "Film Studios"
3. USER : Click on specefic user/company in group : "Industrial Light and Magic"
4. CRM TEMPLATE : displays above mentioned CRM template viewing all "category,group,user", contact info, marketing info and emails related.
INSTANT BASIC TIKI CRM:
combine and refine already existing tiki modules:
1. user/group/category - preferences
2. bookmarks
3. contacts
4. webmail
1) |
18 Jul 2024 14:00 GMT-0000
Tiki Roundtable Meeting |
2) |
15 Aug 2024 14:00 GMT-0000
Tiki Roundtable Meeting |
3) |
19 Sep 2024 14:00 GMT-0000
Tiki Roundtable Meeting |
4) |
Tiki birthday |
5) |
17 Oct 2024 14:00 GMT-0000
Tiki Roundtable Meeting |
6) |
21 Nov 2024 14:00 GMT-0000
Tiki Roundtable Meeting |
7) |
19 Dec 2024 14:00 GMT-0000
Tiki Roundtable Meeting |