TikiCRM will be developed at
http://crm.tiki.org and once it's good enough, it will de converted to a profile, so anyone can deploy in one click.
Developer notes
1-liner to re-install a fresh Tiki with profile
php installer/shell.php install; sh setup.sh; php lib/search/shell.php rebuild; php lib/profilelib/shell.php install Customer_Relationship_Management; setup.sh
Basic prefs
General
YAML
instructions: Setup
preferences:
feature_trackers: y
allowRegister: y
Wiki pages
YAML
objects:
-
type: wiki_page
ref: crm_home_page
data:
name: HomePage
content: wikicontent:Customer_Relationship_Management_HomePage
-
type: wiki_page
ref: crm_setup
data:
name: Setup
description: Post-Profile Setup Instructions
lang: en
content: wikicontent:Customer_Relationship_Management_Setup
Customer_Relationship_Management_HomePage
Customer_Relationship_Management_Setup
Trackers
YAML
objects:
-
type: tracker
ref: CRM-Contact
data:
name: CRM-Contact
allow: [creator_modification]
show: list_modification_date
-
type: tracker_field
ref: CRM_username
data:
order: 10
name: Username
type: user
tracker: $CRM-Contact
-
type: tracker_field
ref: CRM_firstname
data:
order: 20
name: First name
type: text_field
tracker: $CRM-Contact
-
type: tracker_field
ref: CRM_lastname
data:
order: 30
name: Last Name
type: text_field
tracker: $CRM-Contact
-
type: tracker_field
ref: CRM_organization
data:
order: 40
name: Organization
type: text_field
tracker: $CRM-Contact
Actions
YAML
objects:
-
type: menu
ref: CRM_Top_menu
data:
name: Top
description: A menu containing the base navigation of the site
collapse: none
items:
-
name: Home
url: ((HomePage))
-
name: My Profile
url: ((My Profile))
-
name: Membership
url: ((Membership))
-
name: Help
url: ((Help))
-
name: Setup
url: ((Setup))
permissions: [ admin ]
YAML
objects:
-
type: module
data:
name: menu
params:
id: $CRM_Top_menu
type: horiz
menu_id: tiki-top
nobox: y
groups:
order: 1
position: topbar
Features
Contacts and membership management
- Database of contacts, managed by admins
- Some of those contacts have logins and can update their profile as per User_Trackers
- Anonymous can create an account and update profile
- Registered users can become members (and pay) (there is more than 1 membership type) as per: http://doc.tiki.org/Payment#Membership_Management
- Members have access to privileged content (A members-only category)
Interaction management (ticket system)
- Make trackers for contacts with customers (ticket system)
- with admin field (visible to user) with time spent
- When ticket is closed, this is passed to the Credit system
- Registered users can use the ticket system (report issues, etc.)
- Admins can also use the ticket system to log interactions with contacts (whether or not they are members)
Actions by group
What are various actions that can be done by various user types in a typical CRM/Membership Management System?
Anonymous
- Have access to the public information about the organization
- Are invited to register to the site
Registered
- Can login and update their profile user tracker with name, phone number address, photo, etc.
- A main staff contact for each (so the best person calls when relevant)
- Note: there are some contacts which have no login and the info is solely maintained by staff
- Can pay for membership
- Payment is via Paypal or manual payment
- Can see if payment is due
- credits
- Can purchase
- Can check status
- Can use credits
- Can't see other profiles
- Can register to an event
- Can purchase an item (ex.: book) via the Shopping Cart
- Tickets (using Trackers)
- log a support ticket
- review status of tickets already submitted
Members
Staff
- Send Newsletters to members in good standing
- Can promote list of members on public site
- Can change the user type
- Ex.: Contact, Lead, Past Customer, etc.
- Can see full list of members
- Can edit wiki pages and member's profile
- Credits
- Can manage credits for all users
- View all and respond to all tickets
Admins
Questions
- Do we need to make the distinction between an individual contact and a company/account which has many contacts in it.
- Would be simpler not to. Otherwise, we need to figure something out with group trackers.
- interaction or actions, or should they be called something else?
Nice to have
- Admins can indicate: Time spent (minutes to be deducted from Credits, when ticket is closed)
- Admins can filter contacts by a criteria and contact them
- User groups can have access to a common contact database with different access levels. For example the contact database "sales" is readable by the members of "sales", "sales_senior" can add contacts and edit those contacts they own and "sales_admin" can reassign contacts to others and edit them all. Another user group "tech" will have their own contact database and so on.
- Each contact can have n different contact types with different values, for example 3 entries "telephone". new contact types can be defined
- for some contact types links can be generated (for example if I enter data into a homepage field, this is a link to the website, for a telephone number this is a link to a helper script on my pbx server to trigger a call and for an email it is a mailto link of course.
- Notes can be attached to a contact which are visible to all or to the author only
- Documents can be attached to a contact
- contacts can be grouped in relations: Bill is the superior of Joe, Lisa is the wife of Joe etc.
Long term
- Show off credit system
- Shopping cart is available to replenish credits (this part needs to be coded)
- Use payment to run a Data Channel (to show off the new feature)
Todo
alias