邀请您参与 LadVen OS 测试申请演示
跳到主要内容

面向员工的外部门户

本页面面向发放外部访问并负责客户服务的人员:门户管理员、业务方向负责人和客户经理。它说明如何把客户接入外部门户、把其访问权限精确限定到所需范围,并在不危及内部数据的情况下支持协同工作。

门户在客户眼中的样子,见外部门户的客户门户页面。

位置

外部访问的管理集中在外部门户管理 (/extranet-governance) 板块。这里包括:

  • 客户关联——“用户—联系人—公司”关系列表,支持搜索和按状态过滤;
  • 关联向导——分步接入新的外部参与者;
  • 邀请——发放邀请、控制有效期和撤销邀请;
  • 所选关联的权限——公司策略、联系人策略和最终的有效策略;
  • 安全——面向外部参与者的密码策略和会话策略;
  • 渠道关联——客户接入的 Telegram 和小部件;
  • 诊断——当访问表现与预期不符时,检查具体关联。

外部访问的构成

客户对外部门户的访问建立在三件事之上:

要素是什么用途
关联用户与 CRM 联系人以及一家或多家公司之间的连接决定外部参与者以谁的名义、在哪个客户上下文中工作
访问策略面向公司和联系人的一组许可决定参与者可以使用什么:请求、聊天、通话、管道、渠道接入
邀请用于首次登录的一次性链接让客户自行创建密码并进入门户,无需手工传递账号凭据

发放访问之前,请确认 CRM 中已有最新的客户联系人和公司。关联到“草稿”联系人或重复联系人,日后会造成请求和文档的混乱。

关联向导

关联向导通过四个步骤完成客户接入:

  1. **用户。**查找已有的门户用户,或创建新用户:登录名、email、姓名。为新用户设置临时密码——客户凭邀请首次登录时会更换密码。
  2. **联系人和公司。**选择客户的 CRM 联系人以及其将要合作的公司。如果有多家公司,请指定默认公司——客户将从这家公司开始工作。
  3. **检查。**在确认前查看最终的“用户—联系人—公司”组合。
  4. **确认。**保存关联。之后即可发出邀请并配置权限。

示例:代理公司“启航”接入客户——“北光”公司。经理为林晓芸创建用户,选择她的 CRM 联系人,关联“北光”公司并将其设为默认公司。林晓芸只会看到自己公司的请求和文档。

关联状态:激活已停用已撤销。停用会暂停访问而不断开关系——适合合作暂停期。撤销则是最终终止。

邀请

邀请是客户首次登录的唯一正确方式。不要在往来消息中传递登录名和密码。

操作顺序:

  1. 选择要为其发出邀请的关联和联系人。
  2. 创建邀请——系统会生成激活链接。
  3. 通过可靠渠道把链接交给客户:发送到联系人已确认的 email,或使用已建立的安全沟通渠道。
  4. 客户打开链接,设置密码并进入门户。

邀请状态:待使用已使用已撤销已过期。邀请有有效期——如果客户没有及时激活,请撤销旧邀请并创建新的。不要重复转发同一条链接,也绝不要把一个客户的链接用于另一个客户。

访问策略

外部参与者的权限由两个层级组成:

  • 公司策略确定总体范围:这家公司的参与者原则上可以使用什么。
  • 联系人策略细化具体人员的访问,可以比公司策略更窄。

最终结果显示为有效策略——发放访问前应检查的正是有效策略,而不是各项单独设置。

主要许可:

许可开放什么何时启用
创建请求客户可以自行在可用管道中创建申请几乎总是——这是外部门户的主要场景
读取请求聊天客户能看到自己请求中的往来消息当团队准备在请求中开展讨论时
在请求聊天中发送客户可以在请求聊天中发言与读取一起启用——当需要对话而不只是状态时
通用聊天与公司之间独立于请求的长期沟通渠道面向经常提问的活跃客户
通话门户内围绕请求和通用频道的通话团队确实在门户中接听通话时
接入 Telegram客户可以绑定 Telegram 用于通知和沟通应客户要求,且渠道已获认可时
接入小部件客户可以在自己一侧绑定小部件用于与客户商定的集成场景
允许的管道限制客户可查看和创建请求的业务方向始终把列表收窄到确实需要的方向

从最小集合开始:创建请求、读取和发送请求聊天、一条工作管道。按需扩大访问——这比事后追查客户为何看到了多余内容要简单。

每次修改策略后,请在测试档案中或与客户一起检查结果:请求、文档和可用操作的列表应符合预期。

安全

安全板块配置外部登录的要求:

  • 密码策略——最小长度,必须包含小写和大写字母、数字及特殊字符。
  • 登录策略——触发锁定的失败尝试次数和锁定时长。
  • 会话——访问有效期、会话刷新期限和邀请有效期。

如果外部门户中流转合同、财务文档或个人数据,请收紧要求。请记住,策略作用于所有外部参与者:过短的会话会变成频繁的重复登录和客户抱怨。

面向客户的文档

客户在门户中只能看到已为其公司或联系人发布的文档。发布前请检查:

  • 文档属于正确的公司和联系人;
  • 文件中没有内部评论、草稿标注或其他客户的数据;
  • 文档状态对客户清晰:期望其做什么——阅读、审批还是签署;
  • 如果需要签名,客户可以执行签署操作。

签名请求由员工在文档发布后发起。不要“以防万一”地发布文档:客户门户中每一份多余的文件都会变成客户的疑问和团队浪费的时间。

团队侧的请求处理

  • 在具体请求的聊天中回复,而不是在通用频道——这样历史记录始终与请求绑定。
  • 不要让客户重复填写请求表单中已有的数据。如果缺少信息,请指明具体的字段或文件。
  • 保持请求状态最新:对客户来说,状态是了解进展的主要来源。
  • 如果请求在等待客户操作,请确保从状态和最后一条消息能明确看出需要客户做什么。

渠道关联

如果策略允许,客户可以绑定 Telegram 或小部件,在门户之外接收更新。在渠道关联板块可以看到哪些接入处于激活状态。当客户方负责人更换或合作结束时,请撤销这些关联。

诊断

如果客户看到了多余内容或看不到所需内容,不要靠手动转发文件和链接绕过问题。打开诊断,检查具体关联,并沿链条逐项核对:用户——联系人——公司——有效策略——对象可见性。几乎每个访问问题都出在其中某个环节。

结束合作

  1. 停用或撤销客户的关联。
  2. 撤销有效的邀请。
  3. 撤销 Telegram 和小部件的关联。
  4. 确认未完成的请求已关闭或已移交。

发放访问前的检查清单

  • CRM 中客户的联系人和公司是最新的且没有重复。
  • 关联指向正确的用户、联系人和公司。
  • 默认公司选择正确。
  • 有效策略已检查:管道、请求、聊天、通话、文档。
  • 邀请为正确的联系人创建,并已通过可靠渠道交付。
  • 客户首次登录后再次检查了访问。

常见错误

  • **“凭感觉”发放访问,没有检查有效策略。**公司或联系人的单项设置不能反映最终结果——要检查的正是有效策略。
  • **客户方多人共用一个账号。**为每个人创建单独的用户:否则无法弄清是谁写了什么、签了什么。
  • **转发旧邀请。**激活链接就是访问权限。已过期和多余的邀请要撤销。
  • **为了“省得配置两次”而放宽访问。**多余的管道和聊天迟早会让客户看到别人的上下文。
  • **项目结束后被遗忘的关联。**建立规则:在结束合作时检查处于激活状态的关联。

相关页面