继续使用安全共享
如果主要需求是交换少量、明确的文件,这种方式可能合适。也要演示员工如何跟进请求、补正、当前版本和相关权限,并把这些工作计入比较。
配置现有门户
请业务管理或客户门户供应商演示拟议配置下的完整流程。检查机构级和案件级权限是否符合要求,并确认哪些变更需要供应商持续协助。
委托定制开发
当合适的现有方案仍无法支持流程中的必要环节或访问规则时,可以考虑定制开发。达成开发约定前,先明确这些缺口以及软件后续需要的维护。
客户发来文件,团队要求补充,接下来由谁处理?在选择安全文件共享、现有门户或定制软件之前,先梳理完整流程,并明确每个案件由谁查看。

客户门户可以让客户提交文件、查看工作进展并了解下一步安排。事务所是否需要自己的门户,取决于具体工作流程和哪些人可以查看。安全文件共享可能已经够用。妥善配置后的现有业务管理产品,也可能覆盖整个流程。
作出选择前,跟进一项请求从团队发出、到客户回应、再回到团队的全过程,也包括负责检查材料的人。上传按钮只解决了其中一环。
举个假设例子:同一家客户机构在您的事务所同时有两个案件。财务联系人可以为案件 A 提交文件,另一位获授权的联系人负责跟进案件 A 和 B。财务联系人需要查看案件 A 所需的材料,而案件 B 的信息应继续对其不可见。两位联系人属于同一家机构,并不能决定他们应有相同的访问权限。
团队成员向财务联系人索取案件 A 所需的文件。请求应说明需要什么、对应哪个案件,以及有疑问时应联系谁。先检查事务所已有的资料,再决定是否要客户重复提交。有时确实需要确认或更新信息,请把原因说清楚。
客户上传文件后,员工端会发生什么?需要有人注意到文件到达,把它放进正确的案件并检查是否符合请求。假设缺了一页,审核人员发出清楚的补正请求,客户随后提交完整版本。
现在请双方查找最新版本。客户能否确认补交的文件已收到?审核人员能否将新版本与不完整的文件区分开?决定要保留哪些旧版本、谁可以查看,以及这项工作需要保存多久。
“已上传”只表示文件到达了。“已审核”和“已接受”代表后续决定。为每种状态规定清楚的含义,并明确谁负责下一步。
把整个流程走完。审核人员接受文件,或要求再次补正;客户也能看到接下来需要做什么。如果通知发送失败,或常规审核人员暂时无法处理,要确定由谁发现待处理事项并接手。门户也需要应对这种日常中断。
写下财务联系人、负责两个案件的联系人以及经办员工各自应有的访问权限。范围包括文件、消息、状态和下载内容。再在例子中加入另一家客户机构:它的任何资料都不应出现在这两位联系人的视图中。
决定哪些信息可以向客户展示。客户可能只需要知道团队正在审核文件,无需看到关于文件的内部讨论。公开整个内部案件记录可能泄露客户不需要的信息。明确要分享哪些内容,以及如何保持其准确。
登录可以确认一个人的身份,但系统仍需规定此人可以访问哪些案件和文件。例如,Microsoft 的 Power Pages 安全概览区分了身份、Web 角色、页面权限和底层记录权限。这是一个供应商对不同控制措施的说明,并不代表我们建议购买该产品。
页面不显示在菜单中,并不代表它没有可访问的网址。文件也可能有直接下载链接。有人直接请求页面或文件时,访问规则也必须生效,不能只在浏览门户时检查。
Microsoft 的 安全最佳实践明确提到服务器端授权和直接下载文件。请供应商说明拟议方案如何落实不同客户机构和案件之间的访问边界。页面整齐、成功登录,都不足以证明这些边界有效。
用前面的文件请求、不完整提交和补正流程来比较各方案。每次演示都采用相同的访问要求和员工工作内容。否则,把一种产品的简单上传与另一种产品的完整审核流程进行比较,就不够公平。
如果主要需求是交换少量、明确的文件,这种方式可能合适。也要演示员工如何跟进请求、补正、当前版本和相关权限,并把这些工作计入比较。
请业务管理或客户门户供应商演示拟议配置下的完整流程。检查机构级和案件级权限是否符合要求,并确认哪些变更需要供应商持续协助。
当合适的现有方案仍无法支持流程中的必要环节或访问规则时,可以考虑定制开发。达成开发约定前,先明确这些缺口以及软件后续需要的维护。
把双方投入的工作时间都算进去。客户可能觉得界面简单,但员工仍要花时间把每份上传文件复制到另一个系统。也可能只需调整一个内部步骤,现有产品就能很好地处理请求。与其按门户功能数量判断,不如记录这些取舍。
英国政府的技术采购指南会考虑用户需求、现有产品、持续成本,以及支持采购所需的能力。事务所也可以参考这些问题,但英国政府的采购要求不会自动适用于您的采购。
请供应商在单独的测试环境中,使用虚构的客户、案件和文件搭建这个例子,并事先约定测试范围。使用代表不同联系人和员工角色的账号。测试过程中不要使用真实客户资料,也不要对真实客户执行操作。
演示财务联系人能否打开获准查看的案件 A 材料,同时无法访问案件 B 或另一家机构的资料。负责两个案件的联系人也应能访问约定范围内的材料。还要演示:当用户通过直接页面链接或下载链接访问其权限范围以外的内容时,系统会按预期拒绝。供应商应在授权的测试范围内安排并演示这些检查。
接着完成缺页补正流程。请一位模拟客户用户和一位员工审核人员分别找到请求、提交替换文件、识别当前版本,并说明下一步由谁处理。再模拟客户更换获授权联系人,并检查前任联系人是否失去了应当撤销的权限。
记录哪些环节顺利、哪些失败,以及哪些问题仍需专家审查。这种范围明确的演示可以发现拟议流程和访问规则中的缺口,但它不能认证门户整体安全,也不能证明所有类型的客户资料都适合放入门户。
明确由谁审批新客户账号、调整案件访问权限和撤销权限。确定谁处理错发文件报告、通知失败或门户暂时无法访问的情况,以及解决期间员工如何继续紧急工作。询问谁负责维护软件,并在变更后检查权限。
还要询问退出方案。索取一份示例导出,查看事务所需要保留的文件、消息、有用历史记录和案件关联信息。确认案件结束或合同到期后,账号、保留副本和访问权限如何处理。无论采用安全共享、配置现有产品还是定制方案,都要比较合同条款和持续工作量。
对于专业服务事务所,有用的采购说明应围绕经过演示的流程:谁提出什么请求、谁可以查看、如何补正,以及谁负责下一步。选择能够以可接受方式支持该流程的方案,并计入员工时间和持续维护。如果关键缺口需要定制软件才能解决,我们可以讨论具体范围。许可、交付、支持和商务条款都需按项目商定。
可以。如果它能满足文件交换和访问需求,员工也能可靠地跟进请求、补正、版本和下一步工作,就可能够用。在认定必须建设门户前,先演示完整流程。
不能。确认登录身份与获准查看某个案件或文件是两个不同的问题。先为每位联系人定义访问范围,再使用虚构资料在授权范围内检查,包括直接页面和下载链接。演示不能认证整体安全。
指定一位员工审核提交内容、说明需要补正之处并识别已接受的版本。让客户知道接下来会发生什么,并约定审核人员无法处理或通知失败时由谁接手。
上一期通讯:如何从你已经拥有的订阅制网站或应用中赚到更多。
再上一期:如何从真实的成功案例中识别 AI 的胡扯。
感兴趣吗?
每周 或者告诉我们,我们就按你的意愿调整。这样可以吗?