This visual guide is part of a collection of documents created by the One Student One ERP (OSOE) project in collaboration with Institut Mines Telecom, Telecom Bretagne, Dresden University of Technology and the South Westfalia University of Applied Sciences. It can be used to teach modern ERP theory and practice to undergraduate students or professionals.

Copyright: You are free to copy, distribute, display, and perform the work under the following conditions: you must attribute the work in the manner specified by the author or licensor; you may not use this work for any commercial purposes including training, consulting, advertising, self-advertising, publishing, etc.; you may not alter, transform, or build upon this work. For any reuse or distribution, you must make clear to others the license terms of this work. Any of these conditions can be waived if you get permission from the copyright holder through a commercial license or an educational license. For more information, contact info@nexedi.com

Due to the number of persons with whom we interact, and the growing number of communication tools of which only few leave a trace (eg, emails), and the difficulty of organising the trace of communication in a central system (eg, Emails are stored in personal mailboxes, Fax in a specific place etc.), the complexity of keeping trace of the communication within and outside of the organisation makes it difficult to learn from our experience and to share all the informations we have about one contact of our organisation. This gave birth to the CRM systems.

CRM stands for Customer Relationship Management. These systems have been created to keep track of every interaction that you have with your customers. Today, many CRM concepts can be applied to other fields. Based on the notion of "Event" and "Ticket", they can also be used to track other forms of relations, such as your relations with suppliers, staff, media, etc. (eg, the Supplier Relation Management-SRM). So a CRM includes concepts of Events, Campaigns, Meetings, Sale Opportunities and Support Requests, is used for managing all the communication between our organisations and all the contacts.

We will begin with the feature "Event" to explain the process of Customer Relationship Management.

Let's first see a VIFIB Event as an example, and then we will explain in detail how the process of Event works.
In a marketing campaign "Beta Developer Program" which aims to increasing the awareness of SlapOS ( a new open source Cloud developed by VIFIB) by announcing the campaign and hiring software developers, Cédric, the community manager of VIFIB sent an email to his contacts who might be interested in the program and become developers of SlapOS in the future. After these contacts have received the email, they replied to the VIFIB manager by email, which are well stored in the CRM system for future reference.
The Event Title is "SlapOS ongoing!", the Sender is Cédric de Saint Martin (SlapOS Community Manager from VIFIB), the Recipients are Cédric's 14 contacts including software developers, company managers, college professors, etc. The Event Contents are shown in the picture above.

A CRM system uses what we call "Events". Events are computerised records of every interaction which happens between two or more persons.

In our example, each email sent from one person to another is one Event.

Each kind of interaction has its own record within the CRM system. We commonly distinguish these kinds of events: When you meet with a client, you can use "Visit "; When you want to add information about the interaction you have with the client, you can use " Note "; When you have a phone call with someone, you can use " Phone Call " to write a summary of your conversation during the call; Most CRM systems allow you to directly send emails from the central system to any email address using " Mail message ", moreover you can also ingest the mails you receive; When you receive many letters or faxes, you can scan them and add them to " Letter " and " Fax "; " Web Message " is isually used when someone outside the company is posting a message on a public web site (like erp5.com); There are also " Short Message ", " Site Message ", eg, site message is usually used for to send a message to all users of the ERP system etc.
Depends on your business you might have more kinds of interactions.

In our example of communicating by emails, the Event Type is Mail Messages.

Besides different types, the interactions also have different natures.
The nature of an event is classified by its objective: complaint, announcement, advertisement, information, inquiry, spam, etc. We need to classify the events by their natures: an email sent to complain doesn't have the same meaning with an email sent to advertise.
Depends on your business field, the user of the CRM system will choose to classify the events with their own categories.

In our example of the mail message sent by VIFIB manager, the Event Type can be considered as an Information.

An Event, which is representing a movement of resource (information, inquiry, etc.), is going from someone to one or more recipients. In a CRM, we distinguish the Events not only by their contents, but also by their senders.
The Event always has only one sender, but can have an infinite number of receivers. The same message sent by two persons to one same receiver will be represented as two different Events, while the same message sent from one person to many others will be represented as a single Event.

