现在我们来介绍如何运用ERP系统的CRM模块来管理组织内外的沟通。

注意：本章节我们会继续使用VIFIB来介绍ERP5的“集合”和“事件”模块功能。因此当您实践您的ERP5实例的时候，请用您配置ERP5的公司替换VIFIB。

由于交流人数的增加，不留记录的通讯工具的增加，以及在集成系统中跟踪交流的难度增大（像邮件存储在个人邮箱，传真存储在特别的地方等），追踪交流信息的复杂性阻碍我们从经验中获得学习，以及分享重要联系人的信息。这就造就了CRM系统。

CRM表示客户关系管理。这些ERP系统被用于记录您与客户的交流信息。今天，CRM的许多概念被扩展。基于“事件”与“集合”的概念，我们可以运用CRM来记录您与供应商，员工以及媒体的关系（例如供应商关系管理--SRM）。因此在ERP5中，CRM系统包含了事件，活动，会议，销售机会以及客户支持请求，它们被应用管理我们的组织于所有联系人之间的交流。

现在我们就已“事件”的特征开始介绍ERP5的CRM流程。

现在就先来看一个VIFIB事件的例子，然后我们将解释事件的详细流程。
现在VIFIB有一个营销活动“Beta Developer Program”，旨在通过招聘软件开发员来提高SlapOS（一个由VIFIB开发的新的开源云）的知名度。VIFIB社区经理Cédric De Saint Martin将这项招聘信息以电子邮件的方式发送给他的联系人，他们是可能对该活动感兴趣的并且有意向成为SlapOS未来开发员的编程员。当这些联系人收到邮件后，他们就会通过邮件方式回复该VIFIB经理，而这些发送于接收邮件就将存储在CRM系统中以供将来检索使用。
事件标题是“SlapOS ongoing!”，事件 发送人是Cédric de Saint Martin （VIFIB 的SlapOS社区经理），事件接收人是Cédric的14为联系人，包含了软件开发员，公司经理，学校教授等等。 事件内容如图所示。

ERP5的CRM系统使用所谓的“事件”概念。事件是存储在电脑中的发生在两个以上联系人之间的交流记录。

本例中，每一封有一人发给另一人的邮件就是一个事件。

每项交流在CRM系统中都有记录。我们通常将事件分为一下类别：当您访问一位客户或接受客户来访时，您可以使用访问；但您希望为与客户的交流添加引用时，您可以使用笔记；当您与某人有电话联系，您可以使用电话来讲您的谈话概况记录下来；许多CRM系统提供通过邮件信息由系统中心直接发送邮件的功能，您还可以向系统录入您接收的邮件；当您接收许多信件或传真，您可以将其扫描并通过信件和传真存入CRM系统；站内信息是站内员工间发送的短信息，例如ERP5的用户VIFIB员工之间通过ERP5站内信息发送短消息：网站信息专门用于记录组织外人员在您的公开网站（例如erp5.com）上发布的信息。
基于您自己的业务或许需要配置更多种类的交流事件。

本例中，事件种类是“邮件信息”。

除了不同种类，事件还拥有不同性质。
事件性质是通过其目的划分的：投诉，公告，广告，信息，查询，垃圾邮件等。我们必须根据事件性质对其分类：一个投诉事件和一个广告事件是完全不同的。
基于您的业务范围，CRM系统用户需要为事件选择分类类别。

本例中VIFIB经理要发送的邮件信息的事件类型是一个“信息”。

一个事件代表了一项资源（信息，查询等）的运动，它将由一个发送人那里到达一个或多个接收人。在ERP5中，我们不仅已事件内容来区分事件，还以它们的发送人来区分事件。
一个事件通常只有一个发送人，但却可以有无数个接收人。由两个发送人发出的事件是两个不同事件，而有同一个发送人发给许多接收人的事件则是一个单独事件。

本例中，有VIFIB经理发送的事件是一个单独事件，因为该事件只有一个发送人，但是对此事件的回复就是多个不同事件，即使回复信息可能相同。

由于事件都有一个发送人和接收人，因此我们就知道事件的方向。
我们需要区分接收事件和发出事件：接收事件由组织外人员发送给组织内部的；发出事件是由组织内部人员发送给外部人员的。
这项分类非常重要，因为您处理发出事件和接收事件的方式和流程是不同的。

