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 firstname.lastname@example.org
Now we are going to present how a CRM is used to manage the communication within and outside your organsations.
Note: in this session "CRM Tickets and Events", we will still use the examples of VIFIB to explain the concepts of "Event" and "Ticket" which are used to manage the interactions of a company with its contacts. So when you are practicing, please replace VIFIB with the company you created when you configured your ERP5 instance.
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.
Secondly, an Event can also "Follow Up" a Ticket, which is a record in the CRM all Events and documents related to the same subject. We will introduce it in the next tutorial.
Back to our example, as you can see in the above screenshot, in the detail page of a Event which is a reply email from one contact who got the original mail message from our VIFIB manager, it shows the Event Origin ( "SlapOS Ongoing!") and the Ticket which this Event Follow Up ( "Beta Developer Program"). So these two features help us present complex interactions in a clear way.
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.
The concept of workflow helps people to understand the entire process of handling Events. But it is abstract. In order to apply the workflow practically and efficiently, we will use the worklists.
Worklist ( click on the Tab "Worklists" on the sidebar, then you will see the page as shown in the screenshot) is a list showing the states of all your Events. The complete worklist of outgoing Events is a list of the standard process: from draft, planned, confirmed to sent Events (as you can see the highlighted part in the list above). The worklist is updated each time when you do a change to your Events. Thanks to this worklist , everyone can access to Events in different states easily, and then they will know what they are supposed to do every day, if they are the assignees or recipients shown in the Events' lists.
We can take the example of a Call-Center. Everyday, the Call-Center manager will review "Planned" Events and "Confirm" them. The operators will watch the "Confirmed" Events which have to be sent. And once they have emptied the list of Confirmed Events, they finish their tasks.
In our example, everyday, the VIFIB director Smets who is responsible for the operation of Events has to check his "Worklists" to see how many "Planned" Events are waiting to be reviewed and confirmed. Among them, he will see the email created by VIFIB community manager Cédric, review it and set it as "Confirmed". When Cédric checks his "Worklists" and finds the email has been moved to the "Confirmed" list, he will send it, then the email will go into the "Sent" list.
So the Worklist makes the process precisely and clearly stated, and facilitates the work of everyone.
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.
The same as outgoing Events, the worklists will simplify the work and give a good overview of what everyone has to do.
In our example, after sending the email to his contacts, VIFIB manager Cédric has to check the worklist to see if there is any "Received Events to Deliver" which might be the replies from the customers. So he can easily access to them and deal with them more efficiently.