In our example, the email sent by the VIFIB manager to his contacts is one single Event because of the same sender, while all those replies are different Events, even though the contents might be the same.

Since events all have a sender and a recipient, we can tell in which way the event is going.
We will distinguish incoming events from outgoing events: Incoming events are events which have been initiated by persons outside the organisation; Outgoing events go from your organisation to external persons.
This distinction is really important since you won't handle the same way the preparation of outgoing events and how you take care of incoming events.

In our example, the Mail Message sent by VIFIB manager is an outgoing Event, while the replies from his contacts are incoming Events.

By linking related Events together using "Event Origin" and "Follow Up" , you can easily keep track of interactions between your organisation and the external contacts.

Firstly, by using "Event Origin", even complex interaction can also be shown clearly

A single interaction happens between only two persons, but it can have various event types (as shown in the left side), according to the needs of the sender and receiver.

However, for complex interactions (as shown in the right side), we can have many interlocutors within it, done by different persons inside and outside our organisation, using various communication tools. In this case, if we list the events related to one person, we will only have a partial view of the conversation.

As we can see in both tables with records of detail discussions happened between VIFIB staff and its customers in subject of a new product offer, the event N°1 is the reason why the customer replied and created the event N°2. So we can say that the event N°1 is the origin of the event N°2.

So using "Event Origin" can correctly and precisely represent the relation between events.

The upper part of this illustration shows the workflow of Outgoing Events.

Depending on the assignment you have, you will be able to perform one or many actions on outgoing events.

The standard process has four steps:
Firstly, you create by drafting a new Event from the outgoing message's sender's Person File (state "draft" );
Secondly, you plan the Event (same meaning as "request for review" ) (state "planned " );
Thirdly, the manager confirms the Event ( the manager or the person who is responsible for supervising the operation of this Event ) (state "confirmed" );
Finally, you send the Event (state " sent " ).
If the Event has already been edited and only needs to be sent, you can send directly after you create the outgoing Event at the state of draft or planned. You can also delete or cancel the Event during the process.

Under the direction of such a workflow, you can manage from a three-person organisation to a big call-center.

In our example, the Sender Cédric de Saint Martin (community manager) created the Event as an outgoing mail message from his Person File. After drafting the mail, he set the state as "planned", so the VIFIB director Mr Smets who is responsible for the operation of all the Events can find in his "Worklist" that he has a "planned" Event to review and approve. When the manager is OK with everything, he will confirm the Event. When Cédric see the Event's state changed from "draft" to "confirmed", he knows that the mail is approved and ready to be sent. After he sends the email to the Receivers - his contacts, the Event "SlapOS Ongoing!" would be stated as "sent", and the Outgoing Event Process is finished.

Incoming Events have a different workflow as shown in the second part of this illustration: they can either be created manually (e.g, you can input an email which is a support request or a reply from a customer to the company as a new incoming Event), or automatically (e.g, between 2 departments who use the same ERP system, an Event can be exchanged by using the Action "Declare as Received" . If an Event is initially outgoing for department A - the sender, it becomes incoming Event for department B - the recipient, once A has sent the Event and B declared it as received).

The standard process has three steps:
Firstly, you create by drafting the new Event from the incoming message's sender's Person File (state " draft" );
Secondly, you declare the Event as received ; you can also define another recipient instead of you (the original recipient), if it is another team member who is responsible to handle the Event (state "received" );
Thirdly, the recipient create Follow Up Ticket to record all the future interactions related to this Event, then the Event will be delivered automatically; you can also deliver the Event directly after you receive it (state " delivered" ).
If the Event is "Declare as Received" from an outgoing Event which has already been sent by another department of your company, they will be also stated as "received" , so the process begins from the action "create Follow Up Ticket"/ "Deliver the Event ".

The Final state "delivered" of incoming Event indicates to all the team members that this incoming Event has been acknowledged by the recipient to handle it.  

In our example, after sending the email, VIFIB manager Cédric sent got a reply from one contact. So a new incoming Event will be created. Then the "received" Event can be processed in two ways: either be replied by Cédric the Recipient directly, or be assigned to another person in the Support Team to handle the Event, just by changing the Recipient and creating a Follow Up Ticket.