-
Notifications
You must be signed in to change notification settings - Fork 0
Home
Welcome to the EspoCRM knowledge base wiki! This wiki is meant to gather all the knowledge, documentation and best practices around the usage of EspoCRM by humanitarians. The general documentation on EspoCRM can be found here.
CRM stands for Customer Relationship Management, and it can refer to a technology, a process or a strategy. Usually, a CRM is used for business, however, with a growing need of data management, more and more humanitarian organisations are establishing their own CRM.
EspoCRM is just one of the available Open Source CRM software. It allows you to manage registrations, transactions, and all information needed in CVA programs.
There are many reasons why 510 has chosen Espo over other CRM systems, below are just a few reasons
- Open Source
- Active, large, supportive community
- It is constantly updated and maintained, being used by 50k+ companies
- Highly customizable
- Allows for front-end customization (meaning that you do not need an IT background to customize the system to your needs)
- Successfully used by multiple NS for sectorial and/or multi-purpose cash programs
- Relatively low costs (that are related to hosting and maintenance rather than the system itself)
- Generally, it is free to use, expect for a few advanced functionalities
Functionality | Example |
---|---|
Create/edit/delete entities, from the UI or other systems | Register PA with Kobo and automatically create an entity in EspoCRM |
Link entities with one another | Automatically link payments to a unique PA |
Role-based access control | Only CVA Co. validates inclusions of PAs |
Integration with financial data management systems / FSPs* | Execute payments through 121 or RedRose |
Send emails to beneficiaries | Notify PA of delay in next payment with email |
Integration with programmable communication tools (e.g. Twilio)* | Collect feedback from PA with WhatsApp, Viber, Facebook, etc. |
Automate processes with workflows* | Automatically send a message to PA if a payment fails |
- needs the EspoCRM advanced pack
Add here the document that Olga developed on prerequisites for Espo
- Infrastructure (servers, database, etc.): 68 - 142 CHF per year
- Advanced package: 276 CHF (one-time only)
- Third-party integrations: none (excluding the third-party costs, e.g. SMS, transactions…)
- Trainings: 1 week for admins, 2 days for users
Comparison with other providers
- Zendesk: 633 - 1,280 CHF per user per year
- Salesforce: 287 - 3,793 CHF per user per year
- MS Dynamics: 575 - 17,243 CHF per user per year
- Data modeling is the process of defining and representing an information system, and how its parts connect with each other.
- The goal is to clarify and standardize what data we collect, how we store it and what we can do with it.
- Data can be modeled at various levels of abstraction, from high-level to very detailed.
- Guiding principles, in order of importance:
- Operational / legal requirements:
- Logical consistency
- Simplicity
- Easier to explain how the system works and hand it over to NS / colleague
- Easier to integrate with other systems, because requirements are specified
- Nudges your programmatic counterpart (e.g. CVA Co.) to take decisions and define processes
- By defining the data model upfront, easier to avoid bottlenecks, redundancies and inefficiencies later in the process. (F.e. Inconsistencies in how data is collected among NS branches, Manual copy-paste of data from one format to the other, Impossible to integrate with FSP because of missing data)
- Identify the entities, i.e. the main objects of your information system
- Person Affected
- Payment
- Feedback message
- Identify properties of each entity
- Person Affected - Full name: text, Age: number, etc
- Payment - Amount: number, Execution date: date, etc
- Feedback message - Text: text, Phone number: number, etc
-
Identify relationships among entities
-
Identify relationships among properties of entities
Cardinality | When to use it | Example |
---|---|---|
Many to one (*:1) | Multiple instances of A are related to one instance of B | A: payment, B: person affected |
One to one (1:1) | Unique instances of A are related to unique inst. of B | A: host family, B: host house |
One to many (1:*) | One instance of A is related to multiple instances of B | A: branch, B: volunteer |
Many to many (*:*) | Multiple instances of A are related to multiple inst. of B | A: activity, B: person affected |