面向员工的外部门户
本页面面向发放外部访问并负责客户服务的人员:门户管理员、业务方向负责人和客户经理。它说明如何把客户接入外部门户、把其访问权限精确限定到所需范围,并在不危及内部数据的情况下支持协同工作。
门户在客户眼中的样子,见外部门户的客户门户页面。
位置
外部访问的管理集中在外部门户管理 (/extranet-governance) 板块。这里包括:
- 客户关联——“用户—联系人—公司”关系列表,支持搜索和按状态过滤;
- 关联向导——分步接入新的外部参与者;
- 邀请——发放邀请、控制有效期和撤销邀请;
- 所选关联的权限——公司策略、联系人策略和最终的有效策略;
- 安全——面向外部参与者的密码策略和会话策略;
- 渠道关联——客户接入的 Telegram 和小部件;
- 诊断——当访问表现与预期不符时,检查具体关联。
外部访问的构成
客户对外部门户的访问建立在三件事之上:
| 要素 | 是什么 | 用途 |
|---|---|---|
| 关联 | 用户与 CRM 联系人以及一家或多家公司之间的连接 | 决定外部参与者以谁的名义、在哪个客户上下文中工作 |
| 访问策略 | 面向公司和联系人的一组许可 | 决定参与者可以使用什么:请求、聊天、通话、管道、渠道接入 |
| 邀请 | 用于首次登录的一次性链接 | 让客户自行创建密码并进入门户,无需手工传递账号凭据 |
发放访问之前,请确认 CRM 中已有最新的客户联系人和公司。关联到“草稿”联系人或重复联系人,日后会造成请求和文档的混乱。
关联向导
关联向导通过四个步骤完成客户接入:
- **用户。**查找已有的门户用户,或创建新用户:登录名、email、姓名。为新用户设置临时密码——客户凭邀请首次登录时会更换密码。
- **联系人和公司。**选择客户的 CRM 联系人以及其将要合作的公司。如果有多家公司,请指定默认公司——客户将从这家公司开始工作。
- **检查。**在确认前查看最终的“用户—联系人—公司”组合。
- **确认。**保存关联。之后即可发出邀请并配置权限。
示例:代理公司“启航”接入客户——“北光”公司。经理为林晓芸创建用户,选择她的 CRM 联系人,关联“北光”公司并将其设为默认公司。林晓芸只会看到自己公司的请求和文档。
关联状态:激活、已停用、已撤销。停用会暂停访问而不断开关系——适合合作暂停期。撤销则是最终终止。
邀请
邀请是客户首次登录的唯一正确方式。不要在往来消息中传递登录名和密码。
操作顺序:
- 选择要为其发出邀请的关联和联系人。
- 创建邀请——系统会生成激活链接。**请立即复制:**该链接只在此刻显示一次,之后不会再出现在邀请卡片中。若未复制就关闭页面,就必须撤销邀请并重新签发。
- 通过可靠渠道把链接交给客户:发送到联系人已确认的 email,或使用已建立的安全沟通渠道。
- 客户打开链接,设置密码并进入门户。
邀请状态:待使用、已使用、已撤销、已过期。邀请有有效期——如果客户没有及时激活,请撤销旧邀请并创建新的。不要重复转发同一条链接,也绝不要把一个客户的链接用于另一个客户。
访问策略
外部参与者的权限由两个层级组成:
- 公司策略确定总体范围:这家公司的参与者原则上可以使用什么。
- 联系人策略细化具体人员的访问,可以比公司策略更窄。
最终结果显示为有效策略——发放访问前应检查的正是有效策略,而不是各项单独设置。如果窗口显示的是技术性管道 ID 而不是名称,请将其视为诊断提示:在策略编辑器或管道列表中核对对应关系,不要把该 ID 当作面向用户的名称发布。
主要许可:
| 许可 | 开放什么 | 何时启用 |
|---|---|---|
| 创建请求 | 客户可以自行在可用管道中创建申请 | 几乎总是——这是外部门户的主要场景 |
| 读取请求聊天 | 客户能看到自己请求中的往来消息 | 当团队准备在请求中开展讨论时 |
| 在请求聊天中发送 | 客户可以在请求聊天中发言 | 与读取一起启用——当需要对话而不只是状态时 |
| 通用聊天 | 与公司之间独立于请求的长期沟通渠道 | 面向经常提问的活跃客户 |
| 通话 | 门户内围绕请求和通用频道的通话 | 团队确实在门户中接听通话时 |
| 接入 Telegram | 客户创建关联后通过 Telegram 机器人完成;只有投递正常时通知才算就绪,旧关联即使显示已关联也可能需要迁移 | 应客户要求,且渠道已获认可时 |
| 接入小部件 | 客户发送空请求体创建关联,并在门户中检查最终状态 | 用于与客户商定的集成场景 |
| 允许的管道 | 限制客户可查看和创建请求的业务方向 | 始终把列表收窄到确实需要的方向 |
从最小集合开始:创建请求、读取和发送请求聊天、一条工作管道。按需扩大访问——这比事后追查客户为何看到了多余内容要简单。
每次修改策略后,请在测试档案中或与客户一起检查结果:请求、文档和可用操作的列表应符合预期。
启用通话后,客户可以在请求或通用聊天上下文中发起或加入通话。通话期间可使用静音、摄像头、屏幕共享和全屏;离开结束客户的参与,获授权的参与者可用结束结束通话。如果权限、设备或媒体访问被拒绝,按钮可能隐藏或显示错误;请检查权限和频道状态,不要盲目重试。
安全
在外部门户管理页面中,安全板块目前用于查看策略,而不是编辑表单。它标记为由外部管理,并显示所选配置档(smb、business、enterprise 或 custom)、密码要求,以及访问、会话刷新和邀请的有效期。如果存在覆盖值,页面还会以技术视图显示当前覆盖和解析后的策略;刷新会重新加载数据。请在部署指定的策略来源中修改这些规则,不要承诺可以在此板块直接保存。
页面显示的参数包括:
- 密码策略——最小长度,必须包含小写和大写字母、数字及特殊字符。
- 登录策略——触发锁定的失败尝试次数和锁定时长。
- 会话——访问有效期、会话刷新期限和邀请有效期。
如果外部门户中流转合同、财务文档或个人数据,请收紧要求。请记住,策略作用于所有外部参与者:过短的会话会变成频繁的重复登录和客户抱怨。
面向客户的文档
客户在门户中只能看到已为其公司或联系人发布的文档。发布前请检查:
- 文档属于正确的公司和联系人;
- 文件中没有内部评论、草稿标注或其他客户的数据;
- 文档状态对客户清晰:期望其做什么——阅读、审批还是签署;
- 如果需要签名,客户可以执行签署操作。
签名请求由员工在文档发布后发起。不要“以防万一”地发布文档:客户门户中每一份多余的文件都会变成客户的疑问和团队浪费的时间。
团队侧的请求处理
- 在具体请求的聊天中回复,而不是在通用频道——这样历史记录始终与请求绑定。
- 不要让客户重复填写请求表单中已有的数据。如果缺少信息,请指明具体的字段或文件。
- 保持请求状态最新:对客户来说,状态是了解进展的主要来源。
- 如果请求在等待客户操作,请确保从状态和最后一条消息能明确看出需要客户做什么。
渠道关联
如果策略允许,客户可以创建 Telegram 或小部件关联,但创建并不表示投递已经就绪。如果门户提示 Telegram 集成未连接,管理员必须先启用它,客户才能重试关联。Telegram 首先显示待确认状态和有时限的一次性代码。不要发布或截图该代码:客户应按指定流程将其发送给 Telegram 机器人,然后点击我已连接 — 刷新。只有投递正常时通知和沟通才算就绪;旧关联即使显示为已关联也可能需要迁移;已撤销表示连接结束。小部件不使用 Telegram 代码:发送空请求体后,在门户中检查关联状态。客户方负责人更换或合作结束时,请撤销待确认和已关联的连接。
已关联并不总是表示投递正常:旧关联可能仍显示为已关联,但实际需要迁移。此时管理员应在治理页面启动迁移,或请客户重新连接 Telegram。客户要向机器人发送完整的 /bind <code> 命令,而不只是代码,然后刷新关联。代码只能使用一次并有有效期;重新加载或其他标签页接管后,本地代码可能消失,应重新生成。代码过期、遗漏命令/机器人错误,以及 Telegram 已绑定到其他账户,需要不同的处理:新代码只适用于前两种情况,账户冲突必须由管理员释放。
诊断
如果客户看到了多余内容或看不到所需内容,不要靠手动转发文件和链接绕过问题。打开诊断,检查具体关联,并沿链条逐项核对:用户——联系人——公司——有效策略——对象可见性。几乎每个访问问题都出在其中某个环节。
结束合作
- 停用或撤销客户的关联。
- 撤销有效的邀请。
- 撤销 Telegram 和小部件的关联。
- 确认未完成的请求已关闭或已移交。
发放访问前的检查清单
- CRM 中客户的联系人和公司是最新的且没有重复。
- 关联指向正确的用户、联系人和公司。
- 默认公司选择正确。
- 有效策略已检查:管道、请求、聊天、通话、文档。
- 邀请为正确的联系人创建,并已通过可靠渠道交付。
- 客户首次登录后再次检查了访问。
常见错误
- **“凭感觉”发放访问,没有检查有效策略。**公司或联系人的单项设置不能反映最终结果——要检查的正是有效策略。
- **客户方多人共用一个账号。**为每个人创建单独的用户:否则无法弄清是谁写了什么、签了什么。
- **转发旧邀请。**激活链接就是访问权限。已过期和多余的邀请要撤销。
- **为了“省得配置两次”而放宽访问。**多余的管道和聊天迟早会让客户看到别人的上下文。
- **项目结束后被遗忘的关联。**建立规则:在结束合作时检查处于激活状态的关联。