本例中，由VIFIB经理发送的邮件信息是一个发出事件，而来自其联系人的对该邮件的回复是接收事件。

连接事件可以通过“发起事件”以及跟进集合进行，这样您就可以轻松跟踪您的组织与外部联系人的所有交流事项。

首先，通过“发起事件”功能，即使复杂的交流事项也可以被清晰列出。

一个单一事件发生在两个联系人之间，但它可以根据发送人和接收人的需求使用不同的事件类型（如左图所示）。

但是，复杂事件（如右图所示）可以涉及许多联系人，他们是组织内外成员，使用不同的通讯工具。这种情况下，如果我们列出与一个人相关的事件，我们只能得到部分交流信息。

如图所示，该表格记录了所有发生在VIFIB员工及客户关于一个新的产品发盘之间的讨论。事件N°1是客户进行回复并创建事件N°2的原因，因此我们可以说事件N°1是事件N°2的发起事件。

因此，通过使用“发起事件”可以正确并精确地表现事件之间的关系。

上图显示ERP5发出事件的流程。

基于您的任务指派，您可以对发出事件进行一项或多项操作。

标准操作有四个步骤：
首先，从发出事件的发送人文件中草拟建立该事件，此时事件状态是“草拟”；
其次，计划该事件（即“要求审阅”），状态变为“已计划”；
然后，经理确认该事件（公司经理或者该事件操作的负责人），状态变为“已确认”；
最后，您就可以发送该事件，状态变为“已发送”。
如果事件已被编辑，正等待发送，您可以在事件建立后“草拟”或“已计划”状态下直接发送。您也可以在该过程中删除或取消事件。

根据该事件工作流程的引导，您可以管理三人小公司直至大型的客户服务中心。

本例中，事件发送人Cédric de Saint Martin（社区经理）以发出的邮件信息事件的方式从他的人文件中建立了新的事件。草拟事件内容之后，他设置该事件为“已计划”，因此负责所有事件运行的VIFIB公司经理Smets先生就可以在“我的菜单”中“待审阅的已计划事件”中查看事件。当经理认可了该事件内容，他就可以确认该事件。当Cédric看到事件状态从“草拟”变为“已确认”，他就知道他的事件已被批准并可以发送了。当他将邮件发送给事件接收人--他的联系人之后，该事件“SlapOS Ongoing!”的状态就会由“已确认”变为“已发送”，从而发出事件程序就结束了。

如图示第二部分所示，接收事件有不同流程：它们可以被手动创建（例如，您可以将一个来自客户的支持请求或回复邮件内容以新建接收事件的方式输入系统），或者由系统自动创建（例如，一个事件可以通过“声明已接收”的操作在使用相同ERP5系统的两个部门之间传递。如果该事件起初是由部门A创建的发出事件，即，部门A是发送人，那么当部门B声明接收该事件后，它就成为一个新建的接收事件，即，部门B是接收人）。

标准的接收事件流程有三步骤：
首先，从接收事件发送人的人文件草拟建立该事件，此时事件状态是“草拟”；
其次，您可以声明事件已接收；您也可以定义事件接收人（如果您需要指派另一组织成员来处理该事件，而非由您--事件初始接收人来处理），状态变为“已接收”；
然后，事件接收人创建跟进集合以记录将发生所有与该发起事件相关的事件，该事件就会被自动交付；您也可以在接收事件之后手动交付事件操作。这两种操作之后事件的状态变为“已交付”。
如果一个由另一部门发出的事件被“声明已接收”而自动成为新建的接收事件，它的状态就是“已接收”。然后该事件的处理流程就从上一步“创建跟进集合”/“交付事件”开始。

接收事件的最后状态“已交付”就告知所有组织成员该事件已经被接收人“认领”并会对其负责。

本例中，发送邮件信息事件之后，VIFIB的社区经理Cédric收到一个联系人的回复。于是他就基于该回复的内容创建了一个新的接收事件。接着该事件就可能被以两种方式处理：或者由事件接收人Cédric直接处理（例如，回复发送人），或者Cédric将该事件通过改变“事件接收人”的方式指派给另一组织成员，并建立一个跟进集合以便将来跟进该事件的处理过